Ten Types of Software Engineering Waste
Lessons from the Toyota Production System for Tech Leaders
In my last article, I discussed DevOps culture—a mindset that fosters collaboration and shared responsibility among engineering and other teams to deliver high-quality software quickly and reliably.
The article included a checklist for PEM's subscribers to self-assess their software development practices. You can access these checklists (Google Sheet, FigJam board, and Notion template) here: DevOps Culture Checklist templates.
DevOps culture operates under the assumption that we engage with value streams—processes required to convert an idea into a technology-backed service that delivers value to the customer. The term "value stream" is borrowed from manufacturing and describes the sequence of processes needed to convert raw materials into a finished product. This includes designing, producing, and delivering.
Much like how the Toyota Production System transformed manufacturing value streams in the 20th century, DevOps culture and agile practices are transforming software delivery. In 1945, Toyota optimized production by arranging machines close to each other, syncing their speeds to maintain a consistent pace, and producing materials only as needed, transitioning from batch-and-queue to just-in-time manufacturing.
Today, tech organizations are making a similar shift from waterfall development to lean approaches, delivering in small iterations as frequently as possible.
Why does this matter? Just as Toyota's TPS transformed their manufacturing into a "pull system" (production responding to actual customer orders instead of pre-emptive production), we aim to do the same with software engineering—building technology in response to customer needs rather than assumptions.
The essence of "pull systems" and Toyota's TPS is the elimination of waste from the value stream. Waste is any activity or cost that is unnecessary and does not add value to the customer (as opposed to activities that directly create value or are necessary for value creation).
Here are the types of manufacturing waste defined in the Toyota Production System:
Inventory: The cost of storing materials until they are needed, which might never happen.
Extra Processing: The cost of unnecessary steps that downstream processes do not require.
Overproduction: The cost of producing more items than currently necessary.
Transportation: The cost of unnecessarily moving materials from one place to another.
Waiting: The cost of idle time awaiting completion of previous steps.
Motion (of people): The cost of unnecessary movements, such as picking up and putting down items.
Defects: The cost of rectifying quality defects.
Value: The cost of producing goods or services that do not meet customer needs.
Non-utilized Talent: The cost of unutilized employee creativity and skills.
Types of Waste in Software Engineering
Here, you can find a PDF cheat sheet summarizing this article.
IT value streams, like manufacturing, contain waste. Despite similarities, manufacturing, and software engineering differ significantly. Manufacturing produces physical goods, while software is something virtual. In manufacturing, we usually produce batches of similar things; software is usually a unique, singular thing available to countless users via infinite cloning. Software evolves much faster than manufactured products.
Below, I share my list of types of software engineering waste, which comes from the mix of several sources:
Lean Software Development Waste, described in the book "Implementing Lean Software Development: From Concept to Cash" by Mary and Tom Poppendieck.
Types of waste from the "DevOps Handbook," which builds on the Lean Software Development Waste with additional insights from the authors.
Findings from the research paper "Software Development Waste", which identifies types of software development hardships based on a two-year study.
I hope this list inspires you to identify IT waste in your team and SDLC processes. According to DevOps culture, your role is to reduce or eliminate this waste, optimizing your technology value stream to deliver working software often, in small-batch incremental releases.
Ten Types of Waste in Software Engineering
Here are ten types of software engineering waste that I found useful when classifying my teams’ work:
Partially Done Work and Backlog Mismanagement
Extra / Wrong Features
Defects / Rework
Unnecessarily Complex Solutions
Task Switching and Cognitive Load
Handoffs and Knowledge Loss
Heroics and Rush Mode
Non-utilized Talent
Waiting
Extra, Nonstandard, or Manual Work
Partially Done Work and Backlog Mismanagement
This includes any work that is partially completed and awaiting further action (e.g., review process, missing requirements, QA testing). All WIP (work-in-progress) tasks that sit in the queue for too long lose value as time passes. Returning to them requires refreshing memory, catching up with HEAD commits, and reorienting engineers' focus.
What to do
Backlog mismanagement often stems from ineffective product management, such as insufficient stories from PMs, unclear priorities, or missing requirements.
First and foremost, I recommend assessing the product team's dynamics. Are engineers merely mercenaries expected to complete assigned tasks, or do they actively participate in discovery processes alongside delivery, partnering with the product organization?
For more, I recommend reading: Build a team of missionaries, not mercenaries and Focus on solutions, not problems.
Extra / Wrong Features
These are features or products that nobody needs or wants. Not only do they waste time and money, but they also introduce extra complexity and maintenance challenges. This waste often arises from a mismatch between user needs and business desires.
What to do
The direction of development is not always under the engineering team's control—it often comes "from the top." However, engineers can always invest time in better understanding their business/product, clarifying what customer value their work delivers.
I discussed this in the podcast episode: Day 4 - Company's Strategic Context. I also recommend exploring related articles on this topic.
Defects / Rework
This category includes work that was not done correctly the first time, due to poor testing practices, unclear definitions of done, ambiguous requirements, or inadequate mockups. The effort required to resolve these issues is wasteful, and the longer the time between bug creation and detection, the more difficult it becomes to rectify.
What to do
According to the book "Applied Software Measurement," the cost of repairing bugs grows exponentially the longer they remain undetected. To address this, we need to focus on developing a robust testing pyramid (more quick-to-execute unit and functional tests; fewer slow, complex end-to-end and manual tests) and promote a QA shift-left approach (integrating quality assurance early in the development process and sharing the responsibility for testing among all engineers).
Unnecessarily Complex Solutions
Overengineering involves creating solutions that are more complex than necessary, which may lead to users struggling to use the product (opportunity waste) or a too-complex tech stack, which must be maintained over time.
What to do
Finding the right balance between upfront design and incremental design is challenging. Validating work early to gain customer feedback helps ensure the features we build are actually for them, rather than just satisfying business stakeholders. However, rushing implementation can lead to poor design choices, accumulating technical debt, and necessitating rework.
Investing in skills related to Domain-Driven Design can definitely help here (especially if your product becomes a complex technical platform). I also recommend upskilling your teams in software design patterns, UI/UX patterns, common patterns, and guidelines if you work with front-end technologies.
Task Switching and Cognitive Load
This type of waste occurs when engineers are assigned to too many projects, have too many meetings, and face numerous distractions. Switching between these contexts requires additional effort and disrupts the "flow state," a mental state in which individuals are fully immersed in a task.
What to do
The good old "stop starting, start finishing" applies here. Limiting work-in-progress is one of the most effective ways to reduce cognitive load. Your work is also about protecting your teammates' "flow state," i.e., by ensuring their daily calendar has at least 4 hours of undisturbed work (which can be a challenge with all status meetings and scrum ceremonies, all-hands, brainstorming sessions, and others).
Handoffs and Knowledge Loss
This waste occurs when information or projects are transferred across individuals or teams. Each handoff can result in some loss of knowledge and necessitates relearning. Numerous handoffs can lead to a complete loss of context. Handoffs can also be internal, such as when work is passed between engineers and testers.
What to do
To minimize handoffs at the company level, set up cross-functional teams that can take full ownership of a product or its specific domain/features. An example of this is Amazon's Two-Pizza teams, introduced by Jeff Bezos. At the team level, minimize handoffs by ensuring engineers take responsibility for product quality and reduce dependencies on external QA or monitoring services.
Investing in good knowledge-sharing practices is also crucial. Setting global NFRs (Non-Functional Requirements) or documenting decisions are just a few ways to support this. For more information, read: How to Support Collective Intelligence and Decision-Making.
Finally, when someone leaves the organization, you must act quickly so their know-how isn’t lost forever. More about it here: How to handle employee departure.
Heroics and Rush Mode
This waste is characterized by individuals being pulled from planned work to handle numerous incidents, push last-minute changes, or share domain knowledge they alone possess.
What to do
Avoid reliance on heroes or individuals who work excessively hard. Instead, establish predictable, simple, and understandable processes that can be managed by anyone. Senior members should aim to simplify complex tasks. More on this topic can be found in the article: Senior software engineer, these skills are expected from you.
Building a culture focused on outcomes rather than the volume of work and busyness allows for a high-performing environment where people can grow, change positions, and make the onboarding process enjoyable for everyone. For further reading, see:
Non-utilized Talent
This occurs when skilled team members are given precise instructions on WHAT, HOW, and WHEN to perform tasks, stifling their creativity and problem-solving abilities. It also wastes the potential of leaders who could engage in more strategic activities instead of micromanaging.
What to do
As a software engineering leader, create an environment where skilled individuals can use their creativity to solve customer problems. There are many ways to foster this environment, and I recommend starting with the summary "How to lead a team of senior engineers". You may also want to reconsider your management style and explore approaches like Center-Out Leadership or Developmental Leadership.
Waiting
Waiting results from idle time, often leading to task switching and additional cognitive load. Causes include slow automations in SDLC processes, lack of information, and delayed feedback.
Extra, Nonstandard or Manual Work
This type of waste includes any extra tasks in the SDLC that do not add customer value, such as reviews, approvals, manual steps in release processes, and non-automated reporting.
What to do
Both Waiting and Manual Work require ongoing investment in automation and process optimization. From investing in test automations or CI/CD pipelines to utilizing solutions like generative AI—Copilot, ChatGPT, Gemini, and others—it's crucial that as much of the tedious, repetitive work as possible is automated for your team. To assist with this, I recommend establishing metrics to track with your team and using them as goals and KPIs for your teammates.
For inspiration, look at: Practical solutions to track your goals.
End words
Just as in manufacturing, waste in software engineering causes our teams to focus on the wrong things. Rather than delivering value to customers, we waste our efforts and resources on non-productive activities. Classifying waste is the first step for an engineering leader to introduce DevOps culture into their organization.
Reducing waste is a primary task in optimizing the engineering value stream. If we invest enough effort in this area, we will eventually be able to deliver value to customers through small, frequent, and incremental releases.
This is the first step towards a high-performing engineering team led by DevOps principles.
Love it, thanks for this *very* thorough exploration into different types of waste. I really appreciate the effort it took to pair each type with actionable strategy to expose & solve the root cause. 👍 I'd love to see a beautiful, engaging, *visual* model of your cheat sheet that could be plastered all over common work areas – something that could be digested at a glance. (Wish I had the graphics design skill to do it).
You might also like this – an exploration into using Waste Walks to uncover where the waste is. In my experience getting rid of the waste is half the battle – but the first half is figuring out where the waste is hiding. Hope you enjoy → https://blog.bosslogic.com/p/context-switching-is-killing-your-gains-part-2-85be456e6d92
This was a great read Mirek - and I absolutely loved the cheat sheet.
I think that every company has at least few of those, and it’s always easy for engineers to blame the PMs for all the waste. In reality, a big part of it is under our control, and even what is not - can be influenced.