Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Is Kanban the New Scrum?

Is Kanban the New Scrum?

Leia em Português

This item in japanese

Lire ce contenu en français


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,

  1. The feature is available for immediate release into production (should the team wish to do so)
  2. 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?


Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Beyond?

    by George Dinwiddie,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Saying (or asking if) Kanban is the next step beyond Scrum misses the point. You can get to either without going through the other. Neither is inherently better than the other for all situations.

    This is not a case of evolution, but a case of alternatives.

  • Release cadence vs. rhythm of planning and review/retrospective

    by Jens Meydam,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    It is often natural and convenient to have a regular cadence of releases. (Even for startup-like shops - hey, a week is not that long. There are cutting-edge design-thinking shops with a weekly release cadence.)

    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

    by Mark Levison,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    To suggest as the title did that Kanban might beyond Scrum misses much of the point. Kanban and Scrum are both tools, they work well in different contexts. But its like saying a Screwdriver is tool beyond a Hammer because it was invented later.

    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!

    by Thomas Tarnow,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Why do we as software developers love the New word so much. Perhaps because we are so bad at refactoring our code that we are used to throw everything away once in a while - just to clean up the mess an get a fresh start. Then after about a year the new code base is as ugly as the old one and history repeats.

    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

    by Stefan Roock,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Here is a possible "Scrum fir Startups" perspective: Have weekly Sprints. Release severals times a day during the Sprint. Have Daily Scrums every 90 Minutes. Learn from the real users feedback during the Sorint Review. Decide in the Sprint review if you want to Pivot. Then do the retrospective. During Sprint Planning plan the goal/direction for the week, not the Stories and Tasks.
    Have the Product Owner as a team member is also an option.

  • The whole point of self-organization..

    by Roopesh Shenoy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The whole point of self-organization is that the team will adapt its' own processes, so after a couple of months, the team might have something that looks nothing like scrum/kanban. As long as the doers get the choice of how to do things, and the owner gets to choose what needs to be done, things will go fine. Its great to borrow principles from different methodologies, but trying to enforce a (agile?) process from outside is ridiculous if you truly believe in self-organizing teams.

    Great teams get things done. Period.

  • Just adding fuel to the fire with no real reason

    by Elad Sofer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This article, it's title and it's content is very troubling.
    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

    by Chris Matts,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    What Mark said.

    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?

    by Aslak Hellesøy,

    Your message is awaiting moderation. Thank you for participating in the discussion.

  • Re: Just adding fuel to the fire with no real reason

    by Dan Tines,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Elad, agree with everything you said about people over processes. I would put thought leaders in quotes too though. Remember, consultants think buzzwords and new processes translate into billable hours.

  • Moving beyond both

    by Jordan Bortz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    As other's have pointed out they are different with different goals.

    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:


  • Yeah right.

    by Ethar Alali,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Some of the rhetoric is fantastic here:

    "...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: Beyond?

    by Guy Winterbotham,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That's what we found. It's all about context. We started with Scrum when there was high uncertainty. As the platform matured more of the work came from enhancements leveraging the configurability we designed in. Not being on the critical path meant we didn't set the cadence and had to become more response. We flipped to Kanban. WIP limits kept us in check. Our cadence was governed by the need to release to downstream teams. We balanced the transaction cost of a release against the value we had build up. It felt like a better fit. But at times where the we received new epics we once again yearned for the fixed sprints to provide well defined checkpoints.

  • Re: Odd choice of Title

    by Zsolt Fabok,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think the business and the environment should determine which tool is best for an organization. However, Kanban doesn't work on its own, it requires an underlying process like Scrum, XP, Waterfall etc.

    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

    by Tim Elton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I can't believe I missed this article, because this is something that I really feel passionate about. Sorry about the late post. I made a comment on another InfoQ article ( over a year ago, and I still more or less feel the same way:

    "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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p