DEV Community: Matt Shaw

Muri: The Root Cause of Overburden

Matt Shaw — Sun, 05 Apr 2026 17:55:02 +0000

Part 1 of this series was about recognising waste (Muda) and Part 2 was about how uneven flow (Mura) creates that waste. This final part is about the force that gives rise to both. The Japanese term Muri (無理) roughly translates to "overburden" or "unreasonable load". In the original Toyota Production System, Muri was physical: asking a worker to lift a box that was too heavy. In modern software delivery, it is the invisible pressure we put on the two load-bearing parts of any technology organisation: the people who change the system and the system they are forced to change.

It's not dramatic, it's not loud and it doesn't announce itself with outages. Muri accumulates slowly and becomes the norm. And because of that, it's the most dangerous of the three.

There's a well-known paper called Boiling Frogs by GCHQ that describes how organisations degrade not through a single catastrophic mistake, but through a gradual series of tiny concessions. A workaround here, an exception there, a deadline accepted "just this once". The water warms degree by degree and no one jumps out. They acclimatise, they adapt and they cope.

Then one day, the system is brittle, the team is exhausted, and delivery feels like wading through treacle, but no one can quite explain how it happened. This is how Muri works.

Overload on People

Software is not manufacturing. Our raw materials are ideas held in human working memory. In knowledge work, burden manifests as cognitive and emotional overload, which we often describe as "burnout", as though it were a personal failing rather than an environmental response.

Cognitive Load

This is the "brain overburden" of a system that is too complex, too coupled, or too poorly documented for a single human to hold in their head. This high cognitive load is chronic stress. We inflict this on people when we force them to:

Navigate sprawling "big ball of mud" architectures.
Constantly shatter their focus with cross-team dependencies and context-switching.
Understand the entire, complex system just to make one minor change.

It's a direct reflection of a fragmented organisation. As Conway's Law observed decades ago:

"Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure".

If you have siloed "Frontend", "Backend", and "Database" teams for example, you are destined to create a system with high-friction handoffs and a coupled, high-burden architecture. You are, in effect, shipping your org chart.

We can fix this with a modern, sociotechnical toolkit:

Domain-Driven Design: This is our analytical tool. It's how we discover and map the business domains, capabilities and value-streams that matter, defining clear Bounded Contexts that tame the "big ball of mud." It's how we draw the map.
Reverse Conway Manoeuvre: This is our strategy. Instead of letting our bad org chart dictate our bad architecture, we consciously invert it and design good team structures around the good architecture that we want to have.
Team Topologies: This is our operating model. It's the practical "how-to" for executing the manoeuvre, giving us patterns (Stream-aligned, Platform, etc.) to build teams that have ownership and autonomy over clearly defined domains with a manageable cognitive load.

A Practical Sociotechnical Approach

If you only try to fix the symptoms with superficial changes you will fail, because it does not touch the root cause: the deep, systemic mismatch between your software architecture and your team structures.

We like to separate "the people stuff" from "the technical stuff" because it's tidier that way. But software architecture and team structure are two expressions of the same underlying system. Therefore, meaningful architectural improvement doesn't begin in diagrams. It begins with team design. This isn't just theory; it's an actionable strategy.

It would be too costly and time consuming to enact this approach for an entire organisation in one big hit. So, although these steps read linearly, in practice they're iterative, overlapping, and most effective when applied to one domain at a time. Pick a single Bounded Context to start with. Don't pick the simplest one, or the smallest one, pick something in the middle, with enough gnarly parts to overcome that will prove the approach is resilient, repeatable and credible.

Map Your Business: First, stop guessing. Use the analytical tools from Domain-Driven Design, like Event Storming or Context Mapping, to create a true map of your business value streams. This isn't a technical diagram for engineers; it's a strategic map of what your business actually does and where the natural seams lie. This process reveals your true Bounded Contexts.
Define Your Target Architecture: Once you have your map, you can make the strategic-level decisions. You intentionally design the target architecture that aligns with those Bounded Contexts. This blueprint, where services and products have clear, single owners, becomes the model for your new organisation.
Execute the Manoeuvre: Now, execute the Reverse Conway Manoeuvre. This is the leadership act of re-organising your people to match the target blueprint. Use the Team Topologies patterns as your guide. Your Bounded Contexts become the mission for new Stream-aligned teams. Common, repetitive work that burdens them is extracted and given to Platform teams. This isn't just moving boxes on an org chart; it's empowering teams with a clear mission and sustainable cognitive load.
Defend the New Boundaries: A new org chart is useless if you don't defend it. You must rigorously define and protect the interaction modes for your new teams. It can be useful to define a "Team API", not a software interface, but a clear agreement on how the team works, communicates, and accepts requests. This is how you make the change stick. It prevents the old, high-friction patterns of communication and dependency from creeping back in, ensuring your new, low-stress, high-flow state is sustainable.

