Two different ways to be Agile. |
I was introduced to Kanban when I was training in the Scaled Agile Framework for the enterprise. I did not think much about it at the time. It just seemed like a variation on a theme for managing work. I was wrong. Kanban is agile, but it is not a subset of Scrum. It is a different way to meet the principles outlined in the Agile Manifesto.
For those not familiar with Kanban, I strongly recommend Eric Brechner’s book on the subject, “Agile Project Management with Kanban.” Brecher is not some crazy theorist; he is responsible for the development of the Microsoft Xbox. In the book, Brecher not only provides basics; he provides the administrative know-how to make it work at your organization.
Unlike scrum which limits work with a timebox known as a sprint; Kanban uses something called WIP limits. WIP is an acronym for work in progress. The team can only do so much at a time, so WIP is the limit of that work. The team then moves work through a queue based on WIP limits. For example, if the team sets a WIP limit of five for development and a limit of three for QA when work meets the definition of done in development, it is moved over to QA as long as they are working on three or fewer elements.
It is obvious why Kanban would appeal to the “No Estimates,” crowd. Work breaks down as it moves through the queue and it does not require any estimates. Scrum rituals like backlog refinement and sprint planning fall away. Comparing Scrum and Kanban, it is obvious to me that Kanban is well suited to exist in architecture and software applications. Scrum is perfect for a greenfield project where rapid cycles show stakeholders how the project is evolving. I am glad that Kanban is another approach in the agile toolbox.
The agile manifesto says, “Individuals and Interactions over processes or tools.” Kanban is just another process and tool you can use to help your client achieve agility.
Until next time.
No comments:
Post a Comment