Waterfall Kanban

Kanban is a very lean, efficient process for getting work done.
Since Kanban minimized Work in Progress and makes bottlenecks visible, I thought it would be a great way to increase the flexibility of our software development.
Years back in 2008, when I just went through Lean Six Sigma training, I saw Kanban and the first thing that came to my mind, "Let's try this!"

Setting up a Kanban board is easy.
Explaining the concept of Kanban is also easy.
So, we started.

Initially, we did really well:

• Breaking down the work into bite-sized portions made analysis, development and test significantly easier.
• The high visibility of which topic was currently at which stage of the development process made managing the product easier as well.
• Working on a pull principle significantly reduced the stress associated with large projects.
• Seeing multiple cards fly through the board from left to right, getting things done at a rapid pace, significantly improved team morale

So, Kanban was a big success.

However, a couple weeks down the line, problems did start to set in.

What went wrong?

We did Kanban in a classical Waterfall approach.

The swimlanes we had were no "toDo, Doing, Done", but rather:

"Open, Analysis, Development, Test, Done"

Intitially, this approach was fine. Until the stories got more complicated. Then, test simply bounced back defective stories to Development. Some stories even came back to Analysis, because underlying assumptions were disproven in test.

We ended up with a whole mumbojumbo where the Development swimlane was plastered with post-it's and analysis and test were idling.

Lesson Learned

You can only prevent a clutter of stories in an unfinished position if people don't have to idle while other stories are being processed by other people. If anyone needs to wait for someone else to finish, your Kanban setup is doomed!

If you want to be successful with Kanban, you must make sure that you have "T-Shaped People", so that the team can support each other as backlog items move through.

Ideally, you do Pair Programming and the same pair is responsible for the story end-to-end, eliminating unnecessary handovers. Make sure that everything required to successfully complete the story is available in the team: skills, tools, information, ownership.