Blocked or Impeded?
I’ve worked with Scrum Masters who describe the main part of their role as being about ‘removing blockers to the Development Team’. I’ve seen this description in job adverts and other online sources.
I was interested in why the word impediment (actually used in the Scrum Guide) would be commonly changed to blocker, how the words are used interchangeably, whether this mattered and what it can mean for Scrum Masters.
Back to the Source
The Scrum Guide lists the Scrum Master’s responsibility for impediment removal when it discusses Scrum Master services to the Development Team.
‘The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality;
- Helping the Development Team to create high-value products;
- Removing impediments to the Development Team’s progress;
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.’ — The Scrum Guide 2017 (my emphasis added).
Impediments are explicitly mentioned in the Scrum guide in only 3 places. The quotation above and then twice when the Daily Scrum is described. They are mentioned in the 3 questions provided as an example Daily Scrum format that might be used by a Development Team:
The structure of the meeting is set by the Development Team and can be conducted in different ways if it focuses on progress toward the Sprint Goal. Some Development Teams will use questions, some will be more discussion based. Here is an example of what might be used:
• What did I do yesterday that helped the Development Team meet the Sprint Goal?
• What will I do today to help the Development Team meet the Sprint Goal?
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
— The Scrum Guide 2017
And also here:
Daily Scrums improve communications, eliminate other meetings, identify impediments to development for removal, highlight and promote quick decision-making, and improve the Development Team’s level of knowledge. — The Scrum Guide 2017
Blockers are not mentioned at all in the Scrum Guide 2017.
The Problem
Clearly, synonyms of impediment would include barrier, obstacle, blockage in modern English usage. Perhaps it seems less pretentious to use blocker rather than impediment in conversation?
I think that the first problem with the more colloquial ‘a Scrum Master removers blockers’ may be the thinking:
- Blockers and impediments are the same thing.
- Blockers will be raised at the Daily Scrum.
- The Scrum Master need only be responsible for blockers raised at the Daily Scrum.
The responsibility to ‘remove impediments to the Development Team’s progress’ should cover much more than just blockers raised at the Daily Scrum.
The second problem is that with people, teams or organisations that are new to Scrum this change of language may have unforeseen consequences.
If we interpret our role as Scrum Master to be just about removing blockers rather than (as the Scrum Guide says) to be about removing impediments then we may be missing opportunities to serve the team and coach them towards self-organisation.
We use Scrum to help us work in complex environments. Changing the language of Scrum seems like something that could add to the complexity and introduce confusion rather than help teams deal with it.
I think that this is more than semantics and is about how we interpret the Scrum Master role and how it is viewed by others.
Differentiation
Equality without differentiation is bad equality. Differentiation without equality if bad differentiation. — Katsuki Sekida
In ‘Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools, & Tips’ IIan Goldstein makes the distinction that:
Many teams use the terms block and impediment interchangeably, but I like to differentiate between the two. I do so to clearly identify an obstruction that has stopped progress on a particular task but hasn’t necessarily slowed down overall progress (a block) versus an obstruction that is slowing down the team’s sprint progress (an impediment).
In ‘Scrum A Smart Travel Companion, A Pocket Guide’ Gunther Verheyen provides a glossary where he defines impediment as:
Impediment: any hindrance or obstacle that is blocking or slowing down the Development Team and cannot be solved through the self-organization of the Development Team itself. Raised no later than at the Daily Scrum, the Scrum Master is accountable for its removal.
Combining these I’d say that the set of impediments includes the set of blockers but that it is helpful to differentiate because:
- A work-impacting blocker is more likely to be raised in the Daily Scrum.
- A team may deal with individual blockers well, but repeat blockers may signify an impediment to progress that may not be raised at the Daily Scrum.
- One team’s blocker (stops work on a task) may be another team’s impediment (slows down work) depending on the self-organising capability of the Development Team experiencing them.
- Different organisational contexts or cultures may present superficially similar impediments to Scrum Teams but different approaches, appropriate to the context, may be required to address them.
- ‘Removing impediments to the Development Team’s progress’ does not necessarily mean that the Development Team have raised the impediment or necessarily visualise it as an impediment.
- Impediments should be raised immediately (at the latest at the Daily Scrum) but a team may need help to visualise the impediments that are acting upon it.
A Development Team may raise all of the impediments that impact them in the Daily Scrum but, in my experience, they are more likely to raise work impacting blockers to ask for help. As Scrum Masters, we cannot expect that all impediments will be surfaced in this way.
Why Differentiate?
I think that a Scrum Master should coach a team to remove blockers and help them to identify and visualise impediments. As the self-organising capability of a team improves they may self-organise to address impediments to progress (maybe outside of the Scrum Events). The Scrum Master remains responsible for this process and for removal of impediments that the team cannot address.
I think this distinction is useful for a number of reasons and can help us consider how to best help people and teams using Scrum:
- A new Development Team member that is used to hierarchical management styles (and escalating any problems to a ‘lead’ or manager) may initially lack the self-organisation to address a blocker. This may be by asking for help from the team or by pro-actively progressing this problem. Solving the blocker for a person rather than coaching them to address it can be less beneficial in the long run.
- A Development Team of people that are pro-active individually may resolve their own blockers — but may not have the experience with self-organisation or the openness to look at the cumulative impact of blockers on the team. The wider impediment could be missed.
- A team that does consider impact at the team level may limit themselves to tangible task-orientated impediments (i.e. groupings of blockers) but lack the trust or self-organisation to discuss people conflicts or training requirements openly and respectfully.
- An inexperienced Scrum Master may limit themselves to picking up blocker-level impediments raised at the Daily Scrum and miss an opportunity to coach the team towards recognising and tackling impediments in a self-organising way.
These are all opportunities for collaboration, coaching and progression that Scrum Masters can be alert to.
Not only is there a progression for the Development Team but also for the Scrum Master. To deal with impediments that are wider-ranging the Scrum Master can ask for help and support and will need skills and techniques to be able to do this effectively.
Not Just the Daily Scrum
Scrum provides us with the opportunity to inspect the performance of the last Sprint as a Scrum Team in the Sprint Retrospective.
In the interests of keeping this article focused I don’t want to get into the pros and cons of different Retrospective formats. Suffice it to say that as Scrum Masters facilitating a Retrospective we can choose a format that helps the team discuss topics that may not come up elsewhere in the Sprint.
There are well-known Retrospective formats that leverage visual metaphor to help Scrum Teams with this. Examples would include the hot air balloon retrospective and the sailboat retrospective.
Explore
In addition to a Retrospective format that helps identify blockers and impediments, root cause analysis of a given blocker can help us to look deeper.
Root cause analysis techniques such as an Ishigawa Diagram or a Five Whys exercise are helpful techniques to work through with a team when discussing repeat blockers or blockers that collectively constitute an impediment.
The root cause, whilst not actively blocking the team at that moment in time, is nevertheless an impediment that we should take ownership of (or better yet, coach the team towards ownership of the problem).
In this way, the Scrum Master can help to address impediments that are impacting the Development Team’s progress and also coach the team towards being alert to the value of looking deeper.
From observation, I believe that a new Scrum Master or a Team new to Scrum are more likely to pick up on task-level blockers that impacted the previous Sprint rather than look for root cause impediments in a Retrospective.
Visualisation and quantification will be invaluable when trying to enlist support from managers or executives to tackle impediments that are likely to impact multiple teams and/or the success of Scrum in an organisation.
A Sprint Retrospective may not surface all impediment types. How the team visualise the Sprint, the extent to which work is transparent, the level of openness on the team and the format of the Retrospective itself may all impact whether impediments are raised.
Impediments
We use Scrum to help us with complex work and complex work will inherently have many opportunities to experience impediments.
The Scrum Master must serve the wider organisation in a number of ways including:
Causing change that increases the productivity of the Scrum Team; — The Scrum Guide 2017
If we look for implicit examples of impediments that a Scrum Master might need to be aware of from the Scrum Guide then it is clear that the Scrum Master’s service to the Scrum Team and the wider organisation covers many areas that may need support. Any of these areas could impede the progress of the Development Team.
When the challenge of complex work is added to the challenges that come from working as a team, challenges that come from larger groups in scaled Scrum, or from working in large or complicated organisations we can end up with an almost endless variety of things that may impede a team.
Conclusion
I think that it does matter whether Scrum Masters describe their role as about being ‘blocker removal’ or ‘impediment removal’. It’s helpful to differentiate blockers and impediments because of how that helps us think about them. As Scrum Masters, our role is to remove impediments not just blockers.
Exactly how we proceed to deal with impediments that may be impacting a team will vary depending on the factors discussed above. I don’t think there are many hard and fast rules due to the different contexts that are possible but I would suggest:
- Empiricism asks us to be transparent, to inspect and then adapt. Improving transparency by differentiating blockers and impediments helps us inspect and work out how to adapt.
- Discussing impediments as a team and collaborating on how to tackle them can mean working beyond the Scrum Team with wider communities of practice and leadership teams.
- Scrum Masters do not have to solve all of the problems. But we can help by visualising the impediments that are slowing teams down, quantifying the impacts and being able to articulate this in a respectful, positive and constructive way.
- If we stop looking for impediments at the Daily Scrum or only focus on blockers then we are limiting the ways we serve the Development Team and the wider organisation.
- If we do not take a wider view of impediments then we would be missing out on a large part of our responsibility as Scrum Masters, opportunities to grow the capabilities of Scrum Teams and opportunities to develop as Scrum Masters.
‘Impediment Remover’ is discussed as a Scrum Master stance in Barry Overeem’s whitepaper The 8 Stances of a Scrum Master. I think that to be able to deal with all of the possible types of impediments we will need to master the 7 other stances exceptionally well.
References
Goldstein, Ilan: ‘Scrum Shortcuts Without Cutting Corners: Agile Tactics, Tools, & Tips’
Loeffler, Marc: ‘Five Things Nobody Tells You About Scrum’, from ’97 Things Every Scrum Practitioner Should Know’ Edited by Gunther Verheyen
Overeem, Barry: ‘The 8 Stances of a Scrum Master’
Verheyen, Gunther: ‘Scrum A Smart Travel Companion, A Pocket Guide 2nd Edition’
