Dysfunction Mapping

---

Origins

Dysfunction Mapping was developed by Michael Lloyd, an Agile coach and Scrum Master, who built the technique over several years of trial and error. The honest origin: in his first couple of years as a coach he wasn't very good at it. He kept solving the wrong problems — chasing whatever was loudest, fixing surface symptoms, jumping from one fire to the next. Eventually he noticed he was repeating the same pattern when coaching actually worked: write everything down, look for themes, look for connections, then find the single most leveraged thing to address.¹

That implicit pattern became a deliberate process. Lloyd published it publicly in 2022, taught it through workshops, and presented it at the Hands-on Agile meetup hosted by Stefan Wolpers.² It is now widely used in the Scrum and coaching communities as an alternative to running on intuition.

What Dysfunction Mapping Solves

Most Agile coaches face the same problem: too many things are wrong, and it's not obvious where to start. The team isn't finishing work, the Product Owner is absent, retros are stale, the daily Scrum runs forty minutes, and someone in leadership is questioning whether agile is working. Without a structured way to think about all of this, the coach picks the loudest issue, applies a generic fix, and moves on. Six months later the same issues are still there.

Dysfunction Mapping replaces that pattern with an empirical, hypothesis-based process. It asks the coach to slow down before acting: observe broadly, separate symptoms from dysfunctions, surface the purpose underneath each practice, and design solutions that connect back to measurable change.

The Five-Column Map

The map flows left to right across five columns, each linked to the next by visible relationships:

• Symptoms — observable negative outcomes the team or organization is experiencing.
• Dysfunctions — the missing or misapplied practices producing those symptoms.
• Purpose — the underlying reason each practice exists.
• Solution Hypothesis — proposed coaching moves to address each dysfunction.
• Measures — how you'll know the solution worked, reframed from the original symptoms.

The map looks like a flow diagram with sticky notes connected across columns. Color-coding by theme is optional and informal — Lloyd notes it doesn't have to mean anything beyond "this stuff is a bit related."

The Five Steps

Step 1: Lay of the Land

Observe the organization without filtering. Attend events — standups, refinements, sprint reviews, retros, leadership syncs. Interview developers, Product Owners, stakeholders. Write down every visible problem: missed sprint goals, interpersonal conflicts, incomplete work, absent POs, overrun ceremonies, broken builds, fights about scope. Do not analyze yet. The goal is breadth, not depth. An exhaustive list is the foundation.

Step 2: Themes & Connections

Consolidate the list. Eliminate duplicates. Then split items into two categories:

• Symptoms — observable negative outcomes ("team isn't finishing started work", "interpersonal conflicts").
• Dysfunctions — missing or misapplied agile practices (no sprint goals, no CI/CD, daily Scrum without purpose).

Draw hypothetical connections between symptoms and dysfunctions. A dysfunction connecting to multiple symptoms is high-leverage — move it to the top.

Step 3: Purpose

For each dysfunction, ask: "what's the purpose of this practice?" Not what the rule says — what real problem the practice was designed to solve. Lloyd's example: "The daily Scrum has a 15-minute timebox because the team should talk throughout the day." The purpose isn't compliance with a rule; it's continuous communication. This reframing shifts the coaching conversation from "the Scrum Guide says so" to "here's the problem we're actually trying to address."

Step 4: Solution Hypothesis

Generate possible coaching moves through three lenses Lloyd recommends:

• Pillars of Empiricism — can you introduce transparency, create inspection opportunities, or adapt existing processes?
• Servant-Leadership Accountabilities — could the team self-manage this? Could the PO or wider organization help?
• Six Scrum Master Stances — remove impediments, facilitate, coach, experiment, mentor, or teach?

Each lens produces different candidate moves. The coach picks the hypothesis that best fits the team's context, not the most agile-pure answer.

Step 5: Measures

Reframe each symptom as a success criterion. "Daily Scrum overruns" becomes "team consistently keeps Daily Scrum to 15 minutes or less." The measure validates whether the solution actually addressed the dysfunction — not whether the team is "doing Scrum right."

The Output: A Coaching Backlog