This plan is a fundamental, sociotechnical operation. This is hard, expensive, and political work, but it's unavoidable.

Psychological Safety

The sociotechnical plan above will not work if you do not simultaneously address "emotional overburden". This is the pervasive anxiety generated by a culture of low psychological safety. It is just as important as balancing cognitive load, if not more so, because people that don't feel safe will not engage with profound organisational change, and change requires trust.

That plan requires individuals to do things that would make them feel vulnerable in a low-trust environment:

Be honest about how things really work.
Challenge existing boundaries, power structures, and "the way we've always done things".
Admit ignorance and ask "stupid" questions.
Debate and disagree (respectfully) with colleagues and managers.

The Accelerate and DORA research provides strong evidence for this. A culture of fear and blame, where people are punished for failures, unreasonable deadlines are normalised, or raising concerns is seen as "negative", is a significant predictor of low performance.

This culture is a factory for anxiety. When people are constantly afraid of making a mistake, of being blamed, or of not looking "100% busy", their mental health deteriorates. They live in a constant state of fight-or-flight, which is fundamentally incompatible with the creative, complex problem-solving our work requires.

This is the breeding ground for "hero culture", where individuals are praised for surviving unsustainable pressure. But this heroism only proves that the organisation has already failed them.

Overload on Systems

The other half of Muri is the overburden we place on our systems. The most common name for this is Technical Debt.

This is frequently misunderstood as "old code", or even just "someone else's code". It isn't. It's the accumulation of shortcuts, compromises, or outdated assumptions - sometimes made under pressure, sometimes simply made with limited information - that increase the cost or risk of future change.

It's what happens when we optimise for delivery speed in the short term, at the expense of resilience and maintainability in the long term. The codebase remembers every time we said, "We'll clean this up later". But later rarely comes. Over time, these choices form a fossil record of the organisation's priorities and stress patterns.

We can fix this by absorbing, removing and preventing it.

Platform Engineering

In a high-load organisation, every stream-aligned team is burdened with reinventing the wheel. They must solve for infrastructure, compliance, security, and delivery in addition to their core mission.

This is the overburden of figuring out complex cloud-native tooling, navigating a security sign-off process, or manually building a monitoring dashboard just to get a new service live. It's the friction that grinds delivery to a halt.

A good internal developer platform is treated as an internal product and served by a Platform Team (as defined in Team Topologies). Its purpose is to reduce the cross-cutting cognitive load and present it to stream-aligned teams as a set of simple, self-service tools and APIs.

The goal is to pave a low-friction path to production. A developer shouldn't have to become an expert in container orchestration, infrastructure-as-code, or observability just to ship a feature. They should be able to consume these as reliable services, allowing them to focus all their cognitive energy on solving problems and delivering user value.

Continuous Refactoring

Continuous Refactoring is the act of paying technical debt back, not in a single "big bang" project, but as a small, daily, professional practice.

This is the core discipline of Extreme Programming: leaving the code cleaner than you found it. Kent Beck's recent work, Tidy First?, gives a modern name to this practice: it's the art of making small, safe, tidying changes before adding new features, to ensure development speed is sustainable. It requires an organisational commitment to allocate capacity for this work and making technical debt removal a constant and sustainable activity.

Evolutionary Architecture

This is the strategic mindset that prevents future overburden. An evolutionary architecture is one designed to change. Instead of a brittle plan (or Big Up Front Design), it is a system protected by automated guardrails called Fitness Functions; a suite of tests that continuously verify critical architectural characteristics like performance, security, or module dependencies.

This is the modern, automated, and living implementation of what we used to call "Non-Functional Requirements". Instead of a requirement being a forgotten line in a document, it becomes an automated test that prevents systemic debt from accumulating. This allows the system to evolve safely and independently, creating an environment where small, safe changes are always possible.

