Blockers in Kanban & Agile
A blocker might be an issue or bug which you have come across during development or testing and which is not allowing you to develop or test further.
Blockers are also known as impediments in Scrum, and issues in more traditional project management approaches.
A blocker doesn’t necessarily have to be a complete show stopper. Drag factors are also another form of blocker, that is, things that are slowing the team (or individual) down but not stopping them entirely.
Examples of Common Blockers or Impediments
Common examples of blockers that teams face on a regular basis are:
- technical environment issues,
- too much multi-tasking or task switching,
- changing priorities,
- bad story slicing,
- dependencies on 3rd parties,
- dependencies on other teams,
- technical debt,
- too many meetings or distractions,
- unfamiliar tools or technology,
- vagueness of stories,
- too much work in progress,
- hidden complexity.
Blockers can manifest themselves at any time and in most cases, pretty much everything gets blocked at some point in the software development life cycle.
Techniques such as Kanban focus on removing the blockers rather than parking the blocked item and starting some other work. In Kanban, blockers are normally visualised on a physical card wall using magenta (or neon pink) post-it notes. When this technique is used it’s important to clearly state the reason for the blocker on the post-it note. This enables management to understand the common causes of delay for teams and assist with the removal of impediments.
Blockers are normally systemic issues beyond the direct control of the team.
Another Kanban technique is to store the unblocked blocker post-its in an envelope at the end of the board. This provides a store of blockers so that every two weeks or so the team can layout all their past blockers and cluster them according to patterns they spot. The team can then focus on taking action to resolve the root cause of the blocker.
Blockers vs Impediments
An impediment isn’t always a blocker. A blocker is actually stopping work for continuing for a work item. An impediment could be slowing down or impeding work on a work item.
Examples of Common Impediments
- Poor performance of dev environments
- Poor performance of test environments
- Constant team interruptions from “high maintenance” stakeholders
- Frequent context switching
Guidelines for handling blockers
We’ve all been conditioned throughout our careers that if we get blocked on something, keep yourself busy and pickup the next work item. This is actually a bad idea. Instead, you should do this:
- Use a magenta (neon pink) post-it note to signify a work item is blocked.
- Make sure the reason for the blocker is clearly written on the post-it note. Without this, how are you going to keep track of everything?
- Focus on unblocking the work as opposed to starting more work.
- Escalate, escalate, escalate
Once you’ve unblocked the work item, keep a record of the blocker. These records can be very useful at the next retrospective in understanding common causes of blockages.
Things to avoid when handling blockers
Avoid adding a blocked column to your kanban board. The blocked column should be considered an anti-pattern. Blocked columns tend to become a dumping ground where user stories hang around for potentially a very long time. Some tooling prevents the proper handling of blocked work items forcing teams to use a blocked column. Teams tend to produce a Jira blocker definition to accompany the blocked column but this is just a sticking plaster on an underlying issue.
About Ian Carroll
Ian is a consultant, coach, trainer and speaker on all topics related to Lean, Kanban and Agile software development.
Connect with Ian at the following