For years, many people have considered Scrum to be the default starting point when talking about Agile implementations. In fact, many often mistakenly believe that Scrum and Agile are the same thing. The popularity and wide adoption rate of Scrum has made it the default Agile choice for many organizations.
However, with the recent rise of Kanban, some now see Kanban as the next step in the evolution of Agile.
Abby Fichtner recently went so far as to state that Kanban is the New Scrum,
Maybe it’s all the time I spend with startups, but while I strongly value Scrum’s ideas behind self-organizing teams & continual feedback – I can’t help but feel Kanban represents the next level of agility, giving us more flexibility and capitalizing on the lessons we’ve learned from Lean.
The biggest problem Abby sees with Scrum is having time-boxed sprints,
Working with startups, Scrum sprints are almost always way too long. When your sprints are too long then releases are infrequent (deferring revenue) and the team is forced to wait too long before being able to adapt to changing customer needs. This is wasteful because it means you’re continuing to move forward with outdated information.
On the other hand, if sprints are too short, big features need to be arbitrarily chunked into smaller tasks, which aren’t useful to the customer on their own & can obfuscate what the team is trying to achieve
Abby suggests that since Kanban has no sprints and instead relies on limiting work in process (WiP), two things happen when a feature is complete,
- The feature is available for immediate release into production (should the team wish to do so)
- The team can start working on whatever the next highest priority item is. Even if that item was just learned today!
The result is more feedback with the ability to adapt to that feedback faster.
Erwin Verweij disagreed. On Scrum, he said,
[The team] can decide how to do the work the best they can. The pressure is gone. The team estimates work and there is a clear view of what can be done and what not. I know that most project managers like to have control. And losing that control, even though it is a fake kind of control, feels as though they are left out of the process.
Then there is Kanban. And Kanban gives back this control. There is a visual workflow that project manager’s love and understand. Kanban does not say anything about speed or what can be done within a given time, so project manager can start pushing again.
There is a very big risk that nothing changes. Project managers can still keep on the pressure and start pushing forward. They can get their waterfall moments as it is possible to divide the project in work columns (design, development, testing etc).
Lisa Crispin, whose team started with Scrum, but now uses practices from Lean, Kanban, and XP, had this to say,
What has made us a great team is the true ability to self-organize. Every two weeks we have a retrospective and we sincerely want to improve.
I think it comes down to the company being focused on quality, and letting the development team figure out what it has to do to deliver the highest possible quality software product.
Derek Huether added,
I think more organizations need to know that Kanban is a viable alternative to Scrum. As long as we continue to empower our teams, maintain a good cadence, and go light on ceremonies, I have little doubt that more teams will be adopting Kanban over Scrum as their preferred approach.
George Dinwiddie has found some common ground between the two,
Kanban focuses on limited WIP and suggests a short cycle time. Having regular cadences is recommended. Scrum focuses on short, regular cadences and suggests limited WIP. If you're doing them well, both paths lead to the same place.
Abby concluded with,
I still believe Scrum contains excellent ideas – like self-organizing teams & continual feedback – that we shouldn’t just throw out with the bathwater. But, these same ideas continue to work with Kanban’s scheduling.
Is Kanban the next step beyond Scrum?
