Forem: SteliosVoskos

Getting stand-ups right

SteliosVoskos — Sat, 05 Aug 2017 20:45:58 +0000

The daily formal ceremony of the Scrum framework attracted many views throughout the years on how it should or should not be done. The Scrum guide (2016) describes the daily scrum as a time-boxed meeting where the three questions should be answered, but also it says that the daily scrum is an opportunity for the development team to inspect the progress of a sprint and discuss how they are going to work as a team to achieve the sprint goal.

There are people who say that only the three well-known questions should be answered in a stand-up and that any other discussion should be held outside the daily scrum. Yes, that keeps the daily scrum short. But for one, if we follow that pattern, we are increasing the chances of having other meetings outside the stand-up (which is one issue that the daily scrum intends to solve). Secondly, answering just the three questions we are eliminating the chances of good communication in the team in regards to the issues that they should be solved to achieve the sprint goal. Hence, following that pattern, we save more time, but that comes with the price of insufficient transparency.

Since the daily scrum is a planning session for the next twenty four hours, it should be held in a collaborative spirit, where the development team members not only report what they have done yesterday and what they are going to do today, but also interact with each other to plan how to solve the remaining challenges. If testing is behind schedule for example, the development team members could show the appropriate courage to their colleague/s and plan some time throughout the remaining days to do some testing, so that the sprint goal is achieved.

Below you can find an example of a good stand-up and an example of a stand-up which is subject for improvement.

Daily Scrum 1 (as it should be)

John: Yesterday I implemented feature A and now that's pushed to QA. I also had a conversation with the Product Owner and it turns out that we need to improve feature B. The FE needs to improve error handling and that will take most of my time today. David, based on the artefacts that were published yesterday in regards to the error handling, how much more time will you need to allocate on QA?

David: I will need a couple more hours. Probably five hours, as I will have to test the validation on 7 fields, for both desktop, tablets and mobiles. Since it's mid-sprint and we have another two features to test, I may need some help with testing on mobiles for feature A, otherwise we will curry QA debt to the next sprint.

Chris: No problem, I can help with that. Yesterday I finished writing the web service for feature A, so after I finish with the back-end validation rules of feature B, then I will be able to help QA on mobile testing. Also John, could you please send me the JSON format of the error handling object, so that I implement them on the back-end today?

John: Yes, no problem Chris. You will have that before mid-day. Also feature C is still a blocker, as the URL's are still not ready yet. So I would recommend moving that to "blocked" until the support team fixes the issue.

ScrumMaster: Sure, I will remind the support team that the URL issue should be resolved ASAP. John, if you email me the exact error you get when you visit the page, I will pass it on to the support team.

Daily Scrum 2 (the wrong way)

SrumMaster: John, make a start...
John: Yesterday I implemented feature A and now that's pushed in QA. Also today I am going to work on the error handling for feature B. Currently I am blocked on feature C, as the URLs are not ready.

ScrumMaster: Chris...?

Chris: Yesterday I implemented the web service for feature A and today I am ready to start implementing the back-end validation and the JSON response for feature B. No blockers.

ScrumMaster: And you David.

David: Yesterday I finished testing feature A on desktop and today I am going to test it on mobiles as well. Also I will do some automated testing on feature A.

Do you see how transparent the development team at daily scrum 1 is? They don't care if the stand-up lasts 10 minutes or 15 minutes. They care about planning correctly their work and their time for the next twenty four hours. On the other hand, the development team at daily scrum 2, seems to be sacrificing the correct plan of action for the sake of time. Also the team at daily scrum 2 doesn't show the appropriate support and transparency as the team at daily scrum 1.

P.S: Note that the role of the ScrumMaster at daily scrum 1 is more like an observant rather than a person who is leading the stand-up. The Daily Scrum does not need anyone to lead it and the only people who are required to attend it is the development team. The ScrumMaster can write notes on the impediments and the struggles of the team, and the Product Owner to just track the progress.

A Redux minimum working example

SteliosVoskos — Sat, 25 Feb 2017 09:34:13 +0000

When beginners start learning Redux, they find it difficult to understand how the different components in a Redux application communicate and what purpose they serve. I created a minimum working example with React and Redux, but before I provide you the github link at the end of the article to clone it, I would like to give you some background on how the different parts work in this simple application.

In general, in order to understand how a redux app works, we should ask our selves what does Redux expect from us. It expects:

Default state. This can be an empty array, a text — something to start with in the application.
Reducers. Reducers are the units of functionality that are going to return the new copy of the state. They should be always immutable.
Actions. Actions are the functions that hold the type of action that should be fired and the payload of information that we are sending to the reducer.
A store. Finally Redux expects a store where it is going to store all the state of the application. In the community is well known as the ‘single source of truth'.

I did not mention the container components in React, as Redux is a state management tool for Javascript applications, not only for React applications.

The minimum working example

The file structure of the working example consists of the src directory and src works as a root directory for the other folders in the app.

In the src directory there is a directory called actionCreators. In the actionCreators are the actions that return the action type— in this case ‘INCREMENT'.

In the src directory there is a directory called data. This is the folder that holds the default state of the application. The default state at this case has some text and a counter property initialised to 0.

In the src directory there is a directory called reducers. In the person.js, the new copy of the object is returned with the counter property increased by 1. This happens when the ‘INCREMENT' action type is the case is the switch statement. Otherwise, the default state is returned. Also in the reducers directory there is a file called rootReducer.js. In this file, the person and employer reducer are combined with the combineReducers() method, and they form one reducer that is going to be passed in the store.js.

In the src directory there is a file called store.js and it is the file that holds that whole state of the application. It is created by a method called createStore(), taking as parameters the root reducer and the default state. The current default state is imported along with the root reducer. Then with the appropriate use of createStore(), the store is created.

