Context

• Why
• Trap
• Framework
• Benefits

The loop

• Outcome
• Constraint
• Intervention
• Readout

Practice

• Avoid
• Patterns
• Scaling
• Start

En Dash Consulting

Minimum Viable Change

A practical framework for transformation that treats change like product discovery—start small, learn fast, and compound results over time.

⚠️

Why Transformations Fail

Multiple consulting firms report similar transformation failure rates, though the exact numbers vary. The consistency of poor outcomes points to systemic problems in how organizations approach change.

70-88% Fail to Meet Goals 48% Miss Outcome Targets 30% Meet Timeline/Budget

The Pattern

These numbers reflect a fundamental mismatch between how transformation programs operate and how organizational change actually happens. Large-scale initiatives create coordination overhead, slow learning cycles, and late discovery of critical constraints.

The result: organizations invest heavily in planning and governance while teams struggle to deliver meaningful change.

Check Understanding

A company launches a comprehensive transformation program covering culture, processes, and technology across all departments. Based on research data, what's the likely outcome?

High probability of success due to comprehensive scope High probability of failure due to coordination complexity and slow learning Neutral outcome—scope doesn't correlate with success rates

What's the primary cause of transformation failure according to the pattern described?

Insufficient budget allocation Lack of executive commitment Slow learning cycles and late constraint discovery 🚧

The Big Program Trap

What Typically Happens

• Commit to a big plan early: Detailed roadmaps and timelines established before reality testing
• Discover reality late: Critical constraints surface months into execution
• Add governance to manage uncertainty: Steering committees, status reports, dependency tracking
• Teams pay the tax: More time in coordination meetings and rework than actual delivery

The Result

More coordination than delivery

Programs become self-perpetuating bureaucracies. Status reporting consumes more effort than the work being reported on.

More reporting than learning

Teams spend energy justifying variance from the plan rather than adapting based on what they learn.

Productivity, culture, and customer satisfaction often decline during transformation programs—the opposite of intended outcomes.

Check Understanding

A transformation program establishes a detailed 18-month roadmap with dependencies mapped across 12 teams. Three months in, teams discover a critical technical constraint. What typically happens?

Teams quickly adapt the plan based on new learning Governance layer added to manage the variance, slowing delivery further Program pauses to replanning from scratch 🔄

Minimum Viable Change Framework

Treat Change Like Product Discovery

Apply product thinking to organizational change: hypothesize, test, learn, repeat. The goal is not to minimize change itself but to minimize the batch size of change experiments.

The Point of "Minimum"

• Reduce risk: Small experiments limit downside exposure
• Reduce coordination cost: Changes contained within teams avoid dependency overhead
• Increase learning speed: Faster feedback loops surface what works and what doesn't

A Useful Litmus Test

If it needs a steering committee to start, it isn't minimum

Changes requiring extensive approval processes and cross-functional alignment before beginning are too large. Make it smaller.

The MVC Loop

One outcome, one bottleneck, one small bet, two-week readout

Desired Outcome Pick one measurable outcome Constraint Find where work waits Smallest Intervention One lever per experiment Quick Readout Decide: adopt, adapt, abandon

Check Understanding

A team wants to improve their deployment process. Which approach best exemplifies Minimum Viable Change?

Implement a complete CI/CD pipeline with automated testing, deployment, and monitoring across all services Add one automated test gate to the deployment of their highest-risk service Create a six-month roadmap for DevOps transformation pending steering committee approval

Why does MVC emphasize reducing coordination cost?

To minimize meetings and save time To increase learning speed by removing dependency overhead To avoid involving leadership in decisions 📈

Why Small Changes Win

Short Feedback Loops

Small changes complete quickly, generating learning within days or weeks instead of months. This enables:

• Less rework: Course-correct before significant effort is invested
• Better alignment: Teams stay synchronized with actual constraints rather than planned assumptions
• Lower risk: Failures are contained and cheap

Constraint Economics

Systems improve by addressing bottlenecks, not by optimizing everything simultaneously.

Fix the bottleneck and throughput rises

Focused improvement on the constraint increases system capacity immediately.

Try to fix everything? Nothing moves

Distributed effort across many improvements dilutes impact and creates coordination overhead.

Compounding

Small friction removed returns time every day. A five-minute improvement to a daily process yields 1,825 minutes per year per team member—over 30 hours of reclaimed capacity.

Multiple small improvements compound. Ten friction-reducing changes create exponentially more value than one large initiative that arrives months later—if it arrives at all.

Check Understanding

A team identifies five process improvements, each saving 3 minutes daily. Should they implement all five simultaneously or sequentially?

All five simultaneously—maximize time savings immediately Sequentially—test each change, learn from results, avoid coordination overhead Neither—3 minutes isn't worth the effort

According to constraint economics, what happens if you optimize non-bottleneck processes?

