Kanban is NOT King

I was chatting with a client the other day, and he asked about "replacing Scrum with Kanban."

I've heard even Lean or Agile evangelists say that Kanban is the next big Agile thing; that it replaces Scrum and XP. Unless I've thoroughly misinterpreted "kanban" I have to say this is a marketing ploy at best, and potentially a dangerous recommendation for your team. These folks are claiming they've found the Silver Bullet again?!

Kanban: A Powerful Technique

Kanban is a technique (or practice) taken from Lean manufacturing. Kanban can limit the queue size at each point in the process, and thus limits work-in-progress (WIP). For a software product or IT team, this is often done using a kanban-board, which looks similar to a Scrum or XP status board, but each column of the board is a state in a story's development lifecycle (e.g., ..., Elaboration, Needs Acceptance Criteria, Estimation, Automated Acceptance Tests, Development, Ready for Acceptance, Accepted, Ready for Deployment, ...). Each column is limited to a certain number of story cards (the WIP limit). This WIP limit reduces WIP and thus the wasteful "inventory" of incomplete functionality.

Kanban and Agile

At Agile 2009, I had the pleasure of attending Josh Kerievsky's talk on kanban, and he described how his team uses this technique to effectively supplant the XP "Planning Game" or Scrum planning meeting. Not the whole methodology, but just the planning. Oh, and iterations: Industrial Logic releases whenever a feature is ready, whether it's finished on Tuesday or Friday.

Using a Kanban board to allow the continuous flow of value is a technique that will work wonderfully for teams who are very good at prioritizing work, delivering fully completed and tested stories, and integrating and deploying on a very regular basis. If the product is constantly getting better and the users barely need to lift a finger or click a mouse button to receive those updates, what need for release plans or iterations?

But not all teams are ready to adopt such a technique, and there are products that do not call for such fluidity. So how could kanban be the one-size-fits-all, ultimate process?

It isn't.

If Not Kanban, then What?

Give up the hunt for the One True Agile Process. Stop looking for something that all your teams can follow to the letter, forever.

An actual Agile process needs to include mechanisms for process-improvement (from Lean) and constant vigilance towards finding constraints and improving throughput of value (from the Theory of Constraints). Continuous, incremental process improvement may lead your team to a kanban approach. Or, it may not.

So, you may not ever get to sit back, stop thinking, and simply enjoy the fruits of your efforts. Sorry. Fortunately, the benefits of a well-running Agile team are numerous, and apply to the organization and everyone on the team. What is required is frequent reflection on what is working and what is not, and careful consideration of what really needs changing. Learning about new--or newly tested--techniques is truly beneficial, but if you send your team after every Silver Bullet, they'll be expending energy needlessly.

Keep the high-bandwidth channels of communication open, and trust the team to know when something is wrong, and to give suggestions on how it can be fixed. Let one of them bring up kanban, and then discuss it.