Impeded work in kanban is a “critical error” state, not “waiting”

During a discussion about a WiP (work in progress) limit for the “development” column of our kanban board, a question appeared: what should we do if a story is blocked for some reason during development?

My answer was to mark the impeded story with some eye-catching token (e.g. big, red exclamation mark), “stop the production line” and focus on un-blocking the story as quickly as possible.

This raised a lot of doubts. Why should we stop the production line in such a case? Why can’t we simply multitask for a moment and work on another story, letting the impeded story “hang” idly on the board until it becomes un-blocked?

I said that we can’t take another story, because the development column is already full and we would break the WiP limit. This was, I admit, a dumb answer, focused on the board mechanics instead of the underlying reasons. And, what was inevitable, it resulted in a discussion about solutions also focused around the board mechanics.

Because of some delay between specifying a user story and its development, on our kanban board the “development” column is preceded by “waiting for development”. One of the proposed solutions was simply to move the blocked story back to the “waiting” column, instead of marking it with an exclamation mark token. First of all, the board design would be simpler, without additional tokens. Second, it would neatly solve the “stop the production line” problem – the story moved to the “waiting” column would no longer break the WiP limit on the “development” column.

Of course, I quickly explained that this idea is wrong and that waiting for development and being impeded during development are two completely different states. However, I didn’t have time to properly explain why. So let me do it now:

Imagine a car factory. After being molded into proper shape, parts are painted and then dried. But it doesn’t happen instantly – between molding and painting there is a “waiting” step, when parts are stored in a warehouse.

Now imagine that a part was taken from the warehouse to be painted, but it was only half-painted, because there was a malfunction.

Do we have to stop the line and fix the problem? Maybe we can “multitask” and just start painting another part? Of course we can’t. The half-painted part will occupy space on the line, making painting another part difficult or even impossible. And we can’t just dump it on the floor, because it will catch dirt and the fresh paint will be destroyed.

Can we move the half-painted part back to the warehouse, then? We could pretend that this part waits for being painted, as if it was new. Again, no. We can’t move a wet part to the warehouse – we would damage the paint as well as make a lot of mess on the shelf. What’s more, even if we could somehow put the part safely on the shelf, in a few hours the paint will dry, making it hard to finish the painting process later without leaving a visible line between the old and new paint.

The only option is to fix the malfunction and either finish painting the part as quickly as possible, or to throw the part away.

The software development process is, as counter-intuitive as it may seem, not that different. It’s hard to pause a story in the middle of the development and then to continue it later.

The most obvious reason is unfinished, unstable code. Such code can’t be merged into the main code base. To be able to work on another task, a developer must stash it or keep it on a separate branch. It isn’t such a big problem by itself, because most VCSs make it easy. The real problem is finishing and merging the code later. Because we allow another stories to be developed while the work on a blocked code is paused, there is a high chance that some common parts of the system will change, and the merge will result in conflicts.

Another reason is all the mental work the developer did. If he is in the middle of coding, he probably already analyzed requirements, constructed a mental model of the problem in his head and has a vision of the solution and the design of the code. When he will switch to work on another story, most of that context will be lost. And building such context – what again may be not intuitive – is the hardest and most time consuming part of the development.

What’s more, if we let the developer start another story, we can’t guarantee that when the original story is un-blocked, it will be continued by the same developer. And for a different developer picking this story up will be even harder, as he will not only have to build his mental model from scratch, but also he will have to fit this model into another, often clashing, model already present in the unfinished code.

As we can see, work that is already in progress, can’t be treated lightly. Blocked work is not a normal phase of the flow – it is a malfunction, a problem that should be handled almost with such a priority as critical errors on production.

How about you? How do you visualize and handle blocked work on your kanban board? Please share below in the comments!


What do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s