Being ‘blocked’. It’s not what You might think.
Who or what is blocked and why it makes a huge difference for knowledge work teams.
If you are working in an agile product development team, you are probably familiar with the term ‘blocker’. But what should be considered a ‘blocker’? In this post, I’m going to describe what ‘being blocked’ or having a ‘blocker’ has meant for one team and how this team’s understanding had bad consequences on their performance. Also, I’m going to present an alternative understanding of the term ‘blocker’ and how this altered understanding will help to increase team performance.
What is a ‘blocker’? You might say this is a no-brainer, however, recently I witnessed a team introducing a new colleague. One of the team members, let’s call him Pete, described the team’s current workflow and how they use their physical board to plan and synchronize. Pete said something remarkable. He said: “Here you have those ‘blocked’ stickies and you can use them whenever you are blocked, meaning whenever you can’t work any further.” That struck me. I haven’t seen any of those ‘blocked’ stickies on their board at all. How is that possible? If they encourage new colleagues to use those stickies why haven’t they ever been used?
The answer is inevitable. The team’s definition of ‘blocked’ is flawed. Being blocked should not describe that a member of the team is blocked! Instead, it should indicate a piece of work being blocked — the flow of work is impeded. It does not describe something that is blocking you or your colleague. Although this might sound oversubtle at first, it is a major difference.
In digital product development work, the realm of Pete’s team, the work that is performed is knowledge work. That makes Pete a knowledge worker. Knowledge worker create their own work. That leads to the fact, that Pete and his team can always create new work, preventing them personally from being blocked.
You cannot be blocked if there is always something to do.
When you take a closer look at what happens in a knowledge work team whenever they cannot make progress on a particular piece of work — let’s say because they are waiting for another team to support their efforts — you usually witness that the team immediately starts working on new issues.
Some teams add explicit ‘waiting columns’ to their board, to indicate that “they are waiting” for something or someone. That might help to make explicit that not only the team cannot make progress on that piece of work but the work itself doesn't make any progress either. Those ‘waiting columns’ were meant to create a sense of urgency in order to reduce waiting time and increase ‘flow efficiency’. However, most teams have a tendency to start new work instead to investigate the reason for the waiting time. In knowledge work, this is the easiest thing to do. The team just pulls a new issue out of the backlog and starts working on it. Or the team does something ‘important’ that is not too closely related to the actual piece of work that has been started and that needs to be done. This is usually the case if the team does not limit the amount of work in process.
You might consider this a bad behavior. But there are no bad intentions involved. It simply feels good to do something at work. It feels like being productive. So, of course, Pete is not ‘blocked’. It just wouldn’t feel right to Pete to say that he can no longer ‘do work’. And as you might know, there are always so many important things to do that are waiting just at your fingertips.
This well-intended behavior is problematic from a value perspective. The value of a knowledge work organization is usually not generated by people being busy but rather by getting specific work done as quickly as possible. The value manifests when all the work is done, e.g. when the user can use a feature. So, a real ‘blocker’ indicates that the piece of work is stuck, that it waits for something to happen. Although it is seldom exactly quantifiable in this situation, this waiting time causes costs of delay. Being ‘live’ late with a feature generates returns of a feature later. And I am not talking about the negative effects of multitasking or context switching which also have an impact on the lead time.
In that sense, an ‘idle’ developer is by far less problematic than an idle piece of work. However, Pete does not consider ‘reducing waiting time’ or eliminating blocker as part of his daily work. Why? Because he is a developer. ;)
So when using the term ‘blocker’, take the perspective of the piece of work. Is this piece of work currently blocked or is it flowing through the workflow freely with continuous value add? Does this piece of work have full attention all the time? If not then it’s blocked! This specific perspective on the term ‘blocker’ creates a different approach to identifying and handling waiting times. Since waiting times are always evil we try to reduce the waiting time as much as possible. This in return increases the time value added. This effort is expressed in terms of flow efficiency. The best flow efficiency would be 100%. This means no waiting time in the whole workflow. Although it is almost impossible to achieve this state you have to thrive for it in order to maintain a value generation engine that is capable of delivering value fast and responsive.
Using the term ‘blocked’ as an indicator of ‘people being blocked’ deludes you from the chance to improve your workflow. Take the perspective of the piece of work instead. As Scrum Master, Agile Coach or facilitator support the teams by asking if a particular piece of work is blocked and not if everybody is busy. Help to make waiting times explicit and reduce those times together with your team.
So that’s what Pete could have said to the new colleague in the team instead. “Here you see our Kanban board and here you have those ‘blocked’ stickies. Whenever a work item in process is waiting for someone to work on it, put a sticky on that work item. This indicates that the team needs to pay attention to that work item before starting new work. We generate value by delivering to the user and not by being busy. That’s why we consider finishing work more valuable than starting work. So please try to remove the obstacle that prevents the value adding to that piece of work. If you cannot remove that obstacle by yourself make a note and inform the rest of the team. This impediment needs the team's attention.”
What definition of ‘blocker’ does your team use and how do you indicate those blockers?
