Agile Zone is brought to you in partnership with:

Abby Fichtner writes The Hacker Chick Blog, co-organizes Boston's 2500 member Lean Startup Circle, and was Microsoft's Evangelist for Startups where she helped hundreds of startups as they build out the next generation of software. Her background is a mixture of developing bleeding-edge technology for startups and coaching teams on how to improve how they develop software. She's extremely passionate about building communities where innovation thrives and in helping others to push the edge on what’s possible because she believes that each & every one of us is capable of changing the world. Abby is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Kanban is the New Scrum

  • submit to reddit

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


Published at DZone with permission of Abby Fichtner, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Timo Lihtinen replied on Wed, 2012/03/14 - 11:58am

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. 

Luka Thomson replied on Thu, 2012/08/16 - 3:54am

I think that Kanban can improve existing Scrum porocesses as well as mixing both methods can result in boosting preformance. I suggest you to take a look at Kanban Zone (, especially to watch a presentation Kanban applied to Scrum ( and to read an article Scrum-ban (

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.