The Anti-Patterns

The uncomfortable truth is that we actively create and institutionalise overburden through our own processes and anti-patterns, often in the name of "efficiency" or "control".

Estimation as Commitment

This is the most common and toxic way managers create unreasonable pressure. An estimate is a guess, a statement of probability, at best. A commitment is a promise. Turning a guess into a promise by default is an act of applying unreasonable, arbitrary load. This single act forces teams to cut corners (creating Defects), work in unsustainable "crunch" cycles, and ultimately causes burn out.

Productivity Paranoia

This unintentionally generates mistrust. It's the desire to make sure developers are busy, often by measuring counter-productive metrics like "lines of code", "story points delivered", or "JIRA tickets closed."

This practice is a perfect example of Goodhart's Law:

"When a measure becomes a target, it ceases to be a good measure".

This forces teams into performative work only to satisfy the metrics. It creates immense, unreasonable pressure to prioritise the visible and measurable over the important and sustainable. Teams stop doing the invisible, preventative work (like refactoring or documentation) because it doesn't "count", thus accumulating more systemic burden and technical debt.

Hero Culture

Hero Culture is what happens when chronic overload becomes normal and the organisation quietly begins to rely on individuals who can absorb unreasonable load through personal sacrifice. The late-night deployment, the weekend fix, the 2am incident save, these become celebrated behaviours.

Hero Culture is seductive because it feels like excellence. But it is actually the loudest symptom of failure: a system that only works when someone suffers. And because heroism "works" in the short term, it prevents leadership from seeing the real problem: the system is overburdened, brittle, and unsustainable. Heroes are not a strength. They are a warning sign.

These Ideas Are Not For Sale

Obviously, the core ideas in this series are not uniquely mine. They have been articulated before, clearly and generously, by practitioners and researchers who have been solving these problems for decades. What I have tried to do is consolidate them in context, highlighting modern practices and methods that have emerged as industry leading since the Poppendiecks' original work on Lean Software Development.

What makes these ideas so accessible is that their source texts aren't trying to sell you anything. They are not frameworks. They do not come with a mandatory certification path, a five-day training plan, proprietary toolchains, or a lucrative consultancy engagement. They are simply good ideas. Many aren't even new; we've had the playbook for more than two decades.

They have been tested, refined, and over time, empirically proven to be the foundations of high-performing, sustainable, and humane technology organisations. They still hold up today, because they were grounded in reality to begin with.

Conclusion

Muri is the root cause, the "boiling frog" that normalises overload until it's too late. Because it is the root cause, it cannot be solved with a new tool, a dashboard, or a superficial "transformation".

We can now see the complete chain of events: Overload (Muri) causes Irregularity (Mura) which causes Waste (Muda).

The solutions are fundamental and sociotechnical. You must solve the two primary sources of overburden:

For People: This requires the deep, structural work of mapping your business domains (Domain-Driven Design) and fundamentally redesigning your teams (Team Topologies, Reverse Conway) to have a manageable, autonomous scope.
For Systems: This requires a toolkit of absorbers (Platform Engineering), removers (Continuous Refactoring), and preventers (Evolutionary Architecture).

The Choice You Can No Longer Ignore

This is not just a theory; this is a practical diagnostic toolkit. You can use it to see the waste, measure the flow, and identify the sources of overload that are slowly burning out your people and corroding your systems.

And it leaves every single person reading this with a choice...

For teams, the choice is to stop normalising the pain. Stop accepting unreasonable load as "just part of the job". You are not a "hero" for surviving burnout; you're operating inside a system that makes heroism necessary. The modern practices in this series are not "nice-to-haves". They are essential professional tools. Start using them. Demand the time to use them. Prove their value by showing that they really work.

For leaders, the choice is more profound. You are the only ones who have the leverage to fix the system. You can fund a platform. You can sponsor a sociotechnical action plan. You can build a culture of psychological safety that eliminates fear. You can choose to measure outcomes and sustainability, not just activity and output.

The alternative is to keep adding more governance, processes, planning, coordination, ceremonies, frameworks, tooling, committees, dashboards, and transformation programmes.

But make no mistake: you are just rearranging the deck chairs on the Titanic.

