- Scrum is a process framework for product development. The Scrum Guide says so. And the Scrum Guide pretty much is the official definition of Scrum.
- Kanban is an approach to process control and improvement. David says so. And he is the one literally defined Kanban for knowledge work
Scrum is defined by a specific set of roles, events, artifacts and rules that can make up a software development process when the specifics for your given context are resolved and defined.
Kanban on the other hand, provides mechanisms for controlling your work and improving the way you work together with a set of principles and practices like visualization, limiting work in progress, managing flow making policies explicit and a couple more.
Kanban does not provide counterparts to the things Scrum provides – rather, it is a complementary approach to any product development approach.
You can easily build a Kanban system for any given Scrum implementation – most of the time you just have to model four or five states, identify one to three capacities and define the cadence for the input queue and the output queue. A very simple approach here is to define the
- Stations as “Backlog”, “Selected”, “Implementation”, “Review” and “in production” (and make them visible)
- (bracket) capacity of “Selected” through “Review” := throughput of last iteration
- input cadence := output cadence := iteration size
- iteration size := your sprint size
Of course the real power of the Kanban approach only begins after this stage, when you start to improve the way you work together collaboratively. But that would be another post…
Most of the time the processes inspired by the Kanban approach end up with a much more flow-based solution than typical scrum processes, and that is what a lot of people seem to mean when they talk about their evolution.
But please don’t talk about “moving from Scrum to Kanban” – that would be like saying “I don’t use a car anymore, I now use a GPS” – and you wouldn’t say that, would you?
till next time