The Real Differences between Kanban and Scrum

June 7, 2010 — Posted by Al Shalloway

This blog is the first in a two-part blog post. This one deals with the differences between Kanban and Scrum. The next one deals with what you can do with this knowledge. There are a lot of people who don't want to talk about the differences between Kanban and Scrum. Some say you can't compare them because they are like apples and oranges – different things. Many (almost all from the Scrum community) go so far as to say you should suspect the motives of those who even make such a comparison. Well, I believe they are comparable and that they should be compared. While they may be different, they both have the same intention: both are methods to improve the work of a product or IT development organization which involves software. Therefore, if I am trying to improve my software development capability, I should look to see which of these might work better.

My motives? Simple. I want to help people select the right method for themselves.

Everyone agrees that one size does not fit all yet many go around saying "use this!" That just does not make sense to me. At Net Objectives we believe, first and foremost, that Kanban and Scrum cover only some of the areas in an enterprise that needs to be affected by an enterprise Agile transition. We want to help our clients select the method that fits their needs. So, we teach and coach in both approaches and don't over worry what some single-method consultant might think.

More than "Iterations" 

Those with a superficial understanding of Kanban might think the difference between Kanban and Scrum is that Kanban does not have iterations while Scrum does. While that is a difference, there are at least 4 other differentiators to consider. David J. Anderson, the creator of Kanban agrees.

Let's go through the differences between Kanban and Scrum and how they all tie together.

Explicit Policies

A major tenet of Kanban is that you should have explicit policies that define your workflow. It has been demonstrated that doing this vastly increases learning by team members. Team learning occurs because team members actively discuss how they should be doing their work on a regular basis. Having done Scrum for over 10 years we've noticed that team learning is typically a direct result of the number of retrospections they've done. Reviewing a Kanban board is like a mini-retrospection every day. Unfortunately, a large segment of the Scrum community believes that this is neither warranted nor even possible. See comments on this by two CSTs – The Agile Value Stream Mapping by Alan Cyment and Scrum and Kanban – different Animals by Tobias Mayer. Scrum itself is often described as a black box process that has well-defined inputs (the product backlog) and well-defined outputs (the software built during the sprints) but that cannot be defined due to software development being a complex adaptive system. This is how Ken Schwaber's definitive book on Scrum (Agile Software Development with Scrum) describes it and little seems to have changed in many (most?) Certified Scrum Trainer's minds.

Manage Work in Progress (WIP)

One of the core practices of Kanban is to manage the amount of Work in Progress. This enables the team to stay focused and avoids creating new work caused by delays between the stages of work. A common Scrum impediment is having many things still in test at the end of a sprint. Managing WIP would help Scrum teams as well. This requires explicit policies.

Visibility of process, not merely of results

Having explicit policies means that management can see what the team is doing to achieve their results. This helps management see how teams are doing and enables them to play a more active role in removing their impediments. More importantly, this visibility leads to the next difference …

Inclusion of management

Kanban's visibility changes the relationship between management and their teams. It also allows managers to provide coaching and leadership to the team when necessary. While management respects that the team is doing their best but understands that sometimes teams don't see all the things they need to do. Scrum, on the other hand, tells management to trust the team – to never interfere or intrude. Ironically, the team does not trust management to provide proper "interference" – that is, coaching or questioning when the team needs it.

