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.


A lot of people tend to think Agile means Scrum – you know how it goes:


And I think there’s a lot of goodness in Scrum. It provides clear structure for what the team needs to do (the Sprint Backlog), gives them focus for getting it done (backlogs are fixed for the duration of the sprint), and then enables the team to determine the best methods for getting that work done. It even provides them a coach (ScrumMaster) who’s job it is to make sure they have what they need and to get impediments out of their way.

I love it’s feedback loops for constantly checking in, making sure we’re on track and – when we find we’re not – adapting as needed: Daily quick (15 minutes max!) meetings for the team to sync up, customer demos each sprint, regular team retrospectives. As Ken Schwaber says, software is too complex to completely avoid failure and why would we want to anyway since failure is how we learn!  Instead, what we need is a framework that enables us to identify failures as quickly as possible so that we can learn from them and adapt accordingly (see: Framework for Finding Failure).

The Problem with Scrum’s Time-boxed Sprint Lengths

The thing I’ve grown to dislike about Scrum are it’s 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 (see: Kanban Development Oversimplified).

I recognize the advantage to Scrum’s set-lengthed sprints was to provide predictability. If we work in consistently-lengthed sprints then we can define our team’s velocity to predict how many stories we can deliver each sprint. Or, as is the norm with Scrum, we can say, “on X release date we’ll deliver this long list of features.”

But, I believe that for the same reason two weeks is suddenly too long, this predictability isn’t realistic anymore. The faster technology improves in allowing us to quickly build & demo features, the faster it enables the customer to change their thinking, the faster it enables us to learn and adapt, the faster things are changing. And we can either respond to those changes by truly adapting the software into the right solution. Or we can blindly ignore this information and stubbornly continue marching down the not-quite-right-path because our sprint hasn’t ended yet.


Kanban addresses these challenges with a different approach to scheduling. Rather than working in time-boxed sprints (Kanban has no sprints), Kanban puts limits on how many features a team can work on at a given time.

As soon as a feature is completed – two things happen:

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!

Below is an example of a Kanban board, which is used to visually track the status of each feature:

Kanban Board

Each column represents the state of the feature, and under each column – in red – is the maximum number of features that are allowed to exist in that state at any given time. The columns can be named whatever makes sense for the team, but you’ll typically have a To Do column with the next features to work on. Next, you’ll have 1 or more columns to represent the work that’s In Progress (here, we have Development, Test & Release). And finally a Done column.

You don’t want to go too crazy on the # of columns else you’ll hit inefficiencies from that as well, but separating the work into a few different states reaps yet more advantages from Kanban:

1) You can specify different workload capacities for different disciplines based on your team’s capabilities

2) You get a visual, real-time status of your team’s workflow so you can be continually optimizing your process as well as eliminating bottlenecks (or other problems) as they occur (before they have a chance to compound).

The result is more feedback with the ability to adapt to that feedback faster.

Evolving Practices

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 (see Kanban and Scrum).

And so, I believe the evolution of agile – as has always been the case with agile methodologies – is pulling from those practices that make the most sense. Kanban for scheduling, Scrum for self-organizing & feedback loops, and XP (with some of the new practices from Lean Startup!) for technical practices.

Photo Credits: Scrum Process by Mountain Goat Software, Kanban: Kanban and Scrum – making the most of both by Henrik Kniberg and Mattias Skarin


