The 3 Mistakes I Made by Using a Kanban Blocked Column (+ What I Learned from Them)

If an item is blocked for weeks, do you keep it in the same column and allow it to occupy the WIP in that column, or is it more convenient to move it to a dedicated Kanban blocked column?

Back in the day, in my early years as a product manager, the main issue I was struggling with was how to reduce the amount of blocked work in our workflow. We were constantly discovering internal and external dependencies, and the time the work was waiting for a resolution was our main source of delays. The bigger problem was that blocking work became a routine and I didn’t have a clear strategy to address this challenge. 

What the Process Looked like Back Then

We had a dedicated Kanban blocked column to hold all the suspended work. If we discovered a blocker and we knew that it wouldn’t get resolved any time soon, we usually went with two options. We either moved it back into the backlog so that we could reschedule it or it was indefinitely positioned in our blocked column. 

Have you ever felt like you know that something isn’t right, and you know that there should be an alternative but you feel as though you are stuck between a rock and a hard place?

Today, when I look back, I realize how many mistakes I made by following this approach. Probably, part of the motivation behind that behavior was that we didn’t want to blow up the WIP limits for the columns in which the blocking issue was discovered.

The truth is, we didn’t need a Kanban blocked column altogether. Instead, what we should have done was keep the blocked item in the state it has occurred to emphasize the importance of the problem and we should have done our best to resolve it right away. Using a dedicated parking lot within the process actually introduced three much more serious issues to the bigger picture.

The 3 Issues Using a Kanban Blocked Column Caused

The answer to this challenge is not to send work that has stalled out back to the backlog or put it into a blocked column. And it took us quite some time to realize what we were doing wrong.

We Were Losing Focus On Delivering the Work

The first issue this approach caused was that we encouraged everyone to feel comfortable with the idea that it’s okay to start something and lose the motivation to finish it. Any blocked work item somehow felt like it was no longer our responsibility. This is the purest and worst form of waste that exists. 

Teams need to do their best to resolve the blockers in the workflow, and stakeholders need to be sure that if an idea is valuable enough to start then it’s valuable enough to finish. There are exceptions but they should be exceptionally rare.

We Couldn’t Make Accurate Delivery Commitments

The second issue was that it became very difficult to measure the actual amount of time it took to complete work that was started, returned to the backlog and then started again later. 

The thing is, we shouldn’t be interested in the aggregate amount of time multiple people work on something. What we want is to measure the amount of time the work takes from starting to finishing – the effort time plus the amount of delay that the work experiences.

When you destabilize your ability to measure delivery times, you simultaneously destabilize your ability to make probabilistic forecasts. So, you are stuck making commitments using intuition or gut feeling. And using intuition or gut feeling as a primary method of estimation rarely produces reliable results.

We Were Killing the Joy of Work Well Done

The third issue is that rework is a morale killer for a team. Starting, pausing, restarting, stopping, then starting again… when a team who works hard at something realizes that their work won’t see the light of day, the motivation and dedication levels go down. And when the motivation and dedication levels go down, the quality of the deliverables goes down as well. 

Rework, or work that is shelved pending and eventually closed as “Won’t Do”, is an engagement killer for anyone that puts their heart and soul into a job.

In Fact, There Was a Fourth Issue as Well…

The fourth issue was that our Kanban blocked column didn’t have a WIP Limit. An “in progress” column without a WIP limit is a black hole. I’d even go further – a Kanban board with columns without WIP limits is not a Kanban board.

Perceive Your Workflow as a Knowledge Discovery Process

Your workflow should represent your knowledge discovery process. It should contain the activities that your team is performing to deliver customer value. Having a Kanban blocked column contradicts the nature of a workflow. It communicates that blocking work is a standard step in your delivery process.

By discarding the Kanban blocked column and keeping the blocked cards in the column the blocker occurred, you are occupying WIP and, therefore, keeping the attention on the impediment that slows you down. It is better to allow the WIP to continue to be consumed so the team can focus on unblocking the issue (that could even mean lending a person to a different team who is responsible for solving the problem). 

And, if you are in situations like this all the time, it’s worth considering refusing to start any new work if there is a reasonably high chance that it will be blocked midstream for a long period of time.

Furthermore, emphasizing the amount of blocked work and the delays caused by it will actually trigger opportunities for improvement. It’s a real eye-opener when you see the gap between the effort time and the actual time it took to deliver the work. Removing the obstacles that prevent the work from moving further should be a priority. That approach is essential to managing blocked work effectively and identifying areas for improvement through blocker clustering analysis.

Last but not least, treat your defects in the same way you treat your blockers. Defects can be managed like blockers to investigate their root causes and solve them in an economically sensible way.

If you’re interested in learning more about the proven practices of managing work effectively and establishing a stable predictable delivery system, I’d be thrilled to welcome you to our Sustainable Predictability program.