What is the difference between first generation Agile (XP/Scrum) and Lean/Kanban?

May 31, 2009 — Posted by Al Shalloway

This blog is based entirely on a recent post I made on the Kanban Dev group. I have slightly extended it here for clarity.

I get a lot of comments from Agilists who have not done Lean or Kanban suggesting that there is little difference between all of these things (XP, Scrum, Lean, Kanban).  They tend to think the differences are just a few practices which you could do anywhere.  I do not agree - for reasons which this blog will elaborate.

Others have a belief that there is no real science underneath Lean.  I think this belief of no foundation of laws underneath Lean is what stops them  from seeing the value of Lean.  Many Scrum proponents love the simplicity of Scrum.  They believe relying on starting from experience only is powerful.  That there is not a set of rules that can support actions and hypothesis. That only doing will enable someone to learn.  The biggest difference between Scrum and Lean in my mind are just the differences in these beliefs.  If you don’t believe a science is there you cannot find it. I believe that flow has rules you cannot violate without costing your team/organization something.  That the ‘science of lean’ is discovering and learning how to follow these rules. This takes a combination of practice and theory in order to learn how.

Other beliefs of many Agilists include the notion that the only science available is one involving small groups of people.  And that that even this science is almost impossible to take advantage of - which implies that trying to deal with large groups is ill-advised. Ken Schwaber has said "Scaling is hard. It is probably the last thing one should do."  I'm not sure how Scrum practitioners would start with a group of over 50 people as many groups need to start at that scale.  However, I think this belief - that one starts small and scales up - makes it difficult to see a significant perspective and guiding force of Lean and Kanban.  This is that one must include the whole in any software development process - this is Lean's principle of "optimize the whole".  

It is this difference in perspective that is a fundamental and huge difference between Lean and Scrum.  Lean comes at it from the organization in an attempt to create the context the teams need to have in order to operate effectively.  Scrum attempts to get teams working effectively and then tie them together.  A top-down approach is considerably different from a bottom-up approach.  Unfortunately, many Agilists interpret a top-down approach to mean command and control via micro-management.  I don’t.  Another part of Lean is where managers lead, they don’t direct how to do things.  Lean mandates management to be leaders and coaches - so as to allow for top-down guidance without micro-management.

An example of this can be in firefighting a large forest fire.  Imagine a crew of 100 fire fighters organized into 10 teams of 10.  Scrum would suggest each team to do the best they can and then try to coordinate with a Scrum of Scrums (probably with walkie-talkies in this instance).  Lean would have a leader at the top giving objectives to the 10 teams and keeping them coordinated.  The manager would expect that they would organize themselves into the best way to fight the fire in their own situation – but that the objectives would be set from above (him).  No micro-management here – rather managers setting vision, direction and coaching as needed.

In order to see how to do top-down implementations one must understand Lean management.  Ken Schwaber suggests that 75% of teams don’t get the success they want with Scrum because they accommodate the ineffective organizational structure they have.  I think this accommodation occurs because Scrum gives them little to no tools to figure things out.  A large organization, even one of 50+, is very difficult to change without tools other than “inspect and adapt”.  Inspect and adapt ironically is a cornerstone of Lean.  It is part of Deming's systemic thinking of Plan Do Study Act (PDSA).  Toyota calls it Plan Do Check Act (PDCA) but it is the same.  This is a concept that has been around for more than half a century and one I hope everybody (even Waterfallers) are using.

When I suggest to people that going in to an Agile transition without Lean is foolhardy, it is not because I am being negative or bashing Scrum.  I would tell a carpenter to bring hammers and a screwdriver!  Except in this case, Lean represents the power tools. 

In essence, I believe many Agilists have troubles seeing the value of Lean and Kanban is that they hold onto belief-systems that are not effective for large teams.  Scrum works great when you have teams of 25 or less or you have very aware management who can handle the organizational problems.  It does not appear to work so well otherwise. 

