Software Development Waste
The nine types of waste in software development.
This week I read Software Development Waste, a paper by Todd Sedano, Paul Ralph, and Cécile Péraire. This paper describes the results of a two-year long study that sought to identify the types of waste in software development and explore their causes. The authors define “waste” as “any activity that consumes resources but creates no value for customers… Reducing waste, by definition, improves efficiency and productivity.”
My summary of the paper
The concept of eliminating waste in a system is not new. It was introduced in Womack’s analysis of the Toyota Production System, a system that “prioritized waste removal by creating a culture that pursues waste identification and elimination in the entire production of a vehicle”.
The Toyota Production System characterized seven types of manufacturing waste (see the table below). However, as the authors of this paper note, “adapting a taxonomy from a reference discipline (e.g. manufacturing) for a target discipline (e.g. software engineering) manifests at least four threats to validity…”. This was the motivation for this study: to create a taxonomy of waste specifically for software development.
To better understand software development waste, the authors analyzed data from three sources: 1) a 2+ year participant observation study of eight software development projects at Pivotal (a software development consultancy), 2) interviews with Pivotal employees, and 3) an analysis of the topics discussed in team retrospectives over one year.
The types of waste and their causes
The analysis identified nine types of waste in software development is shown below.
This information may help teams better identify waste that exists within their organizations and determine how to improve.
Because the Toyota Production System and it’s seven types of waste were a motivator for this study, the authors compared their taxonomy for software development to the taxonomy from manufacturing.
“We observed four types of waste not found in Lean: unnecessarily complex solutions, extraneous cognitive load, psychological distress, and ineffective communication. Meanwhile, we did not observe Lean Software Development’s handoff waste type.”
Final thoughts
I love this paper because it breaks down developer friction into a set of clear primitives. It’s an interesting lens through which to think about the developer experience. This framework should be helpful for leaders and teams that are thinking about different ways they can impact developer productivity within their organizations.
That’s it for this week! If you know someone who would enjoy this newsletter, please consider sharing it with them.
As always, reach out with thoughts about this newsletter on Twitter at @abinoda, or reply to this email.
-Abi