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.
Top comments (0)