Do you need a Chief Unblocking Officer?
I admit the title is a little clickbaity — I was reminiscing over an ad from 15 or so years ago, that reminded be of unblocking…
I admit the title is a little clickbaity — I was reminiscing over an ad from 15 or so years ago, that reminded be of unblocking. Organizations looking for fast flow of value, can’t achieve flow if they are blocked.
Imagine having Terry Tate in your team or department to help you unblock work! (without the phsyical violence of course)
Back to regular programming…
One of the amazing things about the internet is when your passions cross-over with others. This happened to me recently as part of my exploration of teams, interactions, dependencies, and blockers.
I was thinking and starting to collect my thoughts for this article when I noticed that Nick Brown’s recent talk from Agile on the Beach was available to watch on the topic of blockers. I highly recommend you watch the video as Nick does a fantastic job of defining blockers, metrics, and observations.
“Dependencies are blockers waiting to happen “— Nick Brown
A few terms that are useful to define (do you agree with the definitions)
Impediment: something that slows you down, hinders progress (e.g. a sick team member)
Obstacle: something that gets in your way that requires you to navigate to overcome (e.g. a skeptical stakeholder)
Dependency: a situation that occurs when the progress of one action relies upon the timely output of a previous action or the presence of a specific thing. Taken from Diane Strode’s paper “A Taxonomy of Dependencies in Agile Software Development” (e.g. Team A requires Team B to setup a new Database for Team A)
Blockers: something that stops you from getting your work done (e.g. your test environment is down)
In my recent article (Individuals and interactions over processes and tools) I started to walk through several types of dependencies that exist, I didn’t get to explore how and when dependencies turn into blockers and what to do about them.
From a practitioner perspective, how do you nudge teams and leaders to solve not only the temporal nature of a blocker, but the underlying cause.
I previously mentioned Diane Strode and Troy Magennis in my last article. What I didn’t explore was the ability for an individual, team, department, or organization to resolve the blocker.
I went down the rabbit hole on this topic before I started this article. There’s a few ways to think about blockers (building on Diane and Troy’s contributions with a nod to Liz Keogh’s brilliant article on estimating complexity).
the work — does the team know how to do the work, does the team depend on other teams or resources, can the work be started or finished until other work is done first
reliance on individuals / experts — does the work require support from experts in other functions e.g. a Lawyer, a Compliance expert, Security expert etc. (if you don’t bring these people into the conversation early, they will become a blocker as they are not working on your team in most cases and they will likely be helping many other teams)
the team's capability — does the team have the necessary capacity and skills to complete the work
the environment / industry you work in, your architecture, governance, bureaucracy, regulations, laws, tariffs, etc…
world events / threats like climate change, financial crisis, natural disasters, wars, pandemics etc. are these blockers to the team or just external impediments?
Estimating complexity
From Liz Keogh’s article — estimating complexity — Liz’ 5 point scale on levels of ignorance / certainty of the work (apply this to blockers as well — how would you approach solving those blockers based on the below scale).
5. Nobody in the world has ever done this before.
4. Someone in the world did this, but not in our organization (and probably at a competitor).
3. Someone in our company has done this, or we have access to expertise.
2. Someone in our team knows how to do this.
1. We all know how to do this.
How do you manage blockers?
From Nick’s video, he offers a great approach at a team level and even across teams but hasn’t gotten to the bottom of addressing systemic / organization blockers. I expect this is something Nick is thinking through and will cover in a subsequent talk. I imagine this area could be explored in parallel to things like having flight levels in place with different WIP limits at each level, do you consider blocker WIP limits too.
How bad do things have to get, in a team, department, or organization before they become a priority to solve. If you want fast flow of work, you must unblock the systems of work.
“Impediments are not in the path, impediments are the path” — Jon Smart
The job of leadership is to help unblock, if you are in an organization where leadership is not actively looking to help and unblock work, they are likely to be flooding your system of work instead which will create more blockers and reduce throughput!
I’ve paraphrased Nick’s slide and added a few observations. Nick suggests checking out the new Kanban Pocket Guide.
how long does something need to be blocked to be considered being blocked e.g. hours / days etc.
how do you identify blocked items in your tooling (approach will vary by tool but it could be labels, attributes, swim-lanes)
how do you identify the blocker is (as opposed to just not being able to complete your own work)
how do you think about your blocked items in the context of a WIP limit
what are the conditions for closing a work item as being blocked for so long that you can’t see a resolution
how does your organization deal with blockers, do you have a mechanism in place to escalate blockers if they are impacting a teams ability to deliver
how are you creating transparency on blockers across the organization and what can you visualize (data wise) for people to act on them
what are the sorts of metrics that will get people’s attention to act on the blockers e.g. number of blocked items per team, number of teams blocked by the same blocker, average age of blocked items, lead time for items that have blockers vs those that don’t (thanks to my friends at Nationwide on that one) etc.
after a blocker is removed, and work can be completed, how are your teams reflecting or doing a PDSA on how the blocker came about, is it something that could happen again in the future, how could it be avoided and what would it take to fully eliminate the blocker in the future.
can you cluster the blockers into common cause for broader resolution, this can be useful when looking at larger bottlenecks (Troy Magennis also mentioned dependency clustering in his talks too).
That’s enough of a list for now.
Nick also introduced the notion of a Definition of Blocked (DoB), which I really like, equivalent to a Definition of Ready / Done. Really a small policy for the team to provide decisions based on context of a blocker. A subtle way to reduce cognitive load and help if someone else joins the team. This seems like a great place to start experimenting.
Evaluating options based on needs
Next we can explore common types of blockers and what options might help address them. Some free advice, there is no best practice in knowledge work. Practices are context sensitive and, in many cases, will vary depending on your teams knowledge, clarity of the teams goals and many other factors.
Anyone selling you a silver bullet, you should apply some healthy scepticism towards.