Lean software development involves applying lean manufacturing principles and practices to the software development domain. One of lean's key principles is eliminating waste — but what is waste in software development terms, how can it be eliminated, and what value does its elimination deliver?
Lean principles trace their roots back to the lean production methods used by Toyota. Just as manufacturing is integral to a car maker's success, software development is a critical enabler of digital transformation initiatives.
Lean software development involves applying lean manufacturing principles and practices to the software development domain. The approach can be summarised in seven principles, which are very close in concept to lean manufacturing principles:
In this blog we're discussing the first of those principles: eliminate waste. We look at how NashTech is working towards eliminating waste from software development to deliver additional value to clients.
To eliminate waste, we have to know what it is. Lean philosophy regards everything that doesn't add value to the client as waste. If an activity can be bypassed, or a result can be achieved without it, then it's waste. So all of the following can be defined as waste:
Of course, that's not an exhaustive list. Once we started thinking about waste in software development, we realised there were lots of activities that could be eliminated. We also realised we couldn’t tackle waste elimination on our own.
Understanding what waste is in the software development process is one thing. Getting to the sources of waste and eliminating them is another.
Over many software development projects we've learned that a close partnership with our clients is key to eliminating waste. A client needs to:
Adopting lean thinking is a journey we have to make together. It means leveraging the trust and confidence built by NashTech demonstrating a smooth delivery to influence and drive improvement across the entire project.
Many of the causes of waste are set in motion early in the software development process, such as discussion and planning of requirements and technical architecture.
These early processes - when the product is being defined - can themselves be wasteful. They can deliver late or in an incomplete state for the development teams. And they can build in problems that will cause waste at a later stage, such as:
Let's not forget that another Lean principle tells us: Decide as late as possible. This is another reason to avoid attempting to over-define the product too early on.
We shouldn't rule out the fact that the day-to-day operations of a live application can impose on the development team at short notice.
We've mentioned defects as a source of waste in their own right, but when a production bug (even if mission critical in nature) impinges on a sprint team, the relearning and task-switching involved can lead to more waste.
In a typical project, design and operations functions will often lie with the client's team. This shows why eliminating waste should be a joint goal - and tackling it a joint activity - across the entire engagement.
Once we've worked as a team to:
— we can then look at eliminating waste during code development, testing, and deployment.
Applying the Scrum Agile framework to the development team means we're already guarding - to some degree at least - against the software development wastes identified above.
Ideally, the team will have a guaranteed undisrupted two-week period during which they can:
Work-in-progress limits can be applied to encourage the team to focus on task completion. Avoiding skills over-specialisation of team members - a practice that supports other lean principles - can help here.
Of course, this theoretical perfect sprint supporting lean software development principles is extremely challenging to achieve. What we can say is that the sprint, its ideals and processes must be defended by a knowledgeable and assertive Scrum Master.
The benefits of Agile and lean software development practices may appear simple to achieve, but can prove quite elusive in a real-world engagement. The continuous improvement approach - that will take us from where we are today to where we want to be tomorrow - requires determination and understanding. It also depends on a trustful and open working relationship between partners to tackle shared issues and reach shared goals. Fostering and supporting this ambition is key for any development manager - otherwise they could end up fitting the lean definition of ‘waste’!