Is Kanban the New Scrum?
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.
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.
[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.
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?
This is not a case of evolution, but a case of alternatives.
Release cadence vs. rhythm of planning and review/retrospective
However, IMHO the release cadence is not a defining element of Scrum. If the team is up to it, let them release everything as soon as it is done.
More important than the release cadence is the rhythm of planning and review/retrospective. There are real (if non-obvious) benefits from timeboxes with planning at the beginning and review/retrospective at the end. (Check out Richard Hackman's work on teams, or Don Reinertsen on knowledge work expanding like the perfect gas in physics, or Yuval Yeret's recent blog post on learning and expectations.)
I got in touch with Abby Fichtner, and she said that she actually recommends some kind of light-weight planning cadence as well.
Odd choice of Title
Kanban is an excellent tool for helping your teams understand their work flow and improve it.
Scrum is an excellent tool for helping to create highly productive teams, that can work at a sustainable pace.
Each tool is good for different purposes. When I leave the house to do client work I ensure that my toolbox has many tools Kanban and Scrum among them.
I think the title does a disservice to the readers.
No need for the New keyword!
It's the same thing with our tools and processes. As long as we don't master Scrum there is no point in jumping at Kanban. But being good at Scrum you realize that elements from Kanban can be brought in to improve your Scrum process - retrospective by retrospective.
Our software processes, like our code, should be ever evolving. Be open, experiment, use what works for you, and refactor
Scrum for Startups
Have the Product Owner as a team member is also an option.
The whole point of self-organization..
Great teams get things done. Period.
Just adding fuel to the fire with no real reason
Small reminder : "OVER PROCESSES AND TOOLS"
both Scrum and Kanban are processes and while they are important, focusing the discussion on which one is better completely misses the point.
I personaly feel that this battle between the methods has already gone too far.
I want to make a request from thought leaders from both "sides". Please, join hands and instead of fighting each other, start working together and try to influence the non-agile thinkers in the world.
Re: Odd choice of Title
I think the only people who care about whether Scrum is better than Kanban are people make a living out of selling one them exclusively.
A slight word of caution though. Many people think of kanban as the visualisation of queues (either explicit or in the form of blocked items). Apparently this is not Kanban. Kanban requires explicit WIP limits, which I have come to think of as a coercive management technique ( along with CFDs which are a command and control management technique). To help with clarity around this issue I have started to refer to the board as a "Visualisation Board" or "Scrum Board" (as I suspect people in the Scrum community were the first to invent such boards without the WIP limits)
Is Kanban the New Scrum?
Re: Just adding fuel to the fire with no real reason
Moving beyond both
However neither was designed for, nor is particularly well suited for, software development.
We should focus on creating processes for software, not stealing them from outdated factory management methods.
I have a writeup on this here: jordanbortz.wordpress.com/2011/08/08/is-the-agi...
"...that we shouldn’t just throw out with the bathwater"
Like Agilists throw out tools thathave worked in more heavyweight methods such as RUP and even some waterfall.
"Over processes and tools"
Which I would counter with the very last line of that manifesto that a lot of devs claiming to be agile forget. It is not that there is no value in the items to the 'right' (after the 'Over' word), it is just they value the items on the 'left' more.
Remember Kanban's roots. It is manufacturing. Even in product development the idea of a Kanban is the 'signal' not the board, not the method. Kanban is part of much bigger field of JIT and lean principles. Just-in-time techniques have the primary aim of reducing waste, NOT necessarily delivering quicker. You can be agile without lean and generate just as much waste in terms of rework as BUFD generates in lost time (bearing in mind for a business, the result is the same. Wasted money, including opportunity losses).
One problem with strict SCRUM sprints, is it introduces 'under-runs' in the flow. You aim to commit to getting X, Y, Z features across the board and focus on getting those across, the left hand side of a board starts to have nothing in it. This gap time could be better filled bringing other tasks in, otherwise you are limiting your velocity from above (i.e. you can't get confidently quicker, otherwise you are picking figures to commit to out of thin air). This can include technical debt and thinking process improvement.
As most development teams don't really understand the benefits of Kanban in a true sense, Kanban can lead the team to break down tasks into too small columns or add columns where they are not needed. The 'context switch' caused by the task moving from column to column (which people forget occurs) happens but the value added by these tasks moving doesn't change. For example, a QA and a 'Stage' column, when the environment is the same or the software is the same. This means there is a waste of the context switch getting it to Stage, for no value over and above a 'QA' process (as they are used for the same thing). So that actually introduces waste and not reduces it and is a consequence of the tasks being 'too small'.
Some hybrids (such as SCRUMBAN, or others or shortening sprints to the tasks done) eliminates that dead time and improves overall flow in the same way as Kanban can. So it can result in the same thing.
Re: Odd choice of Title
Based on my experience, the tool matters only to those organizations which feel that things aren't going that well, but have no idea what it is and how to fix. After it is done either with Scrum or Kanban they'll continue to work according to their own modified process or without any process at all. So, for me Kanban is not a Scrum replacement, but another way to find our what's wrong like Mark's tool metaphor.
Yes, actually it is
"I loved Scrum when I first learned about it, practiced it, and defended it; but as I've studied and practiced further, I've come to realize that Scrum is a sub-optimization of the engineering/development team. Further, its time-boxed iterations are artificial in nature and disconnected from the business environment. I'll take continuous flow, iteration on features, and release on-demand anytime over the jerkiness of Scrum's start stop start stop start stop start stop... "Sprint" should be renamed "Spasm". I know a lot of the Kanban community likes to co-exist with the Scrum community, and not have infighting within the broader agile community. I don't care about that. The funny thing is, that even though Kanban was not marketed as a replacement for Scrum, those that truly understand and value lean principles will gradually ditch Scrum on their own, just as I have done. So I've moved on. Thanks Scrum for being a great stepping stone to something better."
I've discussed with experienced software developers the topic of why they are threatened when there is talk about Kanban as a better way. The conclusion we came up with is that Scrum is a security blanket for developers. The time-boxed iterations make them feel safe, even though time-boxed iterations are disconnected from reality (which is probably why it makes them feel safe). The solution to this is for organizations to reflect on their culture and environment and change whatever it is that makes the developers feel unsafe. Then they can ditch the meaningless time-boxes and finally go to the next level. Let's face it, most developers really like agile (at least in my circles) and Scrum is their first love. It's hard to imagine life without it. So this aversion to Kanban is a psychological phenomena.
The final thing I'll say is that both Scrum and Kanban can be done in a less than ideal way, and when done poorly they have the equal potential to suck. However, ideal Kanban and ideal Scrum are not equal in positive potential. The former surpasses the later, which is why Kanban will continue to gain mindshare at Scrum's expense.