Mura: The Source of Uneven Flow

Matt Shaw — Sun, 05 Apr 2026 17:49:55 +0000

In part 1, we explored the eight wastes (Muda) as the visible symptoms of inefficiency in software delivery. We saw how waste shows up in unfinished work, handoffs, long waits, rework, and lost talent. Those are the effects we can observe and feel.

Those wastes are almost always the result of Mura (斑), a Japanese term from the Toyota Production System meaning "unevenness" or "inconsistency" in how work flows. It is the "hurry up and wait" cycle: periods of low activity followed by periods of frantic catch-up, that make delivery unpredictable and unsustainable.

This post examines in depth how to identify uneven flow, and how modern software delivery practices work together to reduce inconsistency and create predictability.

The Detection Kit

The principles of Lean have been empirically validated for software delivery by the extensive research in the Accelerate book and the ongoing DORA programme. This work gave us the four key metrics that are now the industry standard for measuring high-performing teams.

The DORA metrics are not performance scorecards; they are flow indicators. The goal isn't simply to achieve "good" numbers. The goal is to reduce variance.

Lead Time for Changes

What it tells you: A high average Lead Time is a problem, but a high variance (or standard deviation) is a warning signal.

If your team delivers one feature in two days, but the next one takes forty, your system isn't just slow, it's chaotic. This variance makes forecasting impossible. It's the single best indicator that your process is unpredictable and riddled with hidden blockers (like Waiting for code reviews or environments). A smooth flowing system has a tight, predictable Lead Time.

Deployment Frequency

What it tells you: An inconsistent deployment cadence is a clear sign of batching and queues.

Deploying twenty changes on a Tuesday afternoon and then nothing for four days isn't high frequency; it's batched and irregular delivery. It's a sign of an uneven system that queues work up for a "Release Day", creating a massive Inventory of undeployed code. A smooth flowing system has a consistent, rhythmic deployment cadence - or even better, deploy on-demand.

Change Failure Rate

What it tells you: A spiky Change Failure Rate is a lagging consequence of rushed work.

A spiky CFR often indicates a deadline-driven "crunch" cycle. The team was forced to rush to meet an arbitrary sprint boundary or release date. They cut corners, skipped tests, and force pushed their way to "done." The resulting spike in Defects is the unavoidable effect of that unevenness.

The Solutions

Unevenness is created by push-based systems, where work is started regardless of downstream capacity. If we push unrefined work onto teams, or push untested code into a release branch, or push a sprint's-worth of "done" work onto the testers on the final day, we're actively creating instability.

The solution is a fundamental cultural and technical shift to pull-based systems, where work is started only when downstream capacity is available.

The Management System

Kanban (not just a "JIRA board") is a management system for diagnosing and stabilising flow.

The key to Kanban is the Work in Progress (WIP) limit. A WIP limit is not a process bottleneck, or a constraint on productivity; it is a deliberate countermeasure. It is a simple rule that forces the team to stop starting work and start finishing it.

WIP limits relentlessly expose hidden bottlenecks, making the Waiting, and the unevenness painfully visible. By forcing the team to pull new work only when capacity is available, WIP limits naturally smooth the flow.

This effect is not just philosophical; it's mathematical. Queueing theory shows that as a system approaches full utilisation; its cycle time increases non-linearly. In other words, when everyone is "100% busy," work does not finish faster, it finishes much slower. High WIP means more context switching, more Waiting, and more unevenness. A WIP limit creates slack, and slack creates flow.

The Cultural System

A pull-system on its own can still be thwarted by organisational structures and silos. The largest and most damaging bottleneck in traditional IT is the "wall of confusion" between Development and Operations. This isn't just a handoff; it's a fundamental conflict of incentives.

In this broken model, developers are incentivised to deliver change (go fast), while operations are incentivised to maintain stability (go slow). This conflict guarantees a stop-start process of Transportation followed by prolonged periods of Waiting. If a deployment fails, the work is thrown back, creating Defects and halting all forward progress.

The DevOps movement is the cultural countermeasure. By unifying ownership and responsibility ("you build it, you run it"), it aligns these incentives. The team is now incentivised to build operable and stable features from the start. This cultural shift is the prerequisite for true, continuous flow, as it replaces these two large silos with a single, empowered team.

