Lean Software Development: Less is the New More!
This content is syndicated from by Kelly Waters. To view the original post in full, click here.
There is no doubt that 'Lean' is the new buzzword of the software development industry; certainly within the agile community anyway.
But how does it fit in with agile, and more specifically, how does it fit in with agile methods like Scrum and eXtreme Programming (XP)?
Lean software development shares many, if not all, of the key principles of agile software development.
As a result, in can potentially be seen as an instance of agile, much like Scrum is another instance and eXtreme Programming is another.
Whilst Scrum focuses on agile management practices, and eXtreme Programming focuses on agile engineering practices, Lean software development is an extension of the underlying principles and has a sharp focus on eliminating waste.
It can also be seen the other way around, that agile is an instance of Lean thinking.
It's certainly true that agile principles and methods eliminate a lot of waste, especially in comparison with previous project management methods and traditional waterfall projects. That's for sure.
And it's also true that agile - starting with the original agile manifesto - has its roots in Lean manufacturing, as pioneered by Toyota and Honda.
But Lean thinking can actually be applied to any methodology, whether it's waterfall, Scrum, eXtreme Programming, or whatever.
For example, in Scrum, is Sprint Planning waste? It's certainly very time-consuming, although I would argue it's not generally waste. There can potentially be enormous value in aligning the whole team, unifying the team on common goals, establishing a common understanding of what needs to be done, and committing as a team. On the other hand, in some circumstances, when the work is nigh-on impossible to plan and Sprints are routinely disrupted, Sprint Planning can potentially be a big waste of time.
As another example, in eXtreme Programming, is Pair Programming waste? There are some circumstances where Pair Programming is extremely valuable, for instance, when one person is learning from another, to spread knowledge about areas of the code, and to increase quality. On the other hand, if these are not particularly issues for your team, and if the tasks are relatively straightforward, it could certainly be argued that Pair Programming is waste.
It's no wonder people find this all a bit confusing! So what are you meant to make of all this?
My personal suggestion is this...
For those that like and support the underlying key principles of agile, they still apply in Lean. In fact, agile is very Lean compared to traditional waterfall projects. In this respect, Lean thinking is an extension of agile and not a replacement.
For those adopting agile development principles, it can certainly be valuable to adopt some common practices, such as Scrum or eXtreme Programming to bring some structure and process to the principles and help the team to put the principles into practice.
Increasingly it seems to be common practice to use elements of both Scrum and XP, in order to address both the management and engineering aspects of agile. Personally I like this; the two methods are very complementary as they share the same principles and address different issues.
But in adopting these practices, or any other practices for that matter, you could also benefit from Lean thinking. Think hard about your particular circumstances, and whether any of these practices are really waste in your particular situation? If they are, regardless of methodology, you should really try to eliminate them.
One word of caution though. Be sure you really understand the intrinsic value of any process before you eliminate it. Sometimes the benefits are soft and not immediately obvious. Until you really understand the principles, and have practical experience of why they work, you're in no place to adapt them... Agile Practices Are Meant To Be Adaptive, But Only When You're Ready.
Photo by WillShoot