Using a software methodology is far better than no methodology at all. No methodology might make sense when the project is small and all the requirements knowledge is under the control of the developers but things get very hard when the project and team get bigger.
We can’t underestimate how important are the processes to gather requirements and organize tasks for the team, otherwise, it will be impossible to create business value.
This situation occurs usually when a company is in the transition from small to medium size because when the team was small things used to work.
Things get even more challenging when there are different teams working on the same project spread all over the world. The common scenario is that it’s usually in just one country where most of the requirements knowledge are located. Then developers have the big challenge of the timezone, meaning that we have to adapt to a different timezone. This means that developers have to work during the night to be able to attend meetings.
Given this challenge that is common between companies around the world, a software methodology would come in handy. First of all, there is no silver bullet and no perfect software methodology but Scrum does the job very well. When Scrum is used as it is supposed to, it is a great help for developers to get the job done. We know exactly what we should do ahead of time, we have a better idea if we can deliver features, we learn the team speed too.
Kanban is also very commonly used in conjunction with Scrum, which is basically the idea of having a board with tasks on ‘to do’, ‘doing’ and ‘done’. Therefore it’s easier to know how the work progress is going.
Scrum is divided into sprints, this means cycles of work. A sprint usually takes 2 weeks for most companies and in my opinion that’s the best time frame for a sprint. I tried 1-week sprints and in my experience, it was always a disaster.
During the sprints, we have ceremonies and the ones I used and worked well in practice are the following:
Macro planning – This is the planning where product owners, business people, managers, and software developers gather together to figure out everyone who will be impacted by the development during the quarter. It’s a macro view of what will be delivered for the whole quarter. Then when we organize all the tasks usually on the wall, we roughly measure how likely we are likely to deliver everything from 1 to 3.
Refinement – It usually happens before planning once or a couple of times to refine the idea about the business. Depending on the business complexity, it might involve people from different teams and it might take a while until everyone has a clear vision of what has to be delivered.
Planning – It’s one of the most important ceremonies from Scrum since it’s on the planning where the tasks get created. Usually, the product owner will show what piece of the business that must be solved, and then software developers will discuss until reach a consensus of a solution and will create the tasks based on it.
Complex Points – With all tasks created, it’s time for the complex points. It’s basically the complexity of each task. Developers give a complex point to each task altogether and in case a developer gives a very high or low point, it’s time to discuss why and reach a consensus on a team level. In the complex point ceremony, we can learn many things about the task to be done. Several times I’ve seen tasks that I thought it was simple and because of another developer who said it wasn’t I also changed my mind, the opposite might happen as well. The complex points are given with the Fibonacci calculation as well, this means, 0, 1, 2, 3, 5, 8, 13, and so on.
Daily stand up – Nearly every software development company has a daily meeting. The purpose of it is simple, it’s to say what you done, what you are doing, and if you have any blocker for your task, this meeting shouldn’t take more than 15 minutes. It’s important to be brief and bring important information to the team so that the sprint tasks can be delivered successfully.
Retrospective – To maximize the performance of the team, at the end of the sprint there is the retrospective meeting. The purpose of the retrospective is to expose what went well and what can be improved so the team can change their actions and strategies to deliver the tasks more effectively. There are several different ways to run this meeting but the essence the objective is to find out how to become better.
Developers just have to be careful to avoid pointing fingers in the retrospective, otherwise, the retrospective will do more harm than help the team. The blame culture is toxic and dramatically damages the developer’s productivity because of excessive stress.
Company Level Process Issues
As mentioned before, having a software methodology/process is far better than having none but it’s not a silver bullet. The company-level process plays an important role in business definitions. Even if we apply the Scrum process correctly but the company doesn’t have their software engineers teams organized with at least one business person, QA and DevOps it’s very hard to plan tasks for a 2 weeks sprint.
If developers accept constantly the situation of collecting requirements on the go and doing whatever comes into the plate, the cycle will never end. A possible solution is to possibly stop implementing for 2 weeks and focus only on collecting requirements. Then once the team has enough tasks for the whole sprint, developers can focus their whole energy on business implementation while the business people can work in parallel collecting requirements and preparing tasks for the next sprint.
That’s one of the reasons why the Scrum software methodology adoption by one team won’t be enough. Since nearly every company in the market is using microservices, teams have to communicate and sync up more often. If one team is gathering requirements on the go, it will be impossible for other teams to have a well-structured scrum process since the requirements will depend on the other team.
When the process problem is at the company level, the process gets more difficult to be changed. Developers have to expose their ideas for improving the process because if there is no information from what can be improved, nothing will be improved. There is one very powerful quote from Robin Sharma that I believe it really applies to this context because a company level change takes time until it’s effectively done:
Small daily – seemingly insignificant – improvements, when done consistently over time, lead to STUNNING results
As wisely said by Robin Sharma, big things take time and consistency. But if developers and stakeholders embrace the philosophy of small daily improvements, with time the company as a whole will have stunning results delivering high-quality software.