Many of my beliefs have been dismissed as just my current favorite.  I think this is being very dismissive and disrespectful.  By labeling ideas as a current favorite one somehow negates it without having to discuss it. I have been doing agile for over a decade.  My beliefs have not changed as much as I have added to them. I have been doing Agile informally in varying degrees since the 80s.  I incorporated much of XPs philosophy and practices in 2000, added Scrum the next year.  I got a team to use Scrum in about a day very successfully.  Small teams are not hard to get going with Scrum.  I started doing Lean in 2004 (building on my foundation of Deming that I had had since the mid 80's).  So it’s been “my favorite” for 5 years.  A pretty long time in this world. My belief is, however, after having done generic Agile, XP and Scrum, is that Lean is significantly different because it creates a context for everything I do – whereas the others don’t.  Lean incorporates work, management/leadership and education/learning. Over the last five years I have been expanding my knowledge of Lean. 

Lean can incorporate other ideas as well - so I think it creates an incredible context for learning how to do product development. Since then, I’ve extended what could be considered the core of Lean with the science of flow (a la Reinertsen), added Lean Management (a la Scholtes and David Mann), added Lean Knowledge Stewardship (A3s, also a la Learning to Fly) and have recently added the practices of Kanban Software Engineering.  I am not switching between things.  This has required a lot of learning, conferences and reading.  I wish it were easier, but if I am going in to help other organizations I have to be as prepared as I can be.

I just worked with a team of 70 people and used every bit of knowledge I have about XP, Scrum, Lean and Kanban to help them.  They and I were well pleased with the result.  I can tell you absolutely that if I did not have a solid understanding of and practical experience with Lean and Kanban (on top of my XP and Scrum experience) I would have gotten a poor result and they would have sent me away thinking I had wasted their time.   In four days I could not have “inspected and adapted” to a solution.  This team has a good start.  Throughout the week they kept seeing – “oh, I guess we have to change this” and “I guess we have to change that”.  We left with a list of other impediments that they see what they need to do, but they also know transitions are difficult and therefore don’t want to do too much at once.

I am passionate about telling people about the need for an understanding of Lean, Kanban and XP engineering practices because if you need them and don’t know them it is ridiculous to relearn them – they are well known!

Some Agilists are claiming that the leaders of Lean and Kanban are making exactly the same mistakes that the previous one made. Personally, I think the leaders of the Lean and the Kanban community are avoiding the major mistakes of the earlier generation of Agile – and this is another reason why I am so vocal.   There are three major differences.  First, we are friends with management.  You won’t hear us talking about “chickens and pigs” and protecting the team from management.  We are not a reaction against the swinging pendulum of too much management and not enough.  We are looking for ways to repeatedly get good results.  We view our process as a system that represents our knowledge of the best way we do things.  But we hold this as an ever-changing system – one that gives us a way to do continuous process improvement.

Second, we are building our practices on a foundation of principles.  When XP came out I challenged why it worked the way it did.  I didn’t challenge that it worked.  XP to me, once it was described, was intuitive that it would work.  But why?  Why does test-first improve design?  Why can you get better results emerging your designs?  This took me years to figure out (ironically, with similar reactions that I get today to my questioning, even though what I came up with was later enunciated by others as well and is common knowledge now). 

I may not need to have this knowledge to do it nor may I need to have this knowledge if I am a coach and am at a client’s site to help them.  But I absolutely need this knowledge if I am going to come in for a few days and jump start teams so they can function on their own.  I need to convey practice and theory.  The theory is needed for them to generate ideas and try and see how they worked (a scientific approach). 

The difference between inspect and adapt and science is that in inspect and adapt you improve your actions but you don’t necessarily work on improving your understanding of why your actions work better.  This is an essential part of Lean and Kanban.

There is a third huge difference between the Lean/Kanban community and many leaders in the Scrum community.  We are open and are willing to discuss our beliefs.  Scrum leadership has demonstrated they are not.  Not only are the mistakes of earlier methods not acknowledged, they have even been suppressed. Discussing Lean on the Certified Scrum Trainers discussion group is discouraged by Ken. When one talks about Scrum's short-comings as I have, in an attempt to give new Scrum practitioners better tools, we are often characterized as going after the money, being hateful or just thrown off of discussion groups – with an admonition that we should leave the industry. Voices of dissent are often mischaracterized – but that doesn’t mean they are not right. 

It may be useful to note the stages of reaction by communities to new ideas:

  • Ignorance
  • Denial
  • Anger
  • Acceptance
  • Understanding
  • Enthusiasm
  • Accepted as common sense

I have seen the Scrum community move from ignorance of Lean, to Denial and it now appears to be in a combination of Anger and Acceptance - so I guess we are making progress.  

Ironically, I think many in the Scrum community are often acting like the waterfall community did when Agile came out. Instead of seeing that Agile had success and taking the attitude – “I see you are having success but I don’t understand it.  Please teach me what I am missing” many Waterfall practitioners took the attitude “I hear you are claiming success – prove it to me.  You can’t be doing something better because I don’t understand it.  You are just zealots.”  I, unfortunately, see much the same going on now.

The passion of the leaders of the Lean and Kanban community of today should not be misconstrued as being the same as the dogmatism we have sen in the past. We encourage experimentation with and discussion of our methods.

To be clear, I offer this as a discussion of ideas, not as a characterization of the qualities of the individuals involved in the conversation.  I would appreciate the same consideration in anyone’s blogs referring to these conversations.

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility


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.


Previewing my comment caused a page fail, erasing my text. Now I have to rethink and retype the whole text. I don't like that!
Checking the link in the text below, while previewing and then using the Back-button to return to preview did cause even to lose the preview page, with my new comment text! Fortunately this time I made a copy of the text!
Lean and Kanban ideas are already so old:

  • Ford: 1922 "We have eliminated a great number of wastes", 1926: "Learning from waste"
  • Toyoda: 1926: "stop the production line" (zero defects), Just-in-time-flow-pull-kanban"
  • Deming: 1950: "PDSA/PDCA, Elimination of waste", 1986: "Reduce waste"
  • etc

And I was wondering whether you, now so enthusiastic about Lean/Kanban, ever heard of Evolutionary Delivery / Evolutionary Project Management (Evo), which in practice was part of Cleanroom development and propagated by Tom Gilb since the 70's. I added Evolutionary Planning to this (2001-, see booklets: www.malotaux.nl/Booklets). I think Evo is propagating Lean/Kanban/Kaizen from the start, but hasn't been recognized by most people, or rejected on grounds you are describing in your blogs.
Whether it’s called Cleanroom, Evo, Lean/Kanban or whatever is not the issue, as long as people start doing it.
Some problems I see with most Agile approaches is, that they tend to be 'religiously followed'. If people don't understand the grounds well, religious following (belief) is often an answer. This goes against continuous learning/improvement, which is the essence of PDSA/Evo/Lean. Continuous learning requires a certain humbleness, showing that you don’t know it all. This can be scary for some.
Another problem I see eg with Scrum practice is that people should not just decide what they should do. At least as important is what not to do. Most projects deliver late and the only way to do something about this is saving time, see www.malotaux.nl/Booklets, booklet#7, chapter 7.6, essentially describing what Leanists now call ‘muda’, but what was called ‘waste’ already 80 years ago. Because in most projects half of what is done, later proves to have been unnecessary, there is a lot of time we can save. It's not a good solution to rely on the ‘customer-representative’, pushing away the responsibility of the success (or failure) of the project (or of the team) to that person.
I see that Scrum pretends to do retrospectives (PDSA/Kaizen), but people are hardly educated on how to do that usefully: In the Act phase we decide what to do differently the next time (if we don't do something differently, we cannot expect the outcome to be different, let alone better). Mostly we see that people forget in the subsequent Study phase to check whether the change worked for the better and then thinking: if yes, how can we do it even better the next time; if no, how can we do it better the next time. Lack of ‘Profound Knowledge’ and of the use of ‘Masters’ (see Deming) does the rest: in many cases the reaction on what we see in the Study phase, if done at all, is even, although very intuitive, still incorrect. The lack of Profound Knowledge’ and of ‘Masters’ is probably one of the reasons why Scrum fails in so many cases. But this would mean that the same will happen again with Lean/Kanban.

Niels Malotaux, Project Coach (not 'Agile' Coach: Agile doesn't need coaching; Projects do)

I am a very enthusiastic person.  But I could hardly be considered dogmatic. I embrace XP, Scrum (where it works), TDD, Lean, Design Patterns, Kanban, lots of disciplines - whatever I find useful.

I find it dismissive to imply that because I am enthusiastic, I am something not desirable.  I agree that most of the ideas out here are old.  Your points about Scrum could have been taken from my writings - so I'm not sure what you were commenting on.

Alan Shalloway, CEO Net Objectives

An excellent blog entry Alan!

Jan Sandbacka
Manager:Lean Practices
F-Secure Corporation

  • Note 1: when I register, there is no "Chief Engineer" position. I guess if I my organization is already practicing Lean Product Development, Net Objectives is not interested in me? :-)
  • Note 2:
    > This is a concept that has been around for more than half a century and one I hope everybody (even Waterfallers) are using.
    Waterfallers do not inspect and adapt, for the simple reason that they can't.

So, where is this coming from? Since I started studying Scrum after practicing XP for a few years, I kept seeing references to Lean, which has in turn prompted me to study it. I can understand a reluctance with ill-applied Kanban or other Lean Manufacturing techniques, but who in the Scrum community would not be interested in Lean principles? Mary Poppendieck prefaced Ken Schwaber's Project Management with Scrum, for example.

Ken Schwaber has been trying to suppress Lean in the Scrum Community for years.  He has thrown me off the Scrum Development group twice for talking about it.  He has told several CSTs not to talk about it on the Scrum Trainers group.  He has told others not to talk about it on the Scrum Development group.  Now that it is becoming obvious that Lean has value, I am seeing bastardized explanations of it coming from many Scrum consultants who have recognized that "if you can't beat 'em, join em" but are trying to now pretend that they have understood Lean all along.

If you feel the leadership of the Scrum community is open and embracing of Lean I am afraid you are a bit naive. 

Now, be clear. Most Scrum Alliance members are well intentioned and very capable.  But don't pretend there is not a bias against Lean by those who would like to control the Agile movement with Scrum.

Alan Shalloway, CEO Net Objectives


Henrik Kniberg wrote a nice blog entry about the differences (and similarities) between Scrum and Kanban as well

I think that there is much to be learned from Kanban and many places where Kanban actually might work better.

Jan Sandbacka
Manager:Lean Practices
F-Secure Corporation

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