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:
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.
CEO, Net Objectives
Achieving Enterprise and Team Agility