7 Wastes in Lean Software Development
The 7 wastes of Lean Software Development are:
Partially Done Work
Extra Features
Relearning
Task Switching
Delays
Handoffs
Defects
Suppose you are in a leadership role – Agile Coach, Scrum Master, or Manager. In that case, you can work with your team and organization to educate them and help people identify and visualize those wastes. This will result in a list of ideas and suggestions for continuous improvement that is highly relevant to them, increasing the chances of implementing those improvements, and minimizing potential resistance.
Let’s take a closer look at each of the 7 Lean Software Development wastes in more detail.
Partially Done Work
What is that?
Simply put, it is all the work that is only partially completed.
Why is this a waste?
If something is not done (no matter the exact definition), it has no immediate value. It is not something you can give to your customers and thus provides no value to your organzition.
It also means you don’t know if it will work as expected, something you can be sure of when users use or test it.
Unfinished work also contributes to the overall number of items you have in progress. If we don’t keep an eye on how many things are in your development pipeline, it can quickly become overwhelmed. You won’t be able to finish anything and start working on new projects resulting in a downturn in productivity (and that may happen very fast).
Let me refer to the famous Little’s law – the throughput of you or your team depends on how much work you have in progress and how much it takes to finish each one of the items. The more you start, the more you don’t complete – the more productivity will suffer.
Some examples
Think of anything almost done – in software development that might be code in a local branch and not integrated into the central repository. In that case, it is functionality that’s not fully tested. Similar to requirements that are thoroughly detailed and completed in advance but are not implemented.
How to minimize it?
Some ideas on how you might reduce and minimize partially done work:
Clarify what done means.
Whether Definition of Done if you use Scrum or concrete and explicit policies if you use Kanban, there should be a clear understanding of what counts as finished and what doesn’t. Without that, people may lack clarity about the expected result, and everyone may have a different interpretation. This may be not only a source of wasteful activities but also disagreements and potential conflicts.
Focus on finishing work.
Stop starting new things before finishing what you are currently working on. It can be that simple, and implementing this kind of discipline will soon pay off. If you face external pressure – educate your stakeholders and don’t hesitate to seek support.
Don’t demonstrate unfinished items on Sprint Reviews (if you do so).
This practice promotes partial completion because you demonstrate unfinished work. Besides, you may confuse and mislead the stakeholders if you do this as they may think something is finished since they saw a demo.
Set some limits on ongoing work
You may start with a very pragmatic agreement, like working on one thing at a time and avoiding multitasking. Once you have the continuous flow of completed work, you can experiment and further optimize the limits. We will discuss this in more depth in the section for addressing Task Switching waste.
Extra Features
What is that?
Features that are not requested or needed by your existing or potential customers.
Many think this is a rare situation; unfortunately, that’s not the case. According to the Standish Group report for 2018, half of the features created are hardly ever used (read an article here).
Why is this a waste?
Developing unused features is the ultimate form of waste. Even if you have the perfect development process and have delivered a high-quality feature, you spent resources developing something no one will use.
“BUILDING SOMETHING NOBODY WANTS IS THE ULTIMATE FORM OF WASTE.”
ERIC RIES
Not just that, but these unneeded features contribute to the system’s overall complexity requiring someone to document, maintain, support them. Not to mention any potential changes in architecture needed to bring them to life.
Some examples
A good source of insight is analyzing your existing product and identifying the usage of various features. Another source can be looking at current requirements and asking how the features being developed will bring value.
How to minimize it?
Know your market, customers, and users.
Invest in understanding your market, customers, users, and their needs! Understand their problems and potential opportunities before jumping into possible solutions will be invaluable. I am a big fan of using Design Thinking so expect more on this topic in the future.
Validate ideas early and often
Use iterative and incremental approach and validate different coded and non-coded assets along the whole software development lifecycle.
This will give you the chance to start learning before investing a lot in feature development. You can test business models, mockups, prototypes, conduct focus groups to identify features your customers will want and use. I will write a dedicated article on this topic in the near future.
You can often also release functionality iteratively and incrementally and adapt your plans based on customer feedback and/or specific metrics you observe. For example, if you release functionality that you expect to grow your product’s daily active users, monitor it closely to see if that happens or not.
Check your opinion
Try to base your decisions on research and validated learnings. Your opinion of what is supposed to be valuable can guide you but should not be the only source of insights. It is best not to make decisions in a vacuum; seek input and validate your decisions before implementing them. Implementing something just because you think it’s cool is not always a good idea.
Ask yourself – What makes us believe that what we are doing will bring value to our customers and users?
Relearning
What is that?
Relearning is when people have to spend time recalling information or re-discovering knowledge they once knew but have since forgotten. It also includes re-creating knowledge that already exists within the team or organization but isn’t easily accessible.
Why is this a waste?
Time spent relearning is time not spent delivering value. Every minute someone spends trying to remember how a system works, where to find documentation, or how a process was performed is time that could have been spent progressing on actual work.
It also introduces risks — people may remember incorrectly or reinvent inefficient solutions instead of building upon previous learning.
Some examples
Developers frequently needing to re-figure out how to set up local environments.
Teams recreating the same onboarding guides or architecture diagrams because the originals were lost or outdated.
Bug fixes being applied multiple times to similar issues because knowledge was not shared effectively.
How to minimize it?
Invest in documentation
Documentation should be lightweight, practical, and part of the natural workflow — not a heavy burden. Think of it as just enough information to help your future self or your teammates.
Focus on documenting key decisions, architecture overviews, onboarding steps, and critical operational knowledge. Keep it evolving — outdated documentation is almost as bad as no documentation.
Knowledge sharing practices
Encourage the team to actively share knowledge in a structured way. Pair programming and mob programming are fantastic because they foster real-time information flow.
Demos, lightning talks, and internal technical sessions also allow people to present what they’ve learned, recent challenges, or cool solutions they discovered. Formal Communities of Practice can also be a great way to connect people with shared interests across teams and departments, preventing silos.
Make information easy to find
Create a single source of truth for documentation, knowledge articles, onboarding guides, etc. It should be easily searchable, well-organized, and accessible to everyone. Think of it as your team's internal "Google." People shouldn't have to waste time chasing down documents across dozens of folders, chats, or private drives.
Tools like Confluence, Notion, or even a well-structured shared drive can work — what matters is that it’s easy, trusted, and maintained.
Create a culture of learning
Shift the mindset: learning and sharing shouldn’t be treated as secondary tasks. Build them into your team’s narrative of “how good work looks like”
Celebrate when people take time to capture learnings or improve documentation. Create space during retrospectives to discuss not only “what went wrong” but also “what we learned.”
Remember: teams that invest continuously in collective knowledge build momentum over time — they don't just deliver faster; they deliver smarter.
Task Switching
What is that?
Task switching happens when individuals or teams are forced to jump between different tasks, projects, or contexts frequently.
Why is this a waste?
There’s a cognitive cost every time someone shifts focus. Studies suggest that even a brief interruption can take over 20 minutes to regain full focus. Multitasking creates a false sense of productivity but significantly reduces actual efficiency and quality.
Some examples
Developers working on multiple projects simultaneously.
Constant interruptions during the day with "quick questions" or "urgent" new requests.
Meetings breaking up large blocks of focused work time.
How to minimize it?
Limit work in progress
Encourage individuals and teams to work on fewer things at the same time — ideally just one task per person if possible.
Limiting work in progress (WIP) reduces context switching, increases focus, and shortens the time it takes to complete items. You can start with simple WIP limits in your boards (like 1–2 tasks per person at a time) and adjust them based on what you learn.
The mantra is simple: Stop starting, start finishing.
Protect focus time
Deep work requires uninterrupted time. Help the team establish "core hours" with no meetings, no interruptions, and minimal context switching.
Some teams use “Focus Fridays” or “No-Meeting Mornings” to carve out time to get meaningful work done.
As a leader, you can role model this behavior by also protecting your own focus time — and respecting others' blocks.
Prioritize effectively
Not everything is equally important. Work with stakeholders to set clear priorities and communicate them clearly to the team.
Teach them to think in terms of business value, customer impact, and urgency — and make the hard calls when necessary.
Without clear prioritization, teams try to "do it all" and end up spreading themselves thin across multiple tasks, hurting overall outcomes.
Visualize the work
Make work visible! A simple Kanban board can help everyone see exactly how many tasks are in progress, where bottlenecks are happening, and how work is flowing (or getting stuck).
When task switching becomes visible, it’s easier to have conversations about reducing it. You can even go further by tracking how often tasks are started and stopped or how many interruptions occur, helping build a stronger case for minimizing switches.
Delays
What is that?
Delays occur when work is waiting for something — approvals, inputs, clarifications, resources, or simply because of low prioritization.
Why is this a waste?
Delays slow down the entire system. Work sitting idle does not deliver value, but it still consumes mental space, increases risk (requirements may change over time), and delays feedback that could otherwise help correct issues early.
Some examples
Waiting days or weeks for pull request reviews.
Delays in decision-making because stakeholders are unavailable.
Dependencies on other teams that are not ready.
How to minimize it?
Shorten feedback loops
Delays often happen because feedback comes too late. Work on getting faster feedback at every step — faster code reviews, quicker business decisions, and earlier testing.
Aim for cycles that are measured in hours or days, not weeks. Techniques like continuous integration, automated testing, and incremental delivery (small, frequent releases) help keep feedback loops short and actionable.
Empower teams
Where possible, decentralize decision-making. Give teams the authority to make decisions within clear boundaries instead of waiting for approvals that create bottlenecks.
A well-aligned team that understands the business goals can often make faster, better decisions than a team that needs to escalate everything upwards.
Proactively manage dependencies
Dependencies are a common cause of delays, especially in larger organizations. Start identifying dependencies during planning, not after work has already started.
Work together with other teams to align timelines, and if possible, remove or reduce dependencies by building more self-sufficient, cross-functional teams.
Also, consider dependency boards or maps to make these risks visible and manageable early.
Make delays visible
Delays are dangerous when they are hidden. Use visual management tools — like Kanban boards — to highlight blocked work, waiting states, and stuck items.
You can use indicators like red stickers for blocked items or separate “waiting” columns. When everyone can see where delays are happening, it becomes much easier to address them collaboratively and quickly.
Handoffs
What is that?
A handoff happens when work is passed from one person or team to another, such as from development to testing or from one team to another team.
Why is this a waste?
Every handoff introduces the risk of miscommunication, loss of information, and delays. The more steps something must pass through, the greater the chance it will slow down, get misunderstood, or be deprioritized.
Some examples
Requirements moving from business analysts to developers to testers sequentially.
Infrastructure work passed back and forth between operations and development teams.
Feature development divided among multiple specialist teams instead of one cross-functional team.
How to minimize it?
Cross-functional teams
Form teams that have all the skills necessary to deliver value from start to finish, minimizing the need to pass work between separate groups.
A true cross-functional team can handle requirements gathering, design, development, testing, deployment, and even support — without waiting on outside specialists. The fewer handoffs you have between silos, the faster and more reliably you deliver.
Automate as much as possible
Automation removes many of the manual steps that traditionally required handoffs.
Implement continuous integration (CI) so that code merges and validations happen automatically. Add automated testing to catch defects early. Use continuous delivery (CD) pipelines so deployments don’t rely on manual approvals or operations teams stepping in.
The more you automate routine processes, the less you need to hand over work — and the faster your cycle time becomes.
Collaborate early and often
Instead of sequential handoffs, engage all necessary people earlier in the process. Involve testers in planning. Bring ops engineers into design discussions. Include business stakeholders during refinement sessions.
Early collaboration ensures that potential issues are spotted and addressed before they become costly rework later. It also means less back-and-forth between groups because everyone is aligned from the start.
Defects
What is that?
Defects are mistakes, bugs, or quality issues that must be fixed.
Why is this a waste?
Defects consume resources to detect, diagnose, fix, retest, and redeploy. They also hurt customer trust and satisfaction if they make it into production. Additionally, the longer a defect remains undiscovered, the more expensive it is to fix.
Some examples
Bugs discovered late in the release cycle, causing last-minute fire-fighting.
Misinterpretation of requirements leading to rework.
Performance issues found only after launch.
How to minimize it?
Build quality in
Don’t treat testing as something that happens only at the end. Shift quality assurance to the earliest possible stages — review requirements critically, test ideas, and validate assumptions before writing code.
Throughout development, apply continuous testing practices so that quality becomes an integral part of the process, not an afterthought.
Remember: The earlier you catch a defect, the cheaper and easier it is to fix.
Frequent integration
Integrate code changes into the main branch frequently — at least daily if possible. Frequent integration helps surface conflicts, defects, and unexpected side effects early when they are still manageable.
Delaying integration leads to painful "merge hell" scenarios where issues pile up and become much harder to untangle.
Peer reviews and pair programming
Leverage the power of collaboration to find mistakes early. Peer reviews (pull request reviews) encourage knowledge sharing and can catch bugs, inconsistencies, or architectural issues before they make it into production.
Pair programming takes it a step further — two sets of eyes on the same code significantly reduce the chances of defects slipping through.
Invest in test automation
Automation is your safety net. Develop a solid suite of automated tests — unit tests, integration tests, and end-to-end tests — to ensure your system behaves correctly even as it evolves.
Automated tests provide fast feedback, increase confidence during changes, and dramatically reduce the cost of regression testing.
The goal isn’t just to test more — it's to test smarter by embedding testing directly into your development workflow.
Final Thoughts
By recognizing and addressing these 7 wastes in Lean Software Development, you can dramatically improve your team's ability to deliver value efficiently and sustainably.
Small, consistent improvements — guided by awareness of waste — will result in a big impact over time. Focus on working smarter, not harder, and help your teams spend more time on the work that truly matters.
Stay tuned — I’ll soon share some actionable frameworks and practices to help your teams identify and eliminate waste continuously!