System throughput increases proportionally System throughput remains unchanged—work still waits at the constraint Non-bottleneck improvements eventually eliminate the constraint 🎯

Step 1: Pick One Outcome That Matters

Use "So That" Framing

Connect the metric to meaningful impact:

• "Reduce lead time so that customer feedback shows up in the same month"
• "Improve reliability so that releases stop being stressful events"

Good Outcomes Share Three Traits

1. Visible within a few weeks at most: Long feedback loops prevent learning
2. Owned by a team: Outcomes spanning multiple teams create coordination overhead
3. Measurable without a data project: If measurement requires new infrastructure, the outcome is too complex

Outcome Menu (Choose One)

• Lead time / cycle time
• Time blocked / waiting
• Release frequency
• Incidents / escaped defects
• Time to restore service
• Percent of work with clear acceptance criteria

Check Understanding

Which outcome best fits MVC criteria?

"Improve customer satisfaction across all product lines over the next year" "Reduce code review wait time from 3 days to 1 day so that features ship faster" "Transform engineering culture to be more agile and innovative"

A team proposes "reduce time to market by 40%" as their outcome. What's the primary issue?

The percentage target is too aggressive Missing the "so that" framing—unclear why this metric matters No issue—this is a well-formed outcome 🔍

Step 2: Find the Constraint Fast

The Question

Where does work wait the longest, most often?

Last-5 Method

1. Take the last 5 finished items
2. For each, mark the longest wait
3. Tally the winner
4. Name it as a hypothesis: "We stall at [review / QA / approval / dependency / intake]"

This takes 15 minutes. Precision isn't required—you're identifying the most obvious bottleneck, not conducting a comprehensive analysis.

Common Bottlenecks

• Approval queue: Work waiting for stakeholder sign-off
• Review pile-up: Code or design reviews queued behind other work
• QA as a phase: Testing treated as a handoff rather than continuous activity
• External dependency drag: Waiting on another team's delivery
• Intake churn: "Not ready" work entering the system anyway
• Environment/build/test delays: Infrastructure friction blocking progress

Check Understanding

Using the Last-5 method, a team finds: 3 items waited longest at code review, 1 at QA, 1 at deployment. What's the constraint?

Code review—it's the most frequent bottleneck All three stages equally—address them simultaneously Unclear—need more data before deciding

A team wants to conduct a thorough two-week analysis mapping all dependencies and wait states across their entire value stream. What's the problem with this approach?

No problem—comprehensive analysis produces better results Violates MVC principles—two weeks of analysis delays learning from actual experiments Two weeks is insufficient—needs at least a month ⚡

Step 3: Choose the Smallest Intervention

Three Levers (Pick One)

Lever A: Reduce WIP

• Add a WIP limit only where the pile-up is worst
• Stop-start rule: finish something before starting the next
• Swarm rule: blocked > 1 day triggers help

Lever B: Simplify a Handoff

• Replace an approval meeting with a checklist + 24-hour SLA
• Pair QA with dev for the top 1 item/day
• Refine entrance/exit criteria to ensure only ready work enters

Lever C: Shorten the Feedback Loop

• Daily 10-minute "blockers + next test" standup
• Weekly demo to real stakeholders (not a status update)
• One "definition of done" gate that prevents rework

MVC Candidate Test (Before Choosing)

Pass/fail checklist—is the change:

• Reversible within 2 weeks?
• Local to one team?
• Low coordination cost?
• No reorg required?
• Visible with chosen metric in the short timeframe?

If it fails: Make it smaller until it passes.

Check Understanding

Code review is the constraint. Which intervention best fits MVC criteria?

Implement automated code analysis, restructure review assignments, and train all engineers on review best practices Require two reviewers instead of three for PRs under 200 lines Hire three additional senior engineers to handle review load

A proposed change requires sign-off from three VPs before starting. What does this signal?

The change is appropriately scoped given its importance The change is too large—fails the "needs a steering committee" test Proceed once approvals are obtained 📊

Step 4: Quick Readout and Decision Discipline

Write the Experiment Card Before Starting

Document these elements before execution:

• Outcome: [metric]
• Constraint: [where work waits]
• Change: [one lever]
• Timebox: 1-2 weeks
• Success threshold: [target]
• Owner: [role]

Decision Options

Adopt

Improvement observed and no new brittleness introduced. Keep the change.

Adapt

Partial improvement; tune one parameter and run another week.

Abandon

No movement on the metric. Stop and pick a different small bet.

Avoid the temptation to continue experiments that aren't working. The value of MVC is fast learning—which requires killing failed experiments quickly.

Check Understanding

After one week, an experiment shows no improvement. The team believes it needs "just a bit more time." What's the correct decision?

Extend to two more weeks—initial timeboxes are guidelines Abandon—no signal of improvement means try a different intervention Adapt—add a second change to accelerate impact

An experiment improves the metric by 15% but introduces new coordination overhead. What decision fits MVC principles?

