Revisiting Lean Software’s 7+1 Wastes with GenAI and Continuous Delivery

DORA and the State of DevOps Survey/Reports demonstrate that the elite performing software teams follow Continuous Delivery (CD) practices, influenced by Agile and Lean manufacturing. These studies are an incredible gift to engineering leaders, turning what we used to ‘know’ through experience, into a set of hard facts that are hard to dismiss.

With the rapid rise of GenAI tools for software development, it’s also clear to me that there are many new opportunities for teams to optimise their workflows, and this bears itself out in the State of AI-assisted Software Development report by the DORA team. This also adds more flavour to the difficulties and problems I see with teams and AI.

I’ve used the seven wastes (or Muda) to help software teams with continuous improvement over the years, and it feels newly relevant for how we frame the use of AI and continuous delivery techniques.

The 7 wastes have been used by Toyota and Lean Manufacturing for decades for manufacturing and in 2003 it was adapted for Lean Software by Tom and Mary Poppendieck to help software teams optimise their workflows:

• Extra features (originally ‘overproduction’ in Lean Manufacturing)
• Defects
• Waiting
• Hand offs (motion)
• Partially done work (inventory)
• Task switching (transportation)
• Extra processing

In 2006, Norman Bodek added the eighth waste to manufacturing, underutilised talent, adding a much welcomed human element to the tool, and it was largely adopted into Lean Software thereafter.

Having recently worked on Lean Software for Toyota, the company most synonymous with quality and efficiency in manufacturing, I thought now would be a good time to revisit the seven+1 wastes in the light of modern Continuous Delivery Software practices using GenAI.

How do we use the wastes in software?

The wastes are a practical tool for asking better questions and framing opportunities to get better in Continuous Improvement processes, or ‘Kaizen’ as it’s known in Toyota and Lean practices.

I use the wastes as a practical tool at different levels to look how we can improve:

At the organisation or programme level

 

I remember the first time I ever used this process when joining a different company. We mapped the process and identified more than 50% of the design team’s work that went into a bucket that was often not looked at till 2 years later, when it was then out of date and needed to start again. Standing back with the stakeholders and looking at that whiteboard, it was the first time the company had ever understood their own processes, and it became a simple exercise to turn the red pain point and waste stickies into clear steps for improvement and waste elimination.

When we are thinking about an organisation structure, or programme structure and operating model, we will look at this through the lens of wastes to push for efficient alignment and autonomy.

I use various techniques to design the most efficient and effective organisation. I’m a big fan of Team Topologies, Domain Driven Design, Value Stream Mapping/Management and a few other business modelling techniques we’ve developed over the years. The wastes help define clear structural boundaries and relationships when iterating over the operating model. The most common wastes I look at for this area are motion (hand-offs), waiting, and task switching.

Within squads

 

The most stark example I remember is when a very experienced software engineer was working on many user stories at the same time and committing hundreds of lines of code and files in each commit. Using the wastes, and fun team ‘simulation’, he was able to see how the consequences of his actions were not optimal for the team (or even optimal for ‘his steps’) in the value stream.

Primarily, the wastes are  value stream mapping/management, as part of retrospectives.

We visually map the teams’ steps and processes to get from idea, through dev, through to release. We use the wastes to talk about and measure different steps for speed, productivity and quality, and I’ve found that framing leads to greater clarity on issues and solutions. Often, we’ll do a big mapping exercise at times of team forming or storming. In these times, it’s enough to take crude measurements, but as teams become high performing, we move to more automation, with dashboards that visualise the value stream and aid regular reflection.

The State of AI-assisted Software Development report highlights team capabilities and how GenAI can drive both positive and negative outcomes for teams. It highlights Value Stream Mapping as a key exercise for integrating AI effectively.

For individuals and roles

 

In many organisations I’ve seen blame and dissatisfaction placed on ‘Architects’: “why are they bottlenecks and so slow?” It’s often unfairly seen as a problem with individuals.

I’ve preferred to think about this systemically, how can we set up teams and individuals for success? The wastes have helped many teams shift responsibilities between roles and set up clearer processes that have led not only to greater speed and productivity, but also big increases in job satisfaction for teams and architects alike. In later articles, I’ll touch on the role GenAI can specifically improve the Architect roles.

Throughout history, we see a swinging pendulum pattern of how job roles change in line with the technology hype cycle:

• When a new technology emerges, so do the specialist roles to operate that technology – for example when the front-end web exploded beyond basic HTML and CSS, we had a rise in front-end specialists. With the emergence of databases, we had Database Admins. With ‘Big Data’ we had a rise in the need for data scientists and data engineers.
• When multiple adjacent technologies mature at the same time and the ease of use increases, we see a consolidation of roles. We’ve seen a rise in full-stack engineers again. We see boundaries between data engineers and ‘back-end’ devs fade away and with the rise of cloud we’ve seen fewer database administrators with back-end devs taking on the infrastructure automation for back-end and data alike.

Additionally, we see an increasing importance of roles that span the entire value-stream from idea, refinement, dev, test, release, operations. Product Managers, Tech Leads or Engineering Managers, Agile Delivery Managers. The DevOps movement can be fundamentally expressed as a waste reduction exercise.

Taking an intentional approach to evolving roles to meet changing needs, thinking about the wastes of hand-offs (motion) and task switching, minimising waiting and unused talent.

The opportunities and the threats from AI and CD

AI and Continuous Delivery practices afford us great opportunities to improve outcomes and differentiate ourselves and our companies, but they also add complexity and threat to outcomes if approached naïvely. The State of AI-assisted Software Development report eloquently outlines related AI outcomes, and each State of DevOps report covers continuous delivery in a similar fashion.

In this article I’ve shown how I use the wastes in relation to different levels of the organisation.

In the following articles, I’ll tackle each waste in turn and reference how I’ve seen AI and CD practices affect team outcomes through the lens of that waste, and hopefully that will be useful for your value stream mapping, organisation and operating model design or just for you in your role.