The Technical System

A high-trust, continuous flow doesn't happen by accident. It is a technical foundation of built-in quality. You cannot have continuous flow if you are constantly finding Defects.

The practices championed by Extreme Programming (XP) enable this:

Test-Driven Development (TDD) builds a regression-proof suite of automated tests that gives teams the confidence to merge and deploy continuously.
Behaviour-Driven Development (BDD) creates a shared understanding of the requirements, ensuring that the right code is built the first time, reducing the wasteful Transportation handoffs between "dev," "test," and "product."
Pair Programming is a continuous, real-time code review. Instead of work Waiting for an asynchronous review, quality is validated as the code is written.

XP practices don't just improve quality; they make the pull-system more reliable and trustworthy, in turn reducing the variance in lead time.

The Ideal

In the Toyota Production System, the ultimate solution for Mura was the ideal of "One-Piece Flow" - making one part at a time and moving it immediately to the next step, with zero Inventory in between.

The modern software equivalent is Continuous Delivery, supported by trunk-based development, automated testing, and fast deployment pipelines. Continuous Delivery approximates one-piece flow by reducing batch sizes, shortening feedback loops, and ensuring that each change can move smoothly into production without accumulating Inventory.

In a high-flow system, a single commit can be built, tested, and deployed within minutes. This is the closest practical expression of the same principle: work should move continuously, without queueing, batching, or delay.

The Anti-Patterns

This is where our industry so often gets it wrong. We adopt "agile" practices that, through misunderstanding, make flow more uneven.

Misusing Story Points

This is perhaps the most insidious anti-pattern, because it presents itself as a predictability tool while actively producing uneven batches. In theory, story points were intended as an internal estimation shorthand for teams. In practice, velocity is quickly weaponised into a delivery target. This creates a push-system where teams play sprint-Tetris, packing work to hit a number rather than maintaining flow. The result is uneven batches, rushed work, and Defects created simply to get "committed" points accepted.

Ron Jeffries, one of the early advocates of story points in XP, has even said: "if I did invent story points, I'm probably a little sorry now", in response to how commonly they are misused. The Lean alternative is to stop treating estimation as forecasting, and instead focus relentlessly on making batch sizes small, stable, and consistent.

"Scrum-fall"

This is an anti-pattern disguised as Agile. Work piles up at the start of the sprint and testing piles up at the end, creating a mini-waterfall inside timeboxes. This guarantees unevenness, reinforces handoffs, and produces the "hurry up and wait" cycle that drives Defects and Overprocessing. The countermeasures are practices like Pair Programming and Behaviour-Driven Development, where building and checking happen together, not in sequence.

"JIRA-First"

This is the anti-pattern of treating JIRA (or any work-tracking system) as a ticket-pushing workflow. The focus becomes moving cards through states rather than improving flow. This incentivises starting work ("In Progress") over finishing it (WIP limits and flow efficiency). JIRA becomes a status reporting tool, not a system for managing value. The result is bloated Inventory and chronic WIP that never seems to get to "Done".

SAFe (and the Agile Release Train)

This is the most elaborate and costly form of institutionalised ceremony. The Agile Release Train is a large-batch planning and coordination mechanism presented as agility. It produces the illusion of control, but synchronised big-batch planning events make flow uneven and unpredictable. In practice, this leads to integration crunches and "hardening phases," which are a tacit admission that the system generates more waste than it removes.

SAFe attempts to manage the symptoms of unevenness, rather than eliminating the causes. It is a coping mechanism for organisations struggling with deep Muri (dependencies, brittle systems, low trust) but unwilling or unable to reduce cognitive load or decouple teams.

Conclusion

Mura is not just a vague feeling of chaos; in modern software delivery teams it is a problem you can detect and measure using DORA metrics. It is the "hurry up and wait" pattern that creates the waste (Muda) and symptoms of inefficiency.

Unevenness is not "a system problem", it is almost always the direct result of:

capacity overcommitment
deadline-driven delivery
multi-projecting
fractured ownership
incentives that reward starting rather than finishing

The solution is not another tool or framework, but a fundamental cultural shift from a push mentality to a pull system. By embracing WIP limits (Kanban), a DevOps culture, built-in quality (TDD & BDD) and the ideal of Continuous Delivery, we can tame the chaos. We can move from unpredictable delivery to a smooth, sustainable, and high-performance flow.