In the src directory, there is a directory called components. In the components directory presentational component is created in the App.js. It gets the name of the person and the value of the counter from the store and it creates the handler for the increment of the counter.

In the src directory, there is a file called index.js. In the index.js the Provider from react-redux is imported and it is going to put the app into the scope of the store. It is also going to make it possible for us to use the connect() method (see next paragraph) to make the component listening to the changes of the store. Provider takes one property, the store and it needs to be the parent element of the Main.js, which is the container component.

In the src directory, there is a directory called containers. In the containers there is a a file called Main.js. The main objective of the container, is to use the appropriate bindings to listen to the changes from the store and to map the props to the presentational component. This is achieved via 3 methods:

mapStateToProps(state): This method makes the component to subscribe to the store's updates and mapStateToProps is called whenever there is a change in the store.
mapDispatchToProps(dispatch): Gets the actions and makes them accessible for calling in the presentational component. This is achieved by either returning bindActionCreators with the actions and dispatch as parameters, or by just returning an object with the action names.
connect(mapStateToProps, mapDispatchToProps): Composes the above two functions together and it binds all the store updates to the presentational component.

Find the minimum working example here

I hope that this article made the least amount of sense on how a redux application integrated in React should work. Please leave your comment below with your feedback. Happy coding.

The obligation of a software developer

SteliosVoskos — Wed, 15 Feb 2017 17:16:13 +0000

We live in a world that changes everyday and software is one of the biggest part of that change. People interact with software in many ways, such as their laptops, their smart phones, their cars and they expect to get the most out of the devices they use.

Behind the software applications are the teams who build the products and the factors that determine the success or failure of the software are strongly connected with the cohesiveness of the team, the amount of effort the team has put during the delivery and the behaviour of each individual. In this article we will explore some of the ethics that a developer and a team should have during and after the delivery of a software product.

Find the best solution and not a solution
As mentioned in the introduction, a significant factor that will determine the long-term success of a product, is the quality of the solution we are offering to the client. There is no reason to deliver a solution that is going to slow-down the product, make its state unpredictable or make the UI looking different from the one that your UX designers proposed. And this is simply because the quality of the solution and amount of effort, show the respective respect to the client and/or the future user. The high code quality in the codebase will also make the experience of the current and the future developers significantly better.
Do not write code you do not trust
A codebase without unit tests or any kind of tests, contains code that cannot be trusted. And why should you deliver a website, a SPA or an app to a user with code you don't trust? The answer is that you should not. The tests are the first line of defense in a codebase, they are the part of the code that will give you the heads-up when something goes wrong and they are going to catch the bug faster than your console.log('Hello'), they are the part of the codebase that will explain to the software developer or the QA tester the purpose that your code serves. Also remember that the tests are the units that prevent you from writing unnecessary code. So always aim for the highest possible amount of code coverage for your benefit and the benefit of the future user. A codebase should include 15% UI tests, 30% integration tests and 55% unit tests. The unit tests should always be close to 100% code coverage and they should cover as many cases as possible.
Learn how to say No. But also learn to negotiate.
I am glad that at the early stages of my career some Scrum Masters and Solution Architects taught me the value of saying No, but also how to negotiate to make the “No” a compromisation that works as a solution for the benefit of both sides. They taught me that if I don't raise my voice and say that “this, this and this can't be done now or in that way”, then I will end-up with unnecessary amount of pressure on me. And it's true. Unrealistic deadlines, unrealistic requirements and unrealistic delivery will be part of the discussions during development, but you have to find the correct arguments to defend the fact that some things cannot be done by a certain deadline or in the way they are proposed. It is the worst form of unprofessionalism to make a commitment that you can't keep, or make false delivery just to think that you keep your line manager happy in that way. The opposite may happen.
Respect your team members
Your team members are the people you meet every day for at least 8 hours per day, the people that you have long meetings to find the appropriate technical and non-technical solutions, the people you speak with every day. There is no reason to create tension, and change arguments that may harm the cohesiveness and harmony of your team. And if that happens, it is your obligation to discuss the issue with your team member/s and resolve it as soon as possible. Also in a team there should not be a person who should think that is doing better job than the others, or that the depth of knowledge gives them an advantage to behave in an inappropriate way. If someone encounters an issue, then there should be the appropriate support and mentoring and help that team members or team members get back on track again. If there is success, then your team celebrates as a collective. If the product fails, then the team fails as a collective. At the end of the day, what's the meaning of a team that is just a disarrayed set of individuals?
Enhance an implementation. Do not criticise it.
I am at the second year of my career and code review is the part of the development that I always consider an enjoyable task, because it's a good chance to sit down with your colleague and think as a collective how to enhance the implementation that has just been committed in the codebase. It's an exercise that should be happening in all development teams, as the developers are the people who should spot a mistake in codebase in the first place and improve an implementation to make it faster, better and more generic. The criticism and the advice should always be constructive, it should include the “why” your suggested implementation is better than the existing one and your advice should include examples from previous implementations. However, any kind of advice or suggestion should never be said in a judgemental and tough way, as the code review is a team exercise and not a chance to judge your colleagues just because they have done a coding mistake.

Mentoring is also part of our job and it is always required to help others improve and bring them to the level of the rest of the team. As Eric Elliott says in his article “The Essential Guide to Building Balanced Development Teams”:

In a mentorship culture with lots of pairing and code reviews, even novice developers quickly become great contributors.

There is nothing better and greater than mentoring Juniors and see them becoming great developers just because your advice had an invaluable impact on them.

Great software is built by great teams, where the culture within the team is such that allows them to outwork the most difficult challenges. It is also the obligation of each individual to have the right mindset when developing a feature in order to deliver the code in the appropriate quality level.