Being “blocked” unfortunately is a common occurrence with Agile teams. There can be any number of reasons why work gets blocked, it could be internal (e.g. waiting on PdM feedback, test environment down, etc.), within the technology function/from other teams (e.g. platform outage) or even the wider organisation (e.g. waiting for risk, legal, etc.).
Part of making work visible via a kanban system includes making it visible when work is blocked. Some teams will consider a blocked column, which is not a good idea for a number of reasons. Teams should hopefully look to “tag” items as blocked when they can no longer progress things.
Red sticky = blocked work - Source: Valueglide
This also may mean that teams need to agree a consensus on when we say “blocked” what do we actually mean? As Dan Vacanti and Prateek Singh mentioned in their recent video on Flow Efficiency, most teams don’t even have an agreement on a definition of what blocked means!
With the kanban board setup in Azure DevOps, this is actually pretty easy to do. If an item is blocked, you simply add a tag stating blocked and then the tag is visible. Furthermore, you can add a styling rule to make this blocker a bit more visible to the rest of the team.
Great so we’re tagging work that is blocked, we’re done right? Well….not really.
Blocked work is probably one of the most valuable bits of data at your disposal as a team and organisation. These are the real things that are actually slowing you down, and likely the biggest impediments to flow that are in your in your way. As Jonathan Smart would say in Sooner Safer Happier (a must read btw!):
Impediments are not in the path. Impediments ARE the path
So what can we do to make use of this data? One popular activity to carry out is blocker clustering, whereby you take any items that were blocked, note the frequency of blocked as well as the reason/impact and use that to drive system improvements.
The problem however is that this is not easy to figure out with Azure DevOps. As a tool it will only let you query on present tags on an item (via contains/does not contain), not “was ever”.
Meaning you need to go through the work item history of every item to find out if it was ever tagged - eugh!
With so much potential data in a team Azure DevOps project, I needed something simpler. Fortunately, with the OData queries, and the WorkItemRevisions table, it is possible to query the historical data for any changes made to work items. This way we would be able to see when tags were added/removed and, with the power of DAX, calculate how long items spent being blocked.
The end result is a report that looks like so:
We can now see:
Current blocked work (and how long it was blocked for)
How many items of a teams daily WIP were blocked (and where it’s trending)
The rate of blockers being raised/resolved
How much time is lost from an items total cycle time due to being blocked
This way, teams can now make real sense of their blocked data and use this to drive wider improvements in their way of working, as well as highlighting the impact (in days) to other teams and/or the wider organisation.
Whilst this is fine as an interim solution, it really isn’t as comprehensive enough as it needs to be to have real impact. For example, the reason for being blocked is missing, which is hugely important if you have common themes around blockers. Fortunately for the lean-agile community, Troy Magennis is leading the way for teams making sense of blocked data, with the recent release of Blocked.
It is a Blocker and Dependency Management app which, in my view, is the most comprehensive work done so far in our industry around quantifying the impact of blockers and dependencies. It’s currently free for a single team, as well as containing lots of dummy data to play around with to familiarise yourself with the tool - go check it out!
If you want to visualize the impact of your blockers with your Azure DevOps data, this is now available as part of FlowViz - a free Power BI template to download, connect to and visualise your Azure DevOps data.