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.
|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.
Working on too many features simultaneously
Not enough ready stories
Imbalance of feature work and bug fixing
Delaying testing or critical bug fixing
|The cost of altering delivered work that should have been done correctly but was not.
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
|The costs of burdening the team with unhelpful stress.
Low team morale
Interpersonal or team conflict
|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
|The cost of re-acquiring information that the team once knew.
|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))
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.