The completed map becomes a coaching backlog. It's not a finished plan; it's a living artifact the coach revisits as they learn. Lloyd describes it as "a jumping-off point to create a plan for change that's based on what's really happening and what can be observed."

What changes when you have one:

• The coach stops jumping from fire to fire and starts working on the dysfunctions with the highest connection-count first.
• Conversations with leadership shift from "agile isn't working" to "here are the five symptoms we're seeing, here are the dysfunctions producing them, here's what we're trying."
• The team sees that coaching has direction, not whim.
• Success becomes measurable in the team's own terms, not in framework compliance.

When to Use It

• Joining a struggling team or program. When you're new to a context and need a structured way to make sense of it.
• When coaching has stalled. When you've been trying things and nothing is sticking, the map often reveals you've been fixing symptoms instead of dysfunctions.
• Before recommending major changes. Leadership wants to know why you're proposing what you're proposing. The map shows the work.
• When training new coaches. The five-column structure is teachable and produces consistent reasoning.

Common Pitfalls

• Skipping Purpose. Lloyd's most-repeated warning. Coaches rush from "dysfunction" to "solution" and end up enforcing rules instead of solving problems. The Purpose column is what keeps the coaching honest.
• Treating the map as final. The map is a hypothesis. As you act, you learn things that change the map. Update it.
• Skimping on observation. If you start mapping after a single sprint of watching, you'll miss systemic issues that only show up over weeks. The Lay-of-the-Land step is foundational.
• Confusing symptoms with dysfunctions. "The Daily Scrum overruns" is a symptom. The dysfunction might be "team is using the Daily as a status report to the manager." If you treat the symptom as the dysfunction, your solution will be to "timebox harder" — which won't work.
• The Scrum-zealot trap. Lloyd warns explicitly against the "I'll make sure it's less than 15 minutes — why? because the Scrum Guide says so" framing. The map exists to escape that trap, not reinforce it.

How It Relates to Other Techniques

Dysfunction Mapping overlaps with several adjacent practices but is distinct:

• 5 Whys — drills into a single problem. Dysfunction Mapping looks at many simultaneously and surfaces patterns across them.
• Fishbone / Ishikawa diagrams — root-cause for a specific defect. Dysfunction Mapping is broader, organization-level, and prescriptive about solutions.
• Systems thinking / causal loop diagrams — closely related; Dysfunction Mapping is a more concrete, less abstract instantiation.
• Theory of Constraints — identifies the bottleneck. Dysfunction Mapping identifies dysfunctions; the high-connection-count items effectively are the bottlenecks.
• Retrospectives — Dysfunction Mapping is something the coach does, often without the team. It complements team-led retros rather than replacing them.

Coaching Tips

Observe Before You Map

Spend real time in the system before you start writing on the board. Mapping after one sprint produces a shallow map. Mapping after a month produces signal you can actually act on.

Don't Skip Purpose

The Purpose column is what separates good coaching from rule enforcement. Every dysfunction needs a "why this practice exists" before you propose a solution.

Find the Dysfunction Connected to Many Symptoms

The highest-leverage place to start is the dysfunction that produces multiple visible problems. Fixing one of those moves several needles at once.

Treat the Map as a Hypothesis

You will learn things that revise the map. That's the point. A map that stays static for six months has stopped being useful.

Reframe Symptoms as Measures

Whatever the symptom was, turn it into a success criterion in the Measures column. If you can't measure it, you can't tell whether your solution worked.

Use It When You're Stuck

If coaching has stalled and you can't tell why, build a map. The exercise often reveals that you've been fixing symptoms instead of dysfunctions for months.

Summary

Dysfunction Mapping is one of the few coaching techniques that gives Agile coaches a structured, defensible way to decide what to work on. By separating what's visible (symptoms) from what's producing it (dysfunctions), grounding each practice in its actual purpose, generating concrete solution hypotheses, and tying outcomes to measurable change, the technique replaces gut-feel coaching with empirical inquiry. Michael Lloyd's contribution is not a new framework so much as a careful articulation of what good coaches were doing implicitly all along — making the pattern teachable, reusable, and honest about what is and isn't working.

Back to Team Dynamics, Health & Coaching