66 responses to “Kanban is the New Scrum”

  1. I wouldn’t agree that Kanban is evolution of Scrum. It is just two different methodologies. Time-boxed sprint length gives feeling for the team of something that has start and end, while Kanban is never-ending “sprint”.

  2. Tom Howlett Avatar
    Tom Howlett

    I agree using Kanban to replace sprints in Scrum is a good evolutionary step, we’ve started doing it a few months ago and so far it’s working well.
    Scrum encourages you to throw out what you’ve got and follow its rules. For us this provided a kick start that were able to use on a small team and the results encouraged us it to adopt it on a larger scale. We did it by reading a book with no coaches or consultants to help.
    I think Kanban’s start with what you’ve got and evolve into something better requires more skill from the outset. I’m not sure how I would have got on with it with what i knew then. I’m interested to hear if anyone has used it to change without significant outside help.

  3. George Dinwiddie Avatar
    George Dinwiddie

    Scrum’s two-week sprints are almost always too long to be optimal. But in most medium to large organizations, there is enough inertia that going faster is usually quite difficult. Also, most developers have not built the skills to work in small increments and find two-weeks incredibly short. (My recommendation is to go to one week, and quickly pick up the skills required to do so. This requires more willingness than is often available.) I would certainly not recommend high-ceremony Scrum for a startup. For long-established corporate IT, that same approach to Scrum seems incredibly lightweight.

    Karl Scotland and I (with a few others) took a look at Scrum and Kanban practices at Agile 2010 (http://availagility.co.uk/2010/10/04/a-root-cause-analysis-of-agile-practices/). By repeatedly asking “why do we want to do this?” we found that they quickly converged to the same things.

    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.

  4. George Dinwiddie Avatar
    George Dinwiddie

    Tom, if you think that Scrum says to throw out what you’ve got and start fresh, then I think you’re looking only at the Scrum practices and not the principles of how those practices work.

  5. Tom Howlett Avatar
    Tom Howlett

    What we had was managers assigning features to single developers and wondering why it took them so long – that needed throwing out! With Scrum from day 1 the team took collective responsibility and made some real gains. Just by following the practices, self organisation and continuous improvement came pretty quickly. Over the years that followed we understood more and more about the principles behind what we were doing and continued to improve. I think you can adopt Scum practices first (with a basic understanding of the principles you lean doing a CSM) as long as you continue to learn the principles behind it. I think you would need a better understanding of the principles when starting with Kanban to start seeing improvement.
    If everyone, not just the elite teams, are to improve we need to have a viable starting point for change

  6. Nice post, Abby. I agree that Scrum and Kanban, like Agile and Lean, are complementary disciplines. They have evolved along separate paths, but they arrive at more or less the same conclusions. It would be a shame if the IT community becomes so fixated on ideological partisanship that we can’t continue to develop new and better practices, even if those practices to not fit neatly into one camp or the other.

  7. Erwin Verweij Avatar
    Erwin Verweij

    I just had to respond, great article but there is a dark side to it. Is Kanban the new Scrum? I don’t think so – http://agilethings.nl/?p=2253 Join the Dark side

  8. Melle Koning Avatar
    Melle Koning

    Scrum is what developers want, but can only be achieved if we deliver proper quality. Read more: http://www.mellekoning.nl/index.php/2012/01/05/scrum-is-impossible-without-quality/

  9. Lisa Crispin Avatar
    Lisa Crispin

    Personally I think “self-organizing” is the key. My team started 8 years go as a Scrum team – that’s when it transitioned from an exceptionally dysfunctional waterfall team. (I only joined at the time of the transition to Scrum). Over the years, we’ve jettisoned some Scrum practices, and brought in some lean/kanban practices. We *could* release every day if we wanted to, but that would be too disruptive to our customers. We do limit our WIP, and we focus on finishing one story at a time.

    But 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. We try small experiments to accomplish that. Because we’ve been together 8 years, we’ve really jelled as a team. We didn’t start out to be an XP team, but we’ve adopted most of the XP practices. 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.

  10. Derek Huether Avatar
    Derek Huether

    The greatest challenge I see, when coaching new Development Teams (using Scrum), is the idea of a shorter sprint. Though they don’t disagree with the value of delivering “potentially shippable” product earlier, they act as though it’s impossible to be more disciplined in their practices. (We all know this is untrue) I find them trying to hide behind being self-organized AND having self-defined appropriately-sized timeboxes. To counter that, the Product Support team for the same organization doesn’t want the limitation of the lengthy timebox. They want the opportunity to deliver as quickly as possible, without breaking the defined process. As agilists, we promote the idea of eliminating waste. For the Product Support team, that waste is usually the timebox defined by the Development Team. I’ve found Kanban to be my common recommendation. The first response is generally “it’s ok for us to do that”?

    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.

  11. Jim Ewel Avatar
    Jim Ewel

    Great post Hacker Chick. Two additions you might think of adding: 1) the concept of innovation accounting from Eric Ries’s Lean Startup. In other words, a feature isn’t done until the data is in, proving or disproving the hypothesis of why it was added in the first place. 2) Work in process. That’s perhaps implied by your use of Kanban, but making it explicit is important. I particularly like Eric Ries’s application that you can’t start on new features until others have been proven out.

  12. Ralf Pannemans Avatar
    Ralf Pannemans

    Nice article “Kanban is the new Scrum” –

  13. Dave Aplin Avatar
    Dave Aplin

    From the perspective of someone who is new to Kanban, I think your article was great and certainly helps to give perspective to the benefits of this approach. However, as a Business Analyst, I think that there is a need to add in the benefits that the approach gives to the Analyst Team.
    From a BA perspective, one of the challenges during an Agile development is for us to have visbility what we need to be working on and when. It’s all very well delivering stuff into the PBI, but if these items are not looked at for some time they can often be out of date with the current thinking and so need to be updated before they get into a Sprint.
    I’m hoping that the Kanban approach will help us to maintain a view of the priorities that we, as an analyst team, need to work on, so that we are delivering just on time. By adopting Kanban, it should be possible to quickly rework our priorities, in consultation with the Product Owner, so that we all agree what needs analysis and what doesn’t.
    Watch this space !!!

  14. Mag Janvier, the PO Avatar
    Mag Janvier, the PO

    Hi Abby – good thinking.
    I do agree that the Kanban has a better approach to time scheduling by dropping the time box restraint. On another note, I think that many people who end up with a ‘ScrumBUT’ method, finish off doing that as well, by being less strict on themselves as to not adding removing stories from sprints. Also, is there any Scrum role that prohibits a team to release a feature into production the minute it’s complete? I believe that is a key principle to any agile school of thought.
    I like how you end your post by mentioning the fact the agile practices are evolving, and I totally agree; I just recently posted about that: Agile is Evolving, not Declining: http://bit.ly/xw4eTC

  15. security audit of your website(s) HACKING OF WEBSITES & Hacking Accounts which include facebook,twitter this is pretty easy,myspace,skype,and email ids.I require either a Name, Friend ID, or E-mail address of the targets account(s). I have the help of a current 0-Day Exploit that allows me to gain remote access to the website servers and from there I find the password which is usually in an MD5 hash, from that I must decrypt to get the real password. The entire process takes about 30 minutes-1 hour to complete. All passwords are tested out 3 times before they get issued to any clients.I also rip Standards from websites.I accept payment through LR (Liberty Reserve) Only.I hardly ever USE WESTERN UNION!
    YOU CAN REACH ME ON :[email protected] (SEND ME AN IM THROUGH Y! MESSENGER OR MAIL)i also sell bank logins and credit cards

  16. contact [email protected] for your common and coperate hacking problems

  17. Feel free to hack my site! 😀 http://hfase.com/why-not-wordpress/

  18. Mario Moreira Avatar
    Mario Moreira

    Hi Abby, I would suggest that Scrum and Kanban are two different things but both have some similar features.  The way I explain Kanban to Scrum knowledgeable folks is that Kanban is Scrum but without the sprints (well there is a bit more than just that).  Both Scrum and Kanban applies backlogs and prioritization.  There is more to it than this but for some of my sustaining engineering teams that are much more interupt-driven, then Kanban works well for them. 

  19. joelparkerhenderson Avatar

    Yes, you’re right on. Kanban is better than Scrum, especially for startups. Kanban is leaner, faster, and more powerful for continuous integration, continuous delivery, and achieving business value.

    Kanban is effectively a priority queue, and there’s a great blog post by Steve Yegge about this: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

  20. Tobin Avatar

    Thanks for posting! You’ve crystallized a lot of my issues with Scrum. Now I don’t have to write this. 🙂

  21. Kanban has some good points and bad points for software. I talk about this a lot on my blog on this 
    http://jordanbortz.wordpress.com/2012/07/10/kanban-for-software-engineering/ and other postings.

    Ultimately I think having a flow state like “kanban” is good – but it should be designed for software engineering and a lot of things need to be reworked to make something like that happen.

    It’s not a process it’s a signalling mechanism — that is all it is — lean is different form kanban (status).

    What I see most of the enthusiasm for Kanban being is a face saving out from Scrum — no more sprints, and it’s “hip”.

    But it’s also a 30+ year old manufacturing technique that has been bypassed pretty much and is not much used anymore even in manufacturing.

    See http://jordanbortz.wordpress.com/my-approach/ for my thoughts on software development in general; perhaps combining that with a project status indicator system would be good but it’s more related to software than most “agile” methodologies I see


  22. Katt Wilson Avatar
    Katt Wilson

    Certified Ethical Hacker CEH training is held at TechBharat Consulting using official EC-Council curriculum. CEH certification certifies you as Ethical Hacker and Penetration Tester. CEH training is held on Version 7.
    ethical hacking training institutes in hyderabad

  23. Justyna Laskowska Avatar
    Justyna Laskowska

    Kanban and Scrum works best in different circumstances. Nice summary of both methods at http://www.kanban-scrum.com

  24. I_usta_b_a_leader Avatar

    Whats your opinion 6 years later? I have worked with multiple teams and tried to implement Kanaan a few times. I’ve also seen other teams make the transition… and its always been a nightmare. I know of one team that it has worked for and it was only because their software had internal dependencies, and they needed to support/triage other teams needs quickly. Usually Kanban seems to equate to chaos.

    The main problem I see with it is once you move beyond a start up into a growth company and/or get into a more corporate setting you have to support multiple customers, then priorities get more stringent (or should). You can’t build every feature that the business is asking for. You have to build a feature that serves the 80% of customers and eases the pain of the 20% of customers who may have more granular needs.

    I have found that being mostly scrum and leaving room for a little rule bending has been way more successful in the long run. This takes discipline as a product owner and understand what rules can be bent when. It also requires giving the team a voice and letting them be proactive in planning and sometimes you have to tell a customer “no” (gasp) or at least “that will take a few weeks, so we can get X out the door first”.

    That flailing around trying to chase business butterflies often blocks making progress for long term success.

Leave a Reply

Your email address will not be published. Required fields are marked *