These patterns are rarely accidental; they are the system's response to overburden, or Muri, on our people and our technology, which we will uncover in the final part of this series.

Muda: The Eight Wastes of Modern Software Delivery

Matt Shaw — Sun, 05 Apr 2026 17:34:14 +0000

In manufacturing, Lean thinking revolutionised how products were built by relentlessly eliminating waste. Whilst the "software factory" analogy isn't perfect, the core Lean principle of eliminating waste underpins modern software delivery, from Agile and DevOps to Continuous Delivery and Platform Engineering.

In Japanese, Muda (無駄) means "waste" or "futility" - any activity that consumes resources but creates no value. During the development of the Toyota Production System in the late 1940s through to the 1970s, Taiichi Ohno identified seven types of waste that hinder efficiency and productivity. Over the years, Lean practitioners have adapted these for software and added a widely recognised eighth form of waste - often considered the most critical of all.

Decades later, research from Accelerate and the DORA program has validated these same Lean principles as the foundation of high-performing software teams. I've seen first-hand how these wastes can slow down even the most well-intentioned teams. This post isn't a theoretical lecture; it's a practical guide based on experience and evidence. Let's explore how each of these eight wastes shows up in software development, and how to spot them in your team.

1. Transportation

In manufacturing, transportation waste is the unnecessary movement of materials - moving parts without improving them. In software, it's the same pattern made invisible: unnecessary handoffs between people, tools, or environments.

Every transfer adds friction and risk. Knowledge gets diluted, priorities drift, and work waits for permission to move. The cost isn't just time - it's lost clarity, context, and momentum.

Reducing transportation means shortening the path from idea to running code in production and giving teams direct ownership of outcomes.

Practical Reduction Strategies

Form cross-functional, outcome-oriented teams to reduce handoffs.
Provide self-service environments and standardised tooling.
Establish clear communication channels and ownership for tasks and escalations.

Enabling Methodologies & Practices

DevOps and Agile break down silos by forming outcome-oriented teams that deliver value independently.
Team Topologies defines clear interaction modes; collaboration, X-as-a-service, facilitation - making communication intentional rather than chaotic.
Platform Engineering provides self-service infrastructure and environments, eliminating manual requests and delays.

Validated Performance Impact

This waste is a primary driver of long Lead Time for Changes. Research from Accelerate and the DORA program shows that reducing handoffs and enabling end-to-end ownership directly improves performance - shortening lead times and increasing Deployment Frequency.

2. Inventory

In manufacturing, inventory waste means stock that's been built but isn't delivering value. In software, that inventory lives as unfinished code, unmerged branches, bloated backlogs, and half-validated features.

Every line of dormant code represents work that's not improving services. It clogs flow, hides defects, and accumulates merge conflicts, stale dependencies, and forgotten context.

Lean flow depends on fast feedback. When inventory piles up, feedback slows, and value creation stops. The focus must shift from starting work to finishing work, which requires limiting work-in-progress (WIP).

Practical Reduction Strategies

Limit WIP to expose bottlenecks and maintain flow.
Deliver small, independently deployable increments.
Regularly review and prune backlog items that no longer add value.

Enabling Methodologies & Practices

Kanban visualises and limits WIP, exposing flow bottlenecks early.
Continuous Integration keeps the system deployable at all times, while Continuous Delivery automates the path to production.
Trunk-Based Development eliminates long-lived branches and ensures small, frequent merges.
Agile promotes short iterations and small batch sizes to minimise partially done work.

Validated Performance Impact

High inventory (WIP) directly impacts both throughput and stability. It is a major contributor to poor Lead Time for Changes, as work waits in queues. It also increases the Change Failure Rate, as large, complex batches are inherently riskier to merge and deploy. The DORA findings strongly support this: keeping work small (low WIP) leads to faster, safer, and more reliable delivery.

3. Motion

Motion waste is the unnecessary movement of people or tools. In software, it shows up as manual setup steps, repetitive configuration, inconsistent environments, or scattered information.

Every manual click or repeated setup is friction that interrupts focus. Developers spend time wrestling with tools instead of solving problems.

Reducing motion means building a smooth, predictable developer experience - one where environments, builds, and feedback are automatic, consistent, and close at hand.

