The Kanban board: you’re using it wrong
Today, just like most days now, I went for a walk after lunch. Being a full time member of the cult of productivity, I started listening to audiobooks, so that I can learn at the same time.
I like listening to audiobooks, because it frees me up to think and reflect at the same time. That way, I get more “Aha!” moments. Today, however, it was more of a “Oh, no!” moment.
I was listening to The Phoenix Project, and the painful realization came to me when the narrator was reading the chapter that was touching on the principles of lean manufacturing. The protagonist managed to assemble something akin to a Kanban board, but he still couldn’t see what he was looking for — the bottleneck.
Lean IT
More and more people are using the wonderful Kanban board to visualize work in IT. I too have grown to love it, because of its amazing feature to clearly show what’s happening. You can easily see who’s working on what, what’s stuck, how the work is progressing and whether you’ll meet your sprint goals.
That is great! But also, exactly the problem. We were too focused on the sprint, and not focused enough on the value we were delivering to the business.
Working as a development team, we would work on developing and testing features, technical investigations, and fixing bugs and production issues. All these were visible on our Kanban board. But if we’re being honest, our work comprised of much more than developing and testing features.
Our Kanban board looked something like this:
Left to right there were columns named: to do, impeded, development, code review, integration testing, regression testing, smoke testing and done.
Not terrible, but not great either. I bet we could do better than that.
Long before ready
First let’s take a look at the left side of the board. Our work did not begin when tickets are ready to be developed. It started when they first appear on the backlog. They needed to be read, refined, investigated, prioritized and planned for. So there are at least three columns missing left of the to do column. These are backlog, refinement and sprint ready.
If we move out of the mindset of sprints, we could easily see that sprint ready and to do are redundant. What both of those describe is ready for development stage.
But what is the factory equivalent of ready for … stage? In my mind it’s like a stack of raw materials in front of a machine. In other words — it’s not work. So I don’t think it deserves a column.
And while we’re cleaning up, code review should be done during development, so it’s a part of the development step. Also work could be impeded at any stage of the delivery, not just during development, and more importantly — it’s not work, so it shouldn’t be represented by a column.
With these changes, let’s see how the board might have looked like:
At other times it surely looked like this:
Do you see how this may have affected our work?
Not really done
Now let’s look at the right side. When we finished our work, that didn’t mean the features we delivered were in production. It meant that we tossed it over to IT and QA to deploy and verify it.
To see that part of the picture, we should have added at least one more column — acceptance testing. Now the board would look like this:
This would have been a much more accurate picture, because the only work items that create value are those that reach production, and only then could they be considered done.
There can be only one
At some point we decided to improve visibility of production issues, by flagging them as high priority with a label expedite. This created a separate lane for these issues on our board. This might have caused more harm than good, because it created a false sense of having another work stream. Only there wasn’t one. There was one team and one work stream, and the production issues were competing for space in the same pipeline as stories, spikes, and other tickets.
Some production issues were of low priority, so they ended up in the backlog, pilling up like logs in front of a lumber mill, without us really noticing. And, how could we? We spent most of our time looking at our zoomed-in Kanban board, making sure we finish all the work that we committed to in the current sprint.
Having these issues in the same lane, might have highlighted the obvious fact that the work was pilling up.
The complete picture
Ideally by having a better picture of the actual process, we could have focused more on the flow of work and less on the sprint commitment, which would ensure that a constant stream of value was reaching production.
Moreover, by seeing the whole pipeline, we would have a better idea of where our bottlenecks are. We might have been planning too much work, or pilling up tickets on acceptance testing, all the while developing new features that are also going to get stuck there.
I will definitely try to have a more wholesome view on the Kanban board on my next project. And with the flow of value directly in sight, who knows — we might find that we don’t even need sprints. Wouldn’t that be a relief?
How did your Kanban board look like? Did I miss some steps in the process? Are there too many?
Let me know in the comments. I’d love to hear your opinion.
