Estimations and Uncertainty in Agile Projects | David Tzemach

To become fully Agile, the team must leave behind much of their traditional project management mindset. Traditional project management has many aspects that are not relevant to the values and principles that come with Agile adoption. This is especially true in allowing a team to make mistakes as part of their growth.

Due to the nature of project management, wrong estimations delivered by the team can lead to dangerous consequences. These can affect the entire organization and especially team morale.


Once the organization decides to adopt one of the Agile frameworks, they must allow their teams to work with a high level of uncertainty. They need to keep moving forward even if they provide wrong estimations about their ability to deliver their commitments (measurements, training, and processes need to be put into place for this to work, this is a complete culture change).


The Level of Uncertainty in Providing Accurate Estimations

Naturally the team that possesses some experience will more easily provide accurate estimations. This does not mean the estimation problem has been resolved, because estimations can be as wrong in Agile as they are in traditional projects.


The main difference in Agile is that we accept the idea that the development team can be wrong with their estimations, and this is especially true with new teams that have just begun following an Agile framework (Scrum, Kanban etc.). The assumption that Agile will resolve this problem is wrong (although it can improve the symptoms).


Although the level of uncertainty in the Agile environment is lower, it still exists. One cannot assume that the team will be able to provide accurate estimations, for more than the next sprint and even then, they can be wrong.




Embracing Courage as a Growth Engine

There are two approaches to handling estimation mistakes. The first option is more common in traditional project management and focuses on blaming the development team for their mistakes and how they jeopardize the whole project.


This approach is what I like to call an "HR" killer that will neither contribute to the motivation nor make the team more willing to meet commitments. Blame is not an effective method to encourage people to improve their abilities. The only result will be that next time, the team members will provide exaggerated estimations just because they are afraid to be mistaken again.


In the Agile environment, there is more room for mistakes that come from the overall mindset. Those mistakes can be used as a catalyst for the team, as part of their natural growth and continuous improvement.


Remember that for a team member, it takes courage to stand in front the rest of the team and say "I got it all wrong" or "I made a mistake that kept us from completing the story", but it allows him to get the help of the team and the confidence that they will help him to improve next time.


Being Agile Instead of Doing Agile in the World of Estimations

Once the organization decides to start the transition to Agile, there will be a period of weeks and even months when the old project management style will still be the dominant one. This will continue until the organization changes its culture and really adopts the Agile values and principles.


During this difficult period, the Scrum Master or team manager should provide the team with a confident working environment that will allow them to transition to Agile. This is completely different from just doing Agile.


For this transition to be as smooth as possible, the Scrum Master or team manager must remove pressure and any external interruptions that may affect the team. On the other hand, he must recognize warning signs that come from the team itself. This demands more HR-related skills that enable him to become effective at discovering problems earlier.


A good, experienced Scrum Master will know each of the Agile activities has its own warning signs. Let us review two classic examples:


No courage to admit lack of knowledge

The first example is a team member that does not share any obstacles or impediments. These can result in either slowing down work or dangerous blockages that can occur. Either of these can result in a delay in the delivery schedule.


A good Scrum Master must see warning signs and should proactively seek to understand the reasons and determine why no impediments have been reported.


Once the Scrum Master recognizes this issue, he needs to understand the root cause of why the real problem is not reported by the team member. Usually, a short discussion with this member will reveal that he was not confident enough to stand in front of the rest of the team and ask for their help. This often results in the team member trying to provide a fast fix to the problem. This takes time and can have an impact on other team members. It may even result in them losing trust in the team member, the group or the Agile process.


The team cannot provide estimations

In another classic example, a clear warning sign is when team members say that they cannot provide estimations because they do not have enough information about the task. This is fine in some situations, but often the root cause is that the team members do not have the courage to admit that they just doesn't have what it takes to complete what the PO asking for.


Once this occurs, it is the Scrum Master task to explain to the team that it's ok to make mistakes. It will help them improve their next planning meeting. Within the Agile framework, there is room for this. Therefore, team members should not be afraid to request help from members of their team or ask for more information to handle the task.


The Scrum Master should constantly remind the team that it takes courage to take an educated guess (every estimation is a guess unless you have a crystal ball that can show the future). Not knowing how to finish a task does not mean that you cannot start working on it and deal with future problems as they occur.