Practical Reduction Strategies

Automate repetitive tasks like environment setup, builds, and deployments.
Provide standardised, containerised environments for consistency.
Supply curated scripts, templates, and DX tooling to reduce friction.

Enabling Methodologies & Practices

Automation and Infrastructure as Code eliminate manual setup and configuration.
Platform Engineering provides standardised environments that "just work."

Validated Performance Impact

Friction from manual tasks directly harms Lead Time for Changes and often increases the Change Failure Rate due to human error. Data from the DORA studies confirms that automation and standardised development environments are key predictors of elite performance.

4. Waiting

In manufacturing, idle machines burn money. In software, idle people burn opportunity. Waiting waste is the silent cost of slow builds, blocked reviews, overloaded dependencies, or delayed feedback.

Every delay in the feedback loop weakens flow and motivation. Engineers lose context, teams lose pace, and users wait longer for improvements.

Reducing waiting means collapsing those loops - making feedback continuous, not calendar-driven - so progress never depends on someone else's availability.

Practical Reduction Strategies

Automate CI/CD pipelines for fast feedback loops.
Enable async reviews and lightweight approvals to remove blockers.
Decouple teams and reduce inter-team dependencies to avoid idle time.

Enabling Methodologies & Practices

Continuous Integration and Continuous Delivery automate builds, tests, and deployments to reduce idle time.
Agile and Kanban emphasise small batches and fast feedback.
Team Topologies warns against coupling teams so tightly that one's progress blocks another's.
Platform Engineering allows developers to self-serve environments and tools instead of waiting for tickets.

Validated Performance Impact

Waiting is a pure component of Lead Time for Changes. Accelerate research highlights fast feedback loops as one of the strongest predictors of success - teams that shorten the path from commit to deploy (which reduces waiting) consistently outperform those trapped in slow feedback cycles.

5. Overproduction

Overproduction is building more than what's needed - features without validation, designs without user input, or automation without purpose.

It's seductive because it looks like progress. Teams deliver features, fill backlogs, and complete roadmaps - but if it doesn't meet a user need or improve service quality, it's waste disguised as delivery.

Reducing overproduction means focusing relentlessly on outcomes, not output. The measure of success is user value, not feature count.

Practical Reduction Strategies

Prioritise work based on validated user needs and service outcomes.
Deliver small, incremental releases instead of speculative features.
Test assumptions early with MVPs, prototypes or user research.

Enabling Methodologies & Practices

Agile and Lean Startup thinking focus on delivering the smallest valuable increment.
Domain-Driven Design helps teams focus on the core domain - the areas that create real user and service value.
Continuous Delivery encourages small, validated releases rather than speculative ones.
Behaviour-Driven Development ensures teams build exactly what's required, no more.

Validated Performance Impact

Overproduction wastes capacity that could be used to improve Deployment Frequency and, by creating unnecessary code, can increase the Change Failure Rate. The DORA research reinforces that small, validated releases reduce waste and improve stability, allowing teams to achieve both higher throughput and lower Change Failure Rate.

6. Overprocessing

Overprocessing is doing more work than necessary for the same result. In software, it's overengineering, unnecessary abstraction, or process overhead added "just in case."

Complexity accumulates quietly - every extra layer, meeting, or document increases cognitive load and slows adaptation. The result is a system that's heavy where it should be light.

Reducing overprocessing means matching effort to value - choosing simplicity, clarity, and sufficiency over theoretical perfection.

Practical Reduction Strategies

Apply YAGNI: implement features only when needed.
Keep architectures and abstractions simple.
Regularly review code and processes to remove redundant complexity.

Enabling Methodologies & Practices

Clean Code and Refactoring principles fight overprocessing: clarity over cleverness, simplicity over abstraction.
Agile discourages heavyweight ceremonies and unnecessary documentation.
Domain-Driven Design uses Bounded Contexts to contain complexity.
Team Topologies reinforces small, decoupled teams that own coherent parts of the system.

Validated Performance Impact

Overprocessing adds unnecessary complexity, which directly increases Lead Time for Changes and can contribute to a higher Change Failure Rate. Studies in Accelerate show that simplifying architectures and streamlining technical and organisational processes reduce lead times and increase Deployment Frequency - proving that leaner, less bureaucratic systems deliver faster and more reliably.

