There seems to be a growing amount of discussion around the Kanban approach to software development. For those of you who, like me, had never heard of Kanban, it has its roots in Japanese lean manufacturing concepts. I read a great article titled “Kanban Development Oversimplified” by Jeff Patton. If you are interested in the Kanban way to organize your development then give this a quick read – it is well written and starts off with a good look at the origins of the Agile methodology.
From my perspective, having now done a little research into Kanban, the approach is very similar to something I practiced back in 2002 while looking after storage products for BMC Software. In my opinion, Kanban is a great process for software product companies who want to drive efficiency across their product delivery process. However, it is not ideal for corporate IT shops who are working on improving their application development processes and better alignment with the business.
Even though I’m an Agilista at heart, I believe we can learn from the Kanban approach, however, there are some things that just don’t seem like a good practice. For example:
- Lack of Iteration: Kanban doesn’t include an iterative approach – which I feel is one of the key Agile tenets that delivers real benefit. It allows us to continuously align with the business and deliver exactly what the business wants – regardless of the set of requirements we started with. Invaluable in my opinion.
- No commitment to deliver: Without iteration and time boxed sprints you never have the opportunity to set expectations and then meet them – ‘deliver early and often’ as we like to say. This is critical to drive business trust and Agile adoption.
- Writing Larger Stories: Kanban proposes writing larger stories around the concept of a minimal marketing feature (MMF). Once again, a concept that makes a lot of sense for software product companies in the commercial software world. In my experience, writing larger stories results in longer development cycles for a feature, resulting in the opportunity to wander off the path before a user sees what you have done. Historically we have never managed to get the MMFs correctly defined, which results in rework and extra costs. The approach of developing some of the functionality and then getting feedback is a hallmark of Agile and leads to better business alignment by allowing the team to react to change from the business. This works better with smaller, role based stories.
Even with these shortcomings, Kanban’s lean manufacturing approach is interesting as it should really help a team identify process bottlenecks, and I suspect could be applied in a more Agile manner of development.
I am sure you all will have lots more comparisons and thoughts on how Kanban could make your Agile approach better. Let us know what you think!