The courage to work under Uncertainty in Scrum teams

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

Due to the nature of Traditional project management, wrong estimations delivered by the team can lead to dangerous consequences that will affect the entire organization, significantly affect team morale.

Once the organization decides to adopt the Agile framework, they must allow their Scrum teams to work with a high level of uncertainty and keep moving forward no matter 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

We all know that it will be more straightforward (With some experience) to provide more accurate estimations when using Agile. This does not mean the estimation problem has been resolved. Time estimations can be wrong in agile as much as they are when using traditional SDLC methodologies.

The main difference in agile is that we can accept the idea that the development team can be wrong with their estimations, and this is even more true with new teams that have begun following the agile framework. The assumption that Agile will resolve this problem is wrong (although it can improve it dramatically). Although the level of uncertainty is lower, it still exists. During the planning meeting, one cannot assume that the team will provide accurate estimations and a good task breakdown. This is especially true in the beginning. 

Embracing courage as a growth engine

There are two main approaches to handling estimations mistakes. The first option is more common in traditional project management methodologies. This method points the finger and blames the development team regarding their mistakes and their effect on the project.

This approach is what I like to call an "HR" killer that will neither contribute to the team's motivation nor commitment. Blaming is not an effective method to encourage people to improve their abilities. Next time, the only output will be that the team members will provide exaggerated estimations because they are afraid to be mistaken again. 

In Agile, there is a more acceptable room for mistakes from the overall mindset that mistakes can be used as an excellent method for the team to grow, primarily when the team reviews them in dedicated retrospectives. Remember that for a team member, It takes courage to stand in front of 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 will allow him to get the help of its team and the confidence that they will help him to improve next time.

Being Agile instead of doing agile

Once the organization decides to start the transition to Agile, there will be weeks and even months that the old project management style will still be dominant (do not think otherwise…). This will continue until the organization changes its culture and adopts the agile values and principles.

During this challenging period, the Scrum Master is responsible for providing the team with a confident working environment that will allow them the transition to "Being" Agile. This is entirely different from just "Doing" agile.

For this transition to be as smooth as possible, the Scrum Master on one side must remove pressure and any external interruptions that may affect the team. While on the other side, he must recognize warning signs from the team itself. This demands more HR-related skills that will enable him to become effective in discovering problems earlier.

In traditional project management, there are often slow, ineffective meetings that are usually the result of missing direction/deadlines from a single authority. However, agile, slow, and inefficient meetings can result from a lack of courage or poor team commitment.   

A good experienced Scrum Master will know each Agile activity has its warning signs. From my point of view, daily standup and retrospective meetings are the best places to see them. Examples:

No courage to admit lack of knowledge

The first example related to these meetings is a team member that does not share any obstacles or impediments. These can result in either slowing down work or dangerous/blockages scenarios that could occur. Both these can result in a delay in meeting time schedules.

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

Once the Scrum Master recognizes this issue, he needs to understand the root cause of why the team member does not report the real problem. Based on my own experience, 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 fix the problem quickly. This takes time. This can impact other team members and result in them losing trust in the team member of the group or Agile process. 

Time Estimations 

Another classic example relates to time estimations that the team needs to provide during the planning meeting. A clear warning the SM must look for is once team members say they cannot offer estimates because they do not have enough information about the task. This may be ok in some situations, but based on my own experience, the root cause is that the team members do not dare to admit that he doesn't have what it takes to complete what the PO is asking for (Or they don’t understand the requirement and what is expected from them…).  

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

The Scrum Master should consistently 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). The unknowing on how to finish the task does not say that you cannot start working on it and deal with future problems once they occur.  

And as the Scrum Master

If you are the Scrum Master of the team, it is your responsibility to search for warning signs. Although I provide just two examples, there are many more warning signs that can help you determine how courageous your team is while providing their estimations.

Based on the warning signs revealed by your team, it’s your responsibility to coach your team on how to be more courageous and transparent to allow them to keep moving forward without instead their estimations are correct or not (I can assure you that it will improve per iteration).