Software Development Waste
Reviewed by Greg Wilson / 2021-08-29
Keywords: Software Projects
I've looked back at the end of every software project I've ever been on and thought, "If I'd known then what I know now, I'd have been done in half the time." Despite this, I've never thought carefully about exactly where all the time went and why so much of it felt wasted.
Sedano2017 watched eight projects over a period of almost two and a half years and categorized the waste they saw. They're careful to say that their findings may not generalize, but their taxonomy is still a valuable checklist for any team that's trying to figure out how to be more efficient.
| Waste | Description | Observed Causes |
|---|---|---|
| Building the wrong feature or product | The cost of building a feature or product that does not address user or business needs. |
User desiderata (not doing user research, validation, or testing; ignoring user feedback; working on low user value features)
Business desiderata (not involving a business stakeholder; slow stakeholder feedback; unclear product priorities) |
| Mismanaging the backlog | The cost of duplicating work, expediting lower value user features, or delaying necessary bug fixes. |
Backlog inversion
Working on too many features simultaneously Duplicated work Not enough ready stories Imbalance of feature work and bug fixing Delaying testing or critical bug fixing Capricious thrashing |
| Rework | The cost of altering delivered work that should have been done correctly but was not. |
Technical debt
Rejected stories (e.g. product manager rejects story implementation) No clear definition of done (ambiguous stories; second guessing design mocks) Defects (poor testing strategy; no root-cause analysis on bugs) |
| Unnecessarily complex solutions | The cost of creating a more complicated solution than necessary, a missed opportunity to simplify features, user interface, or code. |
Unnecessary feature complexity from the user’s perspective
Unnecessary technical complexity (duplicating code, lack of interaction design reuse, overly complex technical design created up-front) |
| Extraneous cognitive load | The costs of unneeded expenditure of mental energy. |
Suffering from technical debt
Complex or large stories Inefficient tools and problematic APIs, libraries, and frameworks Unnecessary context switching Inefficient development flow Poorly organized code |
| Psychological distress | The costs of burdening the team with unhelpful stress. |
Low team morale
Rush mode Interpersonal or team conflict |
| Waiting/multitasking | The cost of idle time, often hidden by multi-tasking. |
Slow tests or unreliable tests
Unreliable acceptance environment Missing information, people, or equipment Context switching from delayed feedback |
| Knowledge loss | The cost of re-acquiring information that the team once knew. |
Team churn
Knowledge silos |
| Ineffective communication | The cost of incomplete, incorrect, misleading, inefficient, or absent communication. |
Team size is too large
Asynchronous communication (distributed teams; distributed stakeholders; dependency on another team; opaque processes outside team) Imbalance (dominating the conversation; not listening) Inefficient meetings (lack of focus; skipping retros; not discussing blockers each day; meetings running over (e.g. long stand-ups)) |
Sedano2017 Todd Sedano, Paul Ralph, and Cecile Peraire: "Software Development Waste". 2017 IEEE/ACM 39th International Conference on Software Engineering (ICSE), 10.1109/icse.2017.20.
Context: Since software development is a complex socio-technical activity that involves coordinating different disciplines and skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for the customer or user. Objective: The purpose of this paper is to identify and describe different types of waste in software development. Method: Following Constructivist Grounded Theory, we conducted a two-year five-month participant-observation study of eight software development projects at Pivotal, a software development consultancy. We also interviewed 33 software engineers, interaction designers, and product managers, and analyzed one year of retrospection topics. We iterated between analysis and theoretical sampling until achieving theoretical saturation. Results: This paper introduces the first empirical waste taxonomy. It identifies nine wastes and explores their causes, underlying tensions, and overall relationship to the waste taxonomy found in Lean Software Development. Limitations: Grounded Theory does not support statistical generalization. While the proposed taxonomy appears widely applicable, organizations with different software development cultures may experience different waste types. Conclusion: Software development projects manifest nine types of waste: building the wrong feature or product, mismanaging the backlog, rework, unnecessarily complex solutions, extraneous cognitive load, psychological distress, waiting/multitasking, knowledge loss, and ineffective communication.