Adopt—15% improvement justifies the overhead Adapt—keep the improvement, experiment with reducing the overhead Abandon—any new overhead is unacceptable 🚫

Anti-Patterns That Make Small Change Useless

Bundling Changes

Implementing multiple changes simultaneously prevents causal learning. If three things change and the outcome improves, which change drove the result?

Measuring Activity Instead of Outcomes

Tracking "number of standups held" or "training sessions completed" misses the point. MVC focuses on outcome metrics like cycle time, defect rate, or throughput.

Tool-First "Because We Bought It"

Starting with a tool purchase and working backward to justify its use violates MVC principles. Tools should address identified constraints, not create work to justify procurement decisions.

Reorg-First "Because It Feels Decisive"

Reorganizing teams before understanding constraints is expensive theater. Organizational structure should follow workflow understanding, not precede it.

No Threshold, No Stop Rule

Experiments without clear success criteria and stop rules continue indefinitely. Define success thresholds before starting.

Working on Everything Except the Bottleneck

Optimizing non-constraint processes feels productive but delivers no system-level improvement. Work waits at the bottleneck regardless of downstream efficiency.

Check Understanding

A team implements daily standups, new project tracking software, and revised estimation practices simultaneously. After a month, velocity improves. Which anti-pattern did they fall into?

No anti-pattern—they achieved improvement Bundling changes—impossible to know which intervention worked Measuring activity instead of outcomes

Using the Last-5 method, a team identifies code review as the bottleneck. They decide to optimize their CI/CD pipeline instead because it's more technically interesting. What's the problem?

No problem—any improvement helps Working on everything except the bottleneck—CI/CD optimization won't reduce review wait time Tool-first approach 📖

MVC Pattern Library

Flow Patterns

• Make waiting visible: Add a "Blocked" state; review it daily
• Attack the pile-up: WIP limit on the worst queue only
• Improve intake quality: 3-item "ready" checklist
• Bias to finishing: Oldest work first; swarm to close it

Quality and Reliability Patterns

• Stop-the-line: For priority defects
• One service for two weeks: "No merge without tests" for highest-risk service
• Lightweight pre-release checklist: Limit to 5 items
• After an incident: Implement one fix that removes recurring pain (PowerPoints don't count)

These patterns represent proven small changes. Use them as starting points, not prescriptions. Each organization's constraints are specific—adapt patterns to local context.

Check Understanding

A team experiences frequent production incidents. Which MVC pattern best addresses this?

Implement comprehensive monitoring across all services immediately After the next incident, implement one specific fix that prevents recurrence of that failure mode Create a post-incident review process with detailed documentation requirements 🗂️

Then What? How Do We Scale?

Expand Through Connected Workflows

Start with teams that already share work, handoffs, or outcomes. Scaling happens at team boundaries, not through organization-wide rollouts.

Scale by Improving the Seam

Focus on friction at interfaces between teams: unclear intake, competing priorities, ambiguous handoffs, or mismatched definitions of ready and done.

Build Shared Practices With Partner Teams

Co-create the next version with adjacent teams. Adoption feels owned, not imposed.

Use One Cross-Functional Pilot at a Time

Test improvements in real working relationships—product plus engineering, or business team plus shared service—before spreading further.

Standardize Core, Allow Local Variation

Keep essential practices consistent while letting teams adapt details to their context and constraints.

Scale at the Pace of Coordination Capacity

Expand only as fast as teams can absorb new ways of working without adding confusion, overlap, or governance overhead.

Check Understanding

A successful MVC experiment in one team prompts leadership to mandate the same change across all 20 teams immediately. What's the problem?

No problem—proven changes should scale quickly Violates "scale at the pace of coordination capacity"—ignores local context and creates mandate overhead Should pilot with 10 teams first, then expand to all 20

When scaling MVC, where should improvements focus?

Within high-performing teams first At the seams between teams where handoffs create friction At the organizational level to establish standards 🚀

Getting Started: Build Your Experiment

Use this interactive template to design your first Minimum Viable Change experiment. Fill in each field, then generate your experiment card to share with your team.

Experiment Card Builder

Desired Outcome (with "so that" framing) Constraint (where work waits) Change (one lever) Timebox Success Threshold Owner (role) Decision Options Adopt Improvement and no new brittleness Adapt Partial improvement; tune one knob Abandon No movement; stop and pick different bet Generate Experiment Card Reset

Your Experiment Card

Next Steps

1. Share your experiment card with your team
2. Run the experiment for the specified timebox
3. Gather data on your success threshold
4. Make a decision: adopt, adapt, or abandon
5. Repeat with a new constraint

Need Support?

En Dash helps organizations implement Minimum Viable Change practices and build sustainable improvement systems.

Visit En Dash Get in Touch

Minimum Viable Change, a Scroll by En Dash Consulting • 2026 Edition