Blockers in Kanban & Agile

In Agile, anything that stops or slows down the delivery of a product, or acts as a hurdle for the product can be termed as a blocker, impediment or Kanban blocked.

blockers

Agile Blockers

Blockers on a Kanban Board

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,
  • rework,
  • 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.

blockers-sticker

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
  • And most importantly, if you are absolutely blocked and can’t escalate anymore, always look for work from downstream (right) columns on the board before you go upstream (left) looking for work.

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. Important data points to capture per blocker are

  • date blocked
  • date unblocked
  • internal or external blocker
  • categorise the blocker if possible into themes like dependency, technical, or person

From these data points you can run further analysis on the causes and impact of the blockers and visualise them as follows:

blocker grouping analysis

Color coding of blockers represents the category of the blockage.

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.

Leave a Comment

Your email address will not be published. Required fields are marked *

Further information...

The content of this article is just the tip of the iceburg. To dive deeper into any of these case studies or concepts join our 2 day Portfolio Kanban live online course.

Application for a free Agile Coaching session

I would like to speak with an advisor