A Gentle Introduction to Dysfunction Mapping

Make Problems And Hidden Patterns in Your Organization Visible

All organizations have problems. Every company I ever worked for as an employee had problems. Obviously, some companies had more problems than others, but nothing was ever as perfect as it seemed on the outside.

After talking to many employees all over the world, it’s the same at prestigious companies like Apple, Amazon, Google, and Microsoft. Those companies all have their unique issues. Don’t be fooled by the pretty picture presented on the outside or all the brilliant people that work there. Everywhere there are problems.

The problem isn’t that these organizations don’t know their problems. I am confident they are aware of the majority of their problems.

The problem is that these organizations find it difficult to look at their problem from a system’s perspective. The problem is that big companies have big politics and that companies are complex systems that seem to resist change. Especially as companies grow, the organizational inertia grows and their behavior becomes more difficult to predict.

In the words of John Gall:

“The system is its own best explanation - it is a law unto itself. They develop internal goals the instant they come into being and these goals come first. Systems don't work for you or me. They work for their own goals and behaves as if it has a will to live." - John Gall

Now the question becomes: how do you discover the internal goals and problems of your system? How can you make a map of the different problems that exist in your organization to discover what you can do to resolve them?

Enter the world of Dysfunction Mapping.

The History of Dysfunction Mapping

Michael Lloyd created Dysfunction Mapping more than three years ago because he observed he kept bumping into the same walls. Whenever he joined a new team, he would see problems and immediately jump into fixing them without the desired results.

In his own words:

“I made a lot of repeat mistakes from trying to solve the wrong problems, not seeing the big picture, or understanding the systems. After a while, I unlearned to immediately jump into action after noticing problems.

I would spend a week or two looking for patterns and would only jump into action if I had a more systematic understanding of what was happening. Dysfunction Mapping started as my own internal process I used on my iPad to make connections between what I was observing.” - Michael Lloyd, Creator of Dysfunction Mapping

Dysfunction Mapping started as a personal tool that Michael Lloyd developed to serve his teams better and fix the organizational problems he discovered. Over the years as the process became more polished and he gained more confidence in how well it worked, Michael decided to teach others how to do Dysfunction Mapping to make their life as an Agile Coach or Scrum Master easier.

What’s Dysfunction Mapping?

Dysfunction Mapping was invented as a tool to help Agile Coaches and Scrum Masters by helping them explore the problems of the system and how they are related to the realm of Agile and Scrum.

As Michael Lloyd explains Dysfunction Mapping:

“Dysfunction Mapping is a tool to visualize the anti-patterns in your organization, form a hypothesis, and create a plan for change anchored to a specific, visible change or measure.” - Michael Lloyd, Creator of Dysfunction Mapping

In other words, a Dysfunction Map ultimately produces a hypothesis-driven coaching plan for all the problems that exist in your system viewed through the Agile lens. The Dysfunction map connects your lagging problems to leading dysfunctions, together with potential solutions to improve your situation.

That probably still sounds pretty abstract. Let’s show you what a Dysfunction Map produced by a Scrum Master or Agile Coach could look like.

Dysfunction Mapping: Concrete Example

Imagine you join a new Scrum Team, and you notice they consistently struggle to finish the work they’ve added to their Sprint. Every Sprint, they pull in too much work and consistently fail to complete everything they pull in.

In Dysfunction mapping that’s what you’d call the Symptom. A symptom is a negative outcome we observe.

Now that we’ve identified a negative outcome we want to influence, we can try to think about missing Agile or Scrum practices that play a role in our symptom of interest. Those missing Agile or Scrum practices that influence negative outcomes are called Dysfunctions.

Let’s say we identify the absence of a Sprint Goal as one of the main dysfunctions. Then, instead of turning into the Agile or Scrum police, we talk about the Purpose of the Sprint Goal. The main reason is that the goal is never to introduce a practice, but to reduce or get rid of the symptom. Maybe there’s a better way than the Dysfunction we’ve listed.

Some of the purposes of the Sprint Goal are:

• Provide flexibility on the scope of the Sprint. The team doesn’t commit to completing everything they’ve added in the Sprint but to meeting a singular Sprint Goal.

