What’s the main difference between Lean software development and agile methods like Scrum? Until recently, that question has not bothered me at all because I didn’t really care. The principles of Lean software development has helped me to focus on value and waste in software development. Agile values, principles and practices are useful tools when developing software.
But, then it occurred to me that there is really another difference, I’ll try to describe my thought by raising the question to you and your development team: What are you actually selling to your customer, how do you create value?
I’ll give you three alternatives: 1) are you selling a plan, 2) are you selling a team or 3) are you selling a product.
Selling the plan
Selling a plan, to me, is not agile or lean at all. Let’s say that the customer would like to have some kind of software development, and the intentions, business case etc. are all valid and correct. The customer contacts development company MasterPlan.Net and they will create a plan describing how they are going to create the value needed.
The assumption here is that if we follow the plan, then something valualble will be created. Let’s look at the other part:
Selling a team
When selling a team; the customer can choose to use the team in any way he like, if it is to develop a piece of software, build a house etc. in theory it does not matter.
If the customer has a vision, a product backlog and uses agile methods such as Scrum, then there will most likely come something valuable out from the team every 2-4 weeks.
The cost for producing the software is based on the cost of the team and the number of iterations needed by the team to create a version that meets the need from the customer.
This scenario is much more agile and will respond to change much better than the scenario with the plan. On the other hand, what about…
Selling a product
Let’s assume that there is a software system, and we call it a product. Each feature in the system flows through a value creating process including actions such as development, testing, and deployment.
The challange here, is to transform business needs into business values as efficent as possible. And the development process is a description of the current best way of doing that.
To do this efficiently, a motivated, complete team is created. With the ability to move items through the process. The team uses the concept of Scrum to work in iterations. The team tries to minimize the number of things in process the size of the items in the process so that the speed is maximized.
In the perfect world, features are delivered just-in-time, and development teams pulls work from the input queue. Or even better, it can be seen as a Kanban system… where the order is added last in the process… that’s where the motivations for test-driven development is really clear.
So what’s the point?
Maybe, I’ll really need to describe this in a better way. But for me this states the real difference between Scrum and Lean. Do you see the difference?
Scrum is the framework for helping the team collaborating, to make things flow through the development process.
Lean Software Development, is about creating value, make things flow in the value stream from business need to business value.
It is possible to use waterfall project methods to push things thorugh the value stream, but what you’ll see then is a number of large queues between for example development and test etc. Ie. waste in the lean world… so that is something that we don’t like.
SO, again, what’s the point, Agile methods and Scrum are useful practices to enable Lean Software Developent. For me, that complements the perspective of Lean being a foundation of principles guiding software development.
So, is Lean Software Development applicable when you are developing software in a non-product line environment? Yes, I’ll believe so but more on that in another post. What do you think?
cheers!
Thanks for the guidance – it’s definitely taking me a while to sort out good explanations for myself of the differences between Agile, Lean, and Scrum. The more I read, the more I am able to draw the distinctions. So, thank you..
Thanks for the comparison. I was just reading an article about Lean and Scrum and I wasn’t sure of the difference. I’m sure there are other people out there who also don’t.
This is a very helpful post, and I’d like to republish it on PM Hut. Now in case you’re OK with this, please contact me through the “Contact Us” form on the PM Hut site and we’ll take it form there.
I look at any methodology or concept thinking how it could suit my team and my project. I’m far from saying heavy-weight methods are bad at all and agile is a perfect way of doing anything. The same principle applies to lean – it either suits specific environments or it isn’t necessarily the best way to choose.
I agree that lean and agile can interact in a way you describe although I think you flatten Scrum a bit. Actually with a good, active project sponsor “framework for helping the team collaborating” helps to deliver business value too.
Of course that’s different when project sponsor is not willing to play on agile rules but that’s a different story.
Thank you for your comment Pawel, I really appreciate it.
First, i think Lean Software Development is about understanding how to create value to your customer and then continuously try to eliminate your biggest waste in the process of creating that value. To me, Lean is not the solution, it is a way to help me see my biggest bottleneck in my process, help me understand the root cause so that I then can try to find smart ways to eliminate that waste. I’m curious if you could share some examples where you think Lean thinking is not a good way to go?
Second, I absolutely agree with you, I think Scrum can provide a great deal of business value, thank you for pointing that out.
cheers!
/ Johan
For most tiny-sized projects you don’t need any full-blown methodology, because it never comes for free. You always add some hassle while implementing some new process.
R&D projects are another shot from the top of my head. In this case you actually want to wander, to produce some unecessary code just to learn something new.
As far as I understand lean focuses on process improvement (correct me if I’m wrong). Now if you don’t need much of process in your projects implementing lean becomes fairly irrelevant. When your processes work well (no matter how do they look like) I’d argue whether adding lean would help. That of course depends and sometimes it would be reasonable to do so but it isn’t a sure shot.
I’m not trying to say lean principles are wrong but they aren’t unique for lean either.
I would love to hear your view on when a process is good enough. And then, when is the time you decide it is time to actually start improving again?
I think it will be hard for any business to sustain without constantly challenging how things are being done and continuously improve. What if you look at your current way of working today, where is your biggest problem?
Change the way of working without removing the bottleneck will most likely increase the problem, that is one of the reasons I think why introducing a full blown method might just be a hard and expensive thing to do, because the risk is that you might hunt mosquito’s with a machine gun.
What about if you just focus on the bottleneck and try to remove that one? And after that, where is your bottleneck now, let’s go and hunt that one down, and so on…
I don’t care if the ideas are new or not, what they are called as long as they can help me understand what I do and increase the value I create to my customer. I’m amazed how a few principles can widen my view on software development, over and over again.
And by the way, I think of introducing test-driven-development, continuous integration or other technical development practices as process improvement activities as well as capturing the business need in a smarter way.
cheers!
/ Johan
1. The situation from my previous company: medium-sized project was already implemented. The client is a company which doesn’t focus much on papers as far as the job is being done. Now they’ve ordered a couple of simple so-called change requests (functional tweaks) to the system. Fortunately one of my best developers who knew the system well was free to take the task. I just forwarded him an email from the client and it was all. It worked since:
- The guy knew the system
- He’s one of this kind who understand business perspective of software he works on
- Changes didn’t touch any crucial part of the system
- I trusted the guy he’d deliver on time and a piece of quality code
Now, why should I add some techniques to improve the process? For me it worked perfectly fine.
2. The example of Google 20% projects. They aren’t controlled in any way. People are free to do whatever they want. No project management whatsoever. No strict rules. Sure, they add some of that when the project grows, more people join and application shows potential to go live, but many of them don’t make it to that stage. I don’t see any reason why it should be changed.
I’m not trying to say people shouldn’t try to improve their processes. In vast majority of cases they probably should. In Poland we have a proverb: better is the enemy of the good. The main problem is that in software development we rarely can label our processes “good.”
And another general idea: even when you decide you should fix something, there are many ways to do so. Joel Spolsky published lately a good discussion on unit tests which shows it may but not necessarily is good.
Johan and Pawel,
I highly appreciate your comments and thoughts, It had broadened my view.