There have been several posts from those in the Scrum community (Ron Jeffries, Tobias Meyer, to name two) that say it is folly to compare Scrum and Lean/Kanban. The supposition is that they are different tools and therefore you can’t say one is better than another. Apples to oranges they say. I don’t agree.
The odd theory is that they are different tools in your tool box. I say “odd theory” because those who have said that would be the first to say that Scrum is not a tool – but rather a mindset. I agree, and assert Lean is also a mindset. It has tools, but that doesn’t make it a tool (see Lean is more than a set of tools )
To me, Lean and Scrum are both about improving the software development capabilities of an organization. They have different approaches and they work effectively in different situations. One could say the comparison is analogous to comparing bicycles and cars. I suppose many Scrum aficionados would say they are different, can’t compare them. Again, not true. While each is designed for different situations and bikes are good for exercise while cars are not, in general, both are designed for transportation. Both have advantages and disadvantages in different situations. Now, one is not always better than another. That is true.
For example, a bike is simpler, less expensive, easier to maintain, and (if you put on training wheels) easier to learn to use. It can take you places cars won’t. But if you need to go a long distance, a car may be a better choice. So, if you are asked – “which is better, a bike or a car?” you should remember the consultant’s motto- “it depends.” Depends on what? The context in which you are needing the bike or car.
The same is true for Scrum and Lean. The right question isn’t which one is better than the other, the right question is in which contexts is Scrum better and in which context is Lean better?
So where does one work better than another? To answer that question intelligently, I believe one needs to have used both successfully. Those succeeding with one and failing with another will tend to think the one they achieved success with is superior. While they may embrace some concepts from the latter, they will always tend to be more comfortable with the one with which they achieved success.
I started with Scrum several years ago. I have been doing Scrum training and coaching for about 8 years now. My first Scrum engagement took only 4 days of coaching for a year-long project. The results were great. The problems were simple. And they all had to deal with was how the team developed their code and how to protect the team from literally hundreds of internal clients vying for attention. Scrum was up to the task and it shone well. Score one for Scrum. Lean was more than was necessary.
Unfortunately, not all companies trying to go to Agile methods are as simple as this. The industry has reached a point where 3 out of 4 organizations attempting to use Scrum will not get all of the value that they hoped to get for it. This, by the way, is not my opinion, but rather Ken Schwaber’s and others in the Scrum community (see http://mattcallanan.blogspot.com/2010/02/ken-schwaber-on-scrum.html for syopsis of interview). There are so many examples of improper Scrum implementations that we now have a name for them “Scrum But.” The implication by many in the Scrum community is that these failures (or lack of successes as the Scrum community prefer to call them) is not due to Scrum but due to the lack of proper Scrum implementation. The same would be true for Lean of course. The difference, however, is that Scrum is a mere framework that often (usually?) doesn’t give the tools or thought process needed to solve the problems encountered that originate outside the team.
Scrum is based on a simple supposition that, as far as I can tell, has never really been scrutinized. This is the belief that if a team runs into an impediment that 1) they can see the impediment and 2) that they have the means to remove it. I think both of these suppositions are incorrect. Many people in failed Scrum implementations know they are having troubles but don’t really understand why. Even when they do, they are not necessarily properly armed with what it takes to remove the impediment. Merely being told to inspect and adapt is not enough.
It would be like telling someone to take public transportation in New York City and when your associate said the traffic was horrible you asked why they didn’t take the subway? In their upset, they say they weren’t even aware there was a subway. You reply they shouldn’t blame you – you had expected they would inspect and adapt and when they were slowed down they should figure out a way to get around the impediment. My question is “what did you give them to do that?” Perhaps a framework isn’t such a good thing if a thought process that can solve problems is available. In many ways, this is the biggest different to me between Scrum and Lean. Scrum suggests smart people can figure out the problems on their own. Lean suggests a thought process that works in many many different areas and assists a team’s ability to remove impediments in their way.
The surprising thing to me is that with all of this lack of success, no true root cause analysis has been done. Instead, it’s usually been stated impediments are being accommodated. Yes, but why? More recently, it’s been added that better engineering practices need to be followed.
As CEO of Net Objectives and as an Agile coach myself, I get to see dozens of companies each year trying to transition to Agile methods. Before we included Lean in our services, I saw many succeed, and I’m afraid to say, just as many not succeed. Since we’ve shifted to Lean as a foundation for all of our services, I have seen many more succeed than not. And in tougher situations. This success has been in areas in which Scrum would suggest starting with a pilot project and scaling months later. Instead, we’ve gone in and started out development organizations of 70, 150 and more, right off the start. In fact, in several of these, I am sure that starting with a mere team would actually have hurt the organization.
How have we done this? We’ve used Lean-thinking to come up with ways to remove impediments that those who don’t understand Lean would likely not be able to do. We’ve written about these solutions in our upcoming book (publication date October 17th) Lean-Agile Software Development: Achieving Enterprise and Team Agility.
My own opinion is the high rate of lack of success is due to the fact that Scrum is now being used in places which require organizational change. Ironically, in these situations, Scrum’s practices and attitudes often work against it. In particular, Scrum’s neutral at best and negative at worst attitude towards management does not enroll or empower managers in how to solve the organizational problems teams need to be solved. Furthermore, Scrum’s iconic leader, Ken Schwaber, suggests that the process a team needs to follow must be of a black box in nature because the problem being solved is non-deterministic. This too, works against teams in many situations. In a future blog I’ll talk about how Scrum teams can use some aspects of Lean thinking to help both to assist management in helping create the organizational changes needed by the team and how to enable managers understand their process so that management can be a positive force for the team in other ways.
Getting a pilot project off the ground often has a local optimization affect. It may look great for the team, but the value the development organization delivers does not go up. In most cases where there are interdependent teams, teams must be given or must create a model that gives insights into how they can best work together. Lean provides such a model that people don’t need to trust, but rather, once explained, they can see from their own experience how and why it works. In many cases, Lean’s insights confirm that the organization has been moving in the right direction but was just missing a little understanding needed to make it all click.
I have used Lean in so many situations that I consider it indispensable. One of my more recent experiences was kicking an organization of 70 people with only 4 days training and 3-4 days coaching. Lean thinking provided an insight to the group that completely changed the work flow of the teams. Scrum’s team-oriented approach would not have worked – because different team structures were needed for different features. Lean’s “optimize the whole” and “short cycle time” provided the key insights to enable all of the teams to work on and solve the root cause of their problems.
I have seen Guy Beaver, our consultant in Charlotte, kick off organizations of 100-200 people by focusing on their product portfolio management organizations instead of focusing on the team. Scrum assumes the team is always the place to start and then scale up from there. It isn’t. At Net Objectives have a large arsenal – one that includes Scrum and Lean. We have found that the Lean thought process works on the tough problems where other methods have failed.
In our experience with our customers, we have found four different places to start: Business planning, product portfolio management, organizational management and team management. We use Lean thinking to see where the greatest impediments are and use that to determine the best place to start an agile transition. Maybe it’s not a coincidence that Scrum’s starting point of the team (1 of these 4) matches the percentage that is acknowledged for achieving success. It is interesting to note that, while we believe team’s technical skills are woefully insufficient in many cases, that is rarely the place to start if achieving success in a short period of time is desired. The noted exception here is doing acceptance test driven development (i.e., writing acceptance tests before writing code). This is a quick return benefit that all teams should be doing.
I have been told that Scrum does not say to not use Lean. But not saying not to use something is not the same as saying to use something. To provide a framework that does not hold what is almost always needed in many situations is an insufficient framework in my mind. There are also situations where Scrum and Lean provide different guidance. I will be blogging about these in the future:
This discourse has been intended for those who are trying to improve their software development efforts – be they in business, management or developer roles. I consider Lean and Scrum to be based on different belief systems (see Differences in Beliefs Results in Differences in Approach). Furthermore, Lean has a large set of principles and hypothesis that have been shown to be valid in product development for many decades (note I said product development, not manufacturing because I don’t want to get into the “we’re not building cars” argument). I believe these principles are essential in solving the challenge of transitioning any organization that has interdependent teams and works on several projects at a time. I base this on my experience with many organizations and on my expertise with both Scrum and Lean.
Scrum can be improved by using these principles as a basis for adapting it in different situations. Taking selected Lean practices and incorporating them into Scrum is not the same as doing Lean-Thinking. To those looking to start an Agile transition, or if you are one of the 3 out of 4 who have not achieved the success you were looking for, I suggest you take the time to understand the belief systems underlying Scrum and Lean before undertaking to do either.