From Scrum to Kanban, doing the legwork
May 7, 2012 § 2 Comments
I’ve enjoyed participating in the talks at Scrum Gathering 2012 in Atlanta. One of the most interesting was Steve Forte’s presentation on Kanban 101. I’ve been exploring Kanban as an alternative to Scrum at AtTask for a while now, but with our adoption of Continuous Delivery and the recent rollout of Feature Toggles, we may be ready to take the plunge.
AtTask has been an Agile shop for several years now… really since we had a team of appreciable size to benefit from the principles. We adopted Scrum as our methodology of choice, primarily because it along with XP was about the only thing that matched our legacy delivery model. While we’re still delivering features into production every 4 weeks, our CI pipeline has piqued the interest of folks within our organization who would like to see even more rapid build-test-learn feedback loops.
Kanban evolved from the Toyota production system, as a model for developing cars more quickly, while minimizing inventory and emphasizing just-in-time delivery. When it comes to software, Kanban is a model that eschews the traditionally time-boxed Sprint metaphor in favor of a pull-based system. Features are sized, and move through phases of production which are carefully limited in order to eliminate inventory (unreleased code) and maximize flow. With Feature Toggles, we’ve gained the ability to deploy virtually anything without affecting the customer experience unintentionally. Because releases are now managed by the business, we can create a Kanban flow which will take us from story conception all the way to deployment.
I think we may have a good first start with our customer bug-fixing team, since their work is inherently request driven, rather than time-boxed. Over time I’d like to see Kanban principles adopted more broadly across AtTask.