"I Have No Impediments"

19 March 2012

Christopher Broome
True Clarity

"I have no impediments."

It's the most common sign-off for every team member in the daily Scrum. It's also a lie.

We've all been there. Standing in a little circle of people, listening to the carousel of "This is what I did yesterday, this is what I am going to do tomorrow, I have no impediments" from each of the team members. The reality is, most teams will suffer some sort of impediment each and every day. The difficulty lies in getting teams to discuss these issues. For individuals and teams new to Scrum in particular, it takes time to understand the importance of raising impediments and to feel confident enough to raise them in front of peers.

 

Why is it important that we raise impediments?

During the sprint, impediments need to be discussed openly so that they can be dealt with quickly and efficiently by the team or ScrumMaster before they cause serious issues. Leaving an impediment for even a single day can turn an innocuous issue into something that endangers the entire sprint.

This is one of the most important reasons we engage in the daily Scrum, the meeting in which, as a team, we feed back to the team what we've been doing and what we are going to be doing. If team members don't take the opportunity to stand up during the daily Scrum and say, "I have a problem here because . . ." then the issues that have arisen don't get discussed, dealt with, and prevented from occurring again. This results in an endless cycle of impediments that prevents the team from achieving its potential velocity.

By communicating impediments as they occur on a daily basis at the Scrum, the team puts itself in a position to deal with these issues early, before they have an adverse reaction to the sprint. Of course, this also means that during the daily Scrum the team needs to know how to deal with an impediment. As a rule of thumb, I would expect a team to ask the following questions for any impediment raised:

What caused the issue: Is it something that can be resolved by the team?

Who is best placed to deal with the issue: Will a better use of resources remove the impediment?

When can the issue be tackled: Can this be dealt with straightaway?

You'll notice that the questions above have no focus on "why." We don't want the team to be focusing on the "why" during the sprint, as the priority is to deal with the issue, not to understand in depth what caused it. The question of "why" is best left for the retrospective, when the team can objectively review what happened. The opportunity is then there for the team to discuss the origin and repercussions of the impediment in more detail. This can allow the team to change behaviors, processes, or procedures to minimize the risk of the impediment occurring again. This could mean anything from stricter controls on when team members go on holiday to improved conditions of acceptance for user stories.

 

Why don't team members raise impediments?

Moving between Scrum teams, it's easy to see which teams are experienced in Scrum and which are relatively new to the whole concept. More experienced teams fly through the daily Scrum, quickly summarizing what occurred yesterday before shifting focus to what they plan to do today. They're also eager to raise any impediments they may have, as well as any that they may potentially have to deal with during the day. Impediments are dealt with in an efficient and concise manner, resulting in a plan of action where necessary.

New teams are often the exact opposite, focusing on what they did yesterday, showing uncertainty about what they plan to do today, and making no mention of impediments. Why the difference? Well, we have to remember that most team members new to Scrum have been taken out of a Waterfall methodology, where they did what they were told and teamwork was conceptual at best.

Being asked to admit in front of your peers that you have a problem is a big step for most people, and it shouldn't be underestimated. New teams won't have built up the sense of trust that permeates more experienced teams, and this acts as peer pressure, with team members not willing to show weakness in front of their colleagues.

Team members may also feel that some impediments are not important enough to be raised at the Scrum. Perhaps the issue is small and is going to delay the developer only briefly. Or, sometimes, developers don't raise issues because they know they can sort them out themselves, so they don't see the need to discuss them in front of their colleagues.

 

How can we overcome these issues?

While the product owner and ScrumMaster are key to building a working environment in which team members are encouraged to raise impediments, the team as a whole must work together to facilitate a working relationship based on trust. This takes time and won't happen overnight, but it can be encouraged in a number of ways:

  • Trust begets trust. Always be open and transparent.
  • Ask questions. A ScrumMaster can encourage the team to discuss issues by asking them questions rather than making statements.
  • Respect the opinions of other team members. Brushing off their comments or getting angry because the answer provided is different from what you wanted is counterproductive and likely to hinder anyone from offering an honest opinion in the future.

The speed at which teams learn the value of discussing impediments will vary depending on the team's characteristics. Every team contains a mixture of personality archetypes. A ScrumMaster will need to have the support of the more extroverted members of the team and rely on them to encourage the quieter members, who may be uncomfortable when talking in front of others.

 

Summary

How a Scrum team deals with impediments is its ultimate test. An efficient Scrum team will always tackle issues head-on, with honest discussion of the issues and options before deciding how best to proceed. Impediments and bumps in the road are facts of life and occur daily. It is how we deal with them that shows the strength of our character. So be honest with yourself and your team before you next say, "I have no impediments."


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Karim Harbott, CSP,CSM, 3/27/2012 9:25:11 AM
Thanks Christopher. We sometimes have a similar thing. I often have to prompt the team to even mention impediments.

There's also sometimes a mindset of leaving the problem task and starting something new. There's a view that this optimising of time on a micro level is helpful and they do not see that increasing the work-in-progress and leaving impediments unresolved kills productivity. This is where the Kanban practice of limiting WiP can help. It forces the issues to be dealt with or work stops completely.
Pedro Garcia, CSM, 4/1/2012 11:07:05 PM
Unfortunately, the 'no impediment' in the daily scrum happens frequently. Some developers think that an issue is not enough big to become in an impediment. The good thing is that the team learns and it can be reviewed in the Retrospective
Timothy Korson, CST,CSP,CSM,CSPO,REP, 4/2/2012 8:08:46 AM
Christopher, thanks for addressing this important issue. I tell scrum team members that being a good team member is a lot like being a good marriage partner. It's all about trust, communication, openness, etc. There is a lot of literature addressed at the ScrumMaster and Product Owner, but not much addressed to team members. However, there is a lot of literature addressed at being a good spouse. An interesting exercise for a retrospective (or team retreat) is to have everyone read a good book on marriage and come prepared to discuss how the concepts apply to Scrum teams.

You must Login or Signup to comment.