7. Defects

Defects are the most visible waste - bugs, outages, regressions, or rework. But every defect is a symptom of a deeper process failure - a flaw in testing, a gap in understanding, or a rushed review.

The later an error surfaces, the more expensive it becomes. Each missed test, unchecked assumption, or rushed review compounds until failure becomes inevitable.

Reducing defects means building quality in - making testing, feedback, and improvement continuous parts of delivery rather than after-the-fact correction.

Practical Reduction Strategies

Build quality in with TDD, automated testing, and CI pipelines.
Perform code reviews and static analysis for high-risk areas.
Monitor production with observability tools to detect and prevent regressions.

Enabling Methodologies & Practices

Test-Driven Development builds quality in from the start.
Pair Programming provides continuous, real-time code review.
Behaviour-Driven Development aligns developers, testers, and product on shared expectations.
Continuous Delivery embeds testing throughout the pipeline, catching issues early.
Clean Code practices - readability, modularity, testability - reduce the defect rate over time.
DevOps promotes shared responsibility for quality: "You build it, you run it."

Validated Performance Impact

This waste is a direct measure of the Change Failure Rate and impacts Time to Restore Service. DORA's data shows that teams that build quality in through automation and shared ownership see lower failure rates and faster recovery - proving that speed and quality rise together.

8. Unused Talent

Often considered the most damaging waste of all, particularly in knowledge work: failing to use the creativity and insight of the people closest to the work.

When teams are reduced to task-takers, innovation dies. The best engineers become disengaged, and the organisation loses its capacity to learn, adapt, and improve.

Reducing this waste means treating developers as designers of systems - trusted to experiment, decide, and continuously shape how value flows to users.

Practical Reduction Strategies

Empower teams with autonomy and ownership over outcomes.
Encourage contributions and ideas from all team members.
Allocate time for experimentation, learning, and innovation (spikes, hackdays).

Enabling Methodologies & Practices

Agile empowers teams to self-organise and decide how to achieve outcomes.
Team Topologies encourages autonomy and ownership over clear, bounded scopes.
DevOps culture rewards experimentation and learning from failure.
Domain-Driven Design and Clean Code both assume developers are active designers of systems, not passive implementers.

Validated Performance Impact

The Accelerate research identifies culture as a decisive factor in performance, impacting all four DORA metrics. Teams with autonomy, trust, and psychological safety deliver faster (Lead Time for Changes, Deployment Frequency), fail less (Change Failure Rate), and recover more quickly (Time to Restore Service) - proving that empowering people is the most powerful efficiency gain of all.

Conclusion

The eight wastes aren't just a checklist: they're a mindset. They challenge us to constantly ask: "Is this activity adding value, or just keeping us busy?" Accelerate and DORA have shown that the Lean foundations of flow, feedback, and empowerment remain the strongest predictors of high performance today.

But waste is only the symptom. The real question is: why does waste appear in the first place? The answer is Mura; unevenness in how work moves through the system.

In part 2, we will move from the what to the why, diagnosing the patterns of uneven flow that create waste, and exploring how to measure and eliminate them.

DEV Community: Matt Shaw

Muri: The Root Cause of Overburden

Overload on People

Cognitive Load

A Practical Sociotechnical Approach

Psychological Safety

Overload on Systems

Platform Engineering

Continuous Refactoring

Evolutionary Architecture

The Anti-Patterns

Estimation as Commitment

Productivity Paranoia

Hero Culture

These Ideas Are Not For Sale

Conclusion

The Choice You Can No Longer Ignore

Recommended Reading

Mura: The Source of Uneven Flow

The Detection Kit

Lead Time for Changes

Deployment Frequency

Change Failure Rate

The Solutions

The Management System

The Cultural System

The Technical System

The Ideal

The Anti-Patterns

Misusing Story Points

"Scrum-fall"

"JIRA-First"

SAFe (and the Agile Release Train)

Conclusion

Muda: The Eight Wastes of Modern Software Delivery

1. Transportation

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

2. Inventory

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

3. Motion

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

4. Waiting

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

5. Overproduction

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

6. Overprocessing

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

7. Defects

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

8. Unused Talent

Practical Reduction Strategies

Enabling Methodologies & Practices

Validated Performance Impact

Conclusion