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.
Subscribe to:
Post Comments (Atom)
Of course there's no silver bullet. There never was. Neither Kanban nor Scrum is one. Neither agile nor lean is.
ReplyDeleteTalking about Kanban, there's one very cool feature of this technique - it is totally light-weight and can be use as an addition in many situations without chaining your current methods much. But of course Kanban, like any other methodology, needs to be implemented when it does make sense.
There are environment where it can work very well as main method although I'd strongly advise to use some engineering best practices. Otherwise you can have hard time keeping high quality. But it isn't different than anything else - you can easily misuse Kanban like you can misuse every other technique out there.
Having said that I always preferred slow but systematic adjustments of current methods (whichever they are) than replacing one worn silver bullet with another shiny one. The latter virtually never works.
Think of kanban as a visualization layer to what you do. Kanban is not a process. It is a tool. The difference when you are using Kanban is that it promotes Lean techniques which, in conjunction with Agile, can produce some remarkable results.
ReplyDelete