• A singular goal, instead of having all team members working on totally different things, improves teamwork and flow.

• By having a singular Sprint Goal that doesn’t use the full capacity of the Scrum Team, there is room to deal with surprises and the unexpected, such as our estimates being off, and it also helps limit WIP.

Then we can talk about solutions. In our case, we decide to introduce Sprint Goals to our team. The beauty of the Dysfunction Map lies in the fact that:

1. It proves the opportunity to come up with alternate solutions than simply adding the listed dysfunctions.

2. When you do introduce solutions, you can evaluate whether the symptoms you were trying to address were alleviated (and also whether it introduced novel symptoms).

Here’s what our finalized Dysfunction Map looks like:

The Dysfunction Map displays the lagging symptoms together with a map of leading dysfunctions and potential solutions that you may use to influence your situation.

For simplicity's sake, I’ve used a slice of a Dysfunction Map to help you understand the purpose of a Dysfunction Map. This isn’t what a real Dysfunction Map looks like, as it’s supposed to cover many symptoms. Dysfunction Maps don’t limit themselves to one Symptom or one Dysfunction. I just did that not to overwhelm you and aid with understanding.

If you want to run a real Dysfunction Mapping Workshop, where you want to discover all the Symptoms and Dysfunctions, you could do the following:

1. Get the team to list all the problems they are experiencing.

2. Categorize the problems as Symptoms or Dysfunctions.

3. Make connections between the Symptoms and Dysfunctions.

4. Talk about the Purpose of the Dysfunctions, and connect the Purpose back to those Dysfunctions

5. Brainstorm different solutions for resolving those Dysfunctions. The solution does not have to be introducing the exact missing practice that was listed. Maybe you can come up with something better.

Boom! Now you have a list of potential solutions that may influence the negative outcomes you care about. Because the Dysfunction Map is an artifact that is produced, you can do another Dysfunction Mapping exercise to see how your situation has changed and to evaluate whether the Solution produced the desired results.

Dysfunction Mapping: Discover the Whole Story, Elevate Your Scrum Team

Dysfunction Mapping is an extremely powerful tool that allows you to discover the whole story of what is going on with your team, together with generating a list of potential solutions so you can improve your situation.

One of the strengths of Dysfunction Mapping is the fact that you don’t talk about certain practices or rules you have to follow but the purpose behind those practices and rules. This shifts the conversation from ‘Let’s introduce a Daily Scrum that’s limited to 15 mins’ towards other potential solutions for achieving the same goal. In the Agile and Scrum community, there is way too much focus on following the rules over doing what’s best in your situation.

When you’ve produced a Dysfunction Map and you’re busy rolling out different solutions, you can use the same map to evaluate whether the symptoms you’re trying to address have improved. It’s not just a tool for generating potential solutions but also whether those solutions have produced the desired results.

One of the biggest problems with dysfunctions is that we often try to solve them with the same dysfunctional thinking that created those dysfunctions in the first place. In Dysfunction Mapping the symptoms, dysfunctions and purpose are split out. This way, it potentially could be easy to introduce outside help or employees with a different mindset to look at the whole picture and come up with better solutions that lie outside of the dysfunctional mindset.

What’s important to stress: don’t have to limit Dysfunction Mapping to the realm of Agile or Scrum. It’s possible to do Agnostic Dysfunction Mapping, where you don’t view the organization through the lens of Agile or any particular framework (at least not consciously).

I believe the real power of Dysfunction Mapping will shine through when you perform the exercise on the organizational level. Problems don’t artificially limit themselves to the realm of Agile or Scrum, and they’re not limited to the team level either.

If you want the full picture, the best way to go is to do a Dysfunction Mapping workshop on the organizational level. After all, we want to know the whole story, not just the story we can discover on the team level. And that’s what my next Dysfunction Mapping article will be about: how to do Dysfunction Mapping on the Organizational Level.

Thanks to Michael Lloyd for reviewing this article to make sure it’s accurate. Follow him on LinkedIn if you want to attend one of his Dysfunction Mapping workshops.

Further Reading

Dysfunction Mapping Explained by Michael Lloyd