This inclusion of management is very important when it comes to how both methods show up in the real world.

  • In Kanban, managers better understand the impact of their demands on the team because they understand how the team is working. David Anderson's iconic book, Kanban: Successful Evolutionary Change for Your Technology Business, relates how the manager's relationship with the team is significantly changed when they come to understand what happens when exceeding the WIP limits that the team has set for itself is exceeded. Managers may still put something extra on a team's plate, but they do so with the understanding that it will slow them down. Sometimes getting something out the door is worth that.
  • Scrum, on the other hand, provides no insight to the manager who needs "just one more thing" to be done this Sprint. A scrum master who holds their ground and reminds the manager of their agreement to let the team work on the sprint commitment is typically just performing what we call a CLM (career limiting move). The black-box nature of the Scrum sprint essentially makes it impossible for management to understand why adding just one more thing will be so catastrophic. Instead, they assume that the unwillingness of the team to do so is because they are not true team players. Kanban, on the other hand, provides insights to management because it is clear how the teams are working to them. If they want to insert an urgent item they are free to do so. But is will also be clear why doing so will have an adverse impact on the team and slow other, possibly more important, work down.

Extend the Value Stream before the team starts

By including management, Kanban has a direct impact on the product management that feeds the team. This expanded scope often has a tremendous beneficial impact on the development team because it can remove significant overloading of the teams with work. Management gets to see why and how to set work levels to maximize productivity (true value produced) by the teams.

Flow vs. Iterations

Scrum requires iterations. Iterations help the free-for-all approach of Scrum to work so long as he team is functional enough to enforce the rule that everything be done by the end of the sprint. Unfortunately, most teams have serious troubles doing this due to dependencies on issues they can't control. By chunking work into iterations of 1 to 4 weeks, teams are forced to manage their WIP even if they are not consciously doing this. But only if they manage to truly complete things at the end of the sprint. Scrum teams often have problems doing this because the principles they should be following have not been explicitly spelled out to them.

Although Kanban teams don't need iterations, Kanban does suggest having a cadence of input and delivery. Most will not require a planning day or the sometimes confrontational (and often wasteful) task of committing to an iteration. They can do this if they want to but don't have to. When Kanban incorporates iterations, it is typically called Scrumban to differentiate from standard Scrum which does not explicitly manage WIP and from Kanban which does not use iterations.

...And the Biggest Difference: Controlled Change Management

All of these differences allow Kanban to do something Scrum cannot: Manage the rate of change of your transition. This is the biggest difference between Scrum and Kanban. With Kanban you can start where you are and slowly tune up the rate of process change by managing your work in progress limits. Scrum, on the other hand, often requires dramatic changes to an organization. If cross-functional teams don't exist, creating them may be traumatic or virtually impossible. Even if they can be created, the level of change required often leaves an organization in chaos and the members of the team wondering what to do.


The differences between Kanban and Scrum are summarized in the following table. 




Explicit policies


Don't believe it possible

Manage Work in Progress (WIP)


Not mentioned, don't know how to do it without explicit policies

Visibility of process

Input, work, output

Input and output only. Work is black-box



Keep them at bay

Value stream

Includes product management across products

At team level for one product

Change management


Must change to Scrum model – even if disruptive

There are several other differences but these are the primary ones.


Without scientific evidence it may be impossible to definitively answer the question which mindset is correct. However, there are two things to consider.

  • First, a large number of Kanban thought leaders used to do Scrum before they adopted Kanban. Some still do both. While I do not  listen to people because they are "experts," I do believe that the only ones who can truly speak about the differences between Kanban and Scrum are those who have successfully done both. Those who have done both almost universally say Kanban can be implemented in situations where Scrum essentially cannot.
  • Second, there are dozens of case studies in which Kanban teams have demonstrated significantly improved results by explicitly defining their policies. I know of no Kanban teams that have said they cannot do this. Teams that have been frustrated with Scrum have consistently improved with Kanban.

More Information and Next Week's Blog

If you want more information on these ideas, you might want to look at Questions to ask when selecting a trainer for your CSM Training. If you think the Kanban mindset might be useful for your Scrum teams, check out our Scrum Clinic.

If you are interested in learning about Kanban and Scrum, please consider attending one of our Lean-Agile Project Management certification courses.

Besides an understanding of the differences between Kanban and Scrum, where do they apply best? In the next post, I will describe the situations where Kanban works and where Scrum works.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Really this is just an expansion on your "Value Stream" point.

