Quite some years ago, after attending a presentation about lean production at Toyota, I decided to buy the book “The Toyota Way”. I had the feeling many of their 14 management principles would be applicable to professional services as well. I started reading the book, but never finished. Last weeks I read several posts about lean software development compared to another Agile working method: SCRUM. Honestly, despite the recent car issues that Toyota is facing, I feel both methods, or even a combination of these two, can help us deliver software in a better way.
Is Scrum just the Lean software development approach?
Over a year ago at Goyello we started implementing Scrum, a best practice working method for iterative software development. I believe we managed to implement it very well. We shared our lessons learned while implementing Scrum before. The most important results are increased team commitment, more control of the project progress, better and more frequent client involvement and feedback, well estimated projects and a more predictable work load.
I’m not claiming we managed to implement Scrum to its full extent. Some of our projects are just too small, several clients didn’t manage (yet) to adapt to this way of working yet and an important thing is still lacking: team leadership.
Recently I came across several posts about Lean software development. Especially the posts “There are more alternatives to Scrum”, “Agile is not Scrum” and a comparison by Mathis triggered me. I decided to study Lean software development in more detail. Basically I concluded there are many similarities, but both also provide practices and methods the other is lacking. I start to feel like a combination of the two would fit our needs better. Or may be we should just conclude that Scrum is the Lean approach in software development.
Team leadership not as easy as it seems
The first obvious difference in between Lean software development and Scrum in my opinion is the starting point: Scrum starts with the team while Lean starts with the process.
When you introduce Scrum, the first thing to do is to create a self organizing team which commits to a clear set of objectives in a given sprint length and is protected from too much chaos in its environment.
Till now I have noticed gaining the team commitment isn’t as easy as it sounds. Not everyone dares to commit and besides definitions of commitment differ. Basically I feel this has to do both with the experience of the team and cultural aspects related to trust. I noticed that in several cultures people are afraid to be punished. To prevent this, they won’t lead, they won’t commit. When team commitment is lacking it’s hard to implement Scrum. The success depends in that case on strong leadership within the organization, which is much more part of Lean.
Lean development is about value creation and eliminating waste
Lean Software Development concentrates strongly, but not only, on value creation, quality and eliminating waste. Several principles translate these goals into a number of specific actions. The most prominent tool to use is the value stream map, by which you can analyze the steps and waiting times of a given project or type of projects in an organization. The goal is to reduce the amount of work in progress.
Eliminating waste is refined to specific hints which types of waste to look for: handovers, extra features, partially done work and others. Quality is refined to test automation, test driven development, continuous integration, code reviews and others. Tasks within Lean are not defined as technical “tasks” defining what needs to be developed, but are clear descriptions of the features that needs to be developed derived from “user stories” which resulted into “feature descriptions” which need to have a clear market value.
This mechanism of managing the process “right” in between buying-in and selling-out is exactly what happens in a supermarket, and doing it well is the key to the profitability of the store.
Kanban method to eliminate waste in software development
Agile Kanban focuses on enabling tasks, “Visual” and “Self-directing,” in order to help the team become autonomous and improve their own process. In order to make the process continuously flow as well as to limit work in progress, “iteration meetings” are needed to communicate the information. In the InfoQ article they also explain Sustainable Kanban which adds flow enabling a task to flow individually along the needed process steps. In my opinion both have a huge potential to improve your software development.
Recently we started with our Kanban board as an experiment. For sure it still needs a lot of improvement, but we already notice the difference. The team members realize the project flow better and it´s more clear what we expect from them.
Of course we will keep you posted about our experiences. Before that hapens I’m curious about your opinion and experiences. Please share and let’s learn from each other.
Entrepreneur, co-founder & Managing Director of Goyello and Webmerce. Sociologist and electrotechnical engineer, a great combination that stimulates him to look for working solutions. Passionate about converting great ideas into new solutions. He is married and a proud father of 3 great sons. Participating in (and training for) triathlons to stay fit.