Stop Using a Blocked State (Column)

Imagine a software development team cruising along, work is going well, then bang! An unexpected situation arises, causing work on one of your work items to stop.

There are several reasons this could happen including the discovery of a surprise technical unknown. It could be the team encounters an unexpected dependency on another team. Or even that a very high priority interrupt occurs and you need to redirect effort from a current item to handle the new item.

Something that I’ve seen both Scrum and Kanban teams use in these cases is a Blocked state, or column. The current work item that is being halted moves to this state. Here are some reasons this is a bad practice.

Artificially Lowers WIP

The current state represents work-in-progress. By moving the work item to a different state you are lowering the WIP in its current state. This does not reflect the reality that the team spent effort on the item and that it’s still at the same point in the process. It still has the same priority.

Your board should reflect this reality. The work is still at the same level of completeness it was before becoming blocked. Full transparency, right?

Moving the work item out of its current state will open a slot for additional work to be pulled into that state. While this may sound good you are redirecting effort away from resolving the blocker to begin even more work.

Which can lead to…

WIP Overload

After a blocking issue resolves the team will move the work item back to its former process state. But teams are already likely at, or even above, their WIP limits.

Moving the item back to an at capacity or overloaded state will increase delay caused by the additional context switching necessary to juggle another work item.

It Jacks Up Your Tooling

Please understand I’m not promoting tooling over people and conversations. So don’t jump on me for that.

It’s a fact that nearly all teams use some form of ALM (Agile Lifecycle Management) tooling. I don’t know of any team that is only using physical boards. So consideration must be paid to the effects of practices on the accuracy of the tool and its underlying data.

By moving the item out of the state the tool will stop accumulating time within that process step for the item. This will hide information from the team as they work towards creating a smoother, more predictable, process flow.

The team should be accumulating all time for each blockage. This includes tracking where in the delays occur. These items will likely become the outliers in a Cycle Time report putting focus on them as the team reviews their processes and Lean metrics.

Additionally, moving work items back & forth on the board will create “loops” in the tooling metrics likely causing confusion when researching issues. It can create odd looking Cumulative Flow Diagrams which are hard to decipher.

Normalizes Blockers

Creating a formal process to move blocked work items to a separate column lessens the urgency on resolving the cause of the blockage. In effect, you are creating a workaround.

The funny thing about workarounds is that they tend to accumulate. And, before too long, workarounds become how we do things around here. They become the normal, approved process.

If the topic of blockers does arise in a Retrospective type conversation they will likely be dismissed in this situation. The reasoning is “we already have a solution for handling blockers”.

Blocked items no longer become an abnormality to resolve quickly. They become routine, a normal thing to expect. Doing a deep dive and resolving the actual causes is unlikely to occur.

Some of you may be familiar with the fable of the Little Dutch Boy who plugs a dike with his finger to save the village. Never do you hear about the villagers fixing the dike and removing that temporary solution.

The same thing happens in most companies, workarounds become acceptable solutions to many dysfunctions. How many Little Dutch Boys do you have in your organization?

Use a tool such as Blocker Clustering to analyze blockage data and resolve the root causes.

A Place For Work To Die

Finally, another great reason to not use a Blocked column.

During Standups and other events teams overlook this column. “Those items are blocked, let’s skip over them”. Or a cursory status update, “yep, still blocked”.

Rarely will a team discuss actions for TODAY that will unblock the items. Rarely do actions make it into the daily plan to remove the blockers. The team is too busy focusing on “real” work instead.

Review your metrics, how long, on average do work items remain in Blocked? How does that compare with other process states?

The longer a work item remains blocked the higher the associated risks. Integration will likely be more challenging. Circumstances can change which make the effort no longer viable as originally planned. It will take far longer to pick the work back up when the blocker clears. Relearning and rework may be necessary.

Doing Away With the Blocked State

Leaving items in the state where they became blocked will allow you to gather accurate data. You will be able to analyze the impact on flow where the delays occur.

Add a tag to the work item, turn the card a special color in the ALM, add another form of decorator as appropriate. But leave them where they are in the workflow.

It’s important to “keep the clock running” when blockages happen. If you don’t you will not see the negative impact they are having on your cycle and lead times.

These will likely become outliers if not handled quickly. If that happens you want to see the effects, not hide them. Otherwise your forecasts generated from your Lean metrics will be inaccurate. You will likely form SLAs or SLEs using data that is too optimistic.

As they say, past performance is no guarantee of future results. If you are not measuring the impact of blockers accurately that will certainly be true. Forecasts generated using information like Cycle Time should reflect reality, not wishful thinking.

Use techniques such as Walking the Board Standup or The Aging WIP Standup to examine the blockers. If the team has many blocked work items dedicate an entire Standup and only review those work items. Create a plan to resolve them, not put them off once again to discuss later.

Still not convinced? Create an experiment, give it a month or two. You will likely see two results: the number of blockers dropping since you are purposefully solving root causes and improved predictability.

If you found this article helpful, please click on 👏 and follow me for more valuable information on Agile, Lean and Book Reviews.

Until next time!