The two methodologies define the principle of pull very differently.

In scrum, teams pull from business and then push value to them when they are "done."

Kanban at least permits, if not encourages, an environment where organizational units closer to the customer pull work out of more deeply "nested" teams.

This means that, with Kanban, the customer pulls whole units of value through the entire value stream rather than parts of the value stream pulling fragments of effort that they call "work" out of the customer.

Great post! Thank-you for the insightful comparison. I have a question about this comment:

"It has been demonstrated that doing this vastly increases learning by team members."

Can you point me towards the information that backs this statement? I am interested in reviewing it.

Look for Chris Shinkle's presentation at the Miami Lean/Kanban conference in 2009.  Many blogs discussing that conference also talk about this.

There's a lot more, but this is where I first saw it.  Since then, I've coached a dozen or so teams and have seen this almost all of the time (in comparison to the scores of Scrum teams I have coached in the last 10 years).

Alan Shalloway, CEO Net Objectives

Since publishing this blog, there have been three other blogs of interest:

I believe all three of these blogs are worth reading.

Alan Shalloway, CEO Net Objectives

I don't view Scrum as such a black-box. The tasks and their state are quite visible on the card wall. Typically, every part of the value stream is represented in the tasks.

In fact, in some cases, Kanban can be more of a black-box in that though it reveals the process, the details (tasks, if you will) for a given stage are hidden. If your value stream is analysis -> design -> develop -> test, what's the details of 'develop'? How many things will you do in 'test'? For many software projects each of these stages can be quite involved with many tasks.

Note that I'm not disparaging Kanban. I use it and like it. I just didn't think the Scrum black-box categorization was fair.



Kanban does not say to do a value stream of analysis -> design -> develop -> test.  It says to map what you do.  If that's what you do then you are showing visibility on the tasks. I think you are mis-interpreting Kanban.  I therefore have to ask - how many teams have you done kanban with?

In Kanban, you must have visibility into the policies in which you are working.  Scrum shows the state, no doubt.  I am certain i said that.  It shows where the work is.  It doesn't show how you get there. Kanban says to have explicit policies, Scrum says doing this isn't possible or desirable.  I have seen dozens of kanban and scrum teams and the difference in clarity/visibility between the two is palpable. 

Ken Schwaber is the one who describes the Scrum internal process as a black box.  Both in his original book and in his recent blog. Maybe you should take it up with him? ;)

Alan Shalloway, CEO Net Objectives

"This blog is the first in a two-part blog post. This one deals with the differences between Kanban and Scrum. The next one deals with what you can do with this knowledge."

Can you link/point to the 2nd part of this post, thanks! Enjoyed reading part 1.

I was amused by the notion that Kanban allows managers to provide coaching and leadership to the team when necessary, whereas Scrum insists upon "self organization". What ScrumMaster in his/her right mind would withhold coaching because the methodology prescribes "self organization"? If automatons are implementing a methodology, they might be so rigid in their interpretation. Luckily, most humans are smart enough to read between the lines. Self-organization is a guideline. Inexperienced Scrum teams may get stuck and need a little advice. Selecting Kanban over Scrum for this reason alone would be silly. I'm sure there are good reasons to use Kanban, but this isn't one of them.

I never meant to suggest that ScrumMasters shouldn't/couldn't provide coaching as well.  I have always endorsed that - although, ironically, many (most?)  CSTs teach that ScrumMaster are facilitators, not coaches.  But managers in a Scrum world are typically hands off - as they probably should be in Scrum.  Why? Because Scrum typically operates as a black-box and management can't see how they are operating - and therefore don't have the opportunity to coach.   They also don't have the opportunity to improve the context within which the team works unless the team makes the suggestion.  And, they can't see very well how what they do adversely (or positively) affects the team.  But, I agree, this is not the reason to go to Kanban.  There are many others.

Alan Shalloway, CEO Net Objectives

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban