Dysfunction Mapping; A tool for effective Agile Coaching
Scrum Mastery and Agile coaching can sometimes feel like an incredibly opaque trade. Everyone loves to talk about mindset and servant leadership, but very few people talk about what they actually do all day.
I’ve spent thousands of hours coaching teams and organizations in effective Scrum and Agile practice, and over the years, many of my approaches have become somewhat repeatable.
Many of the tools I use today are things I created myself in order to make finding and solving problems easier.
I wish I could share these approaches with my past self, but the next best thing is sharing them with you.
My hope is that I can provide an easy to use tool that you can take into your teams and organizations that allows you to form concrete plans for change. Not buzzwords and hand-waving, but real, actionable insights based on the challenges you see.
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. Read on to find out more.
Step 1: Lay of the land
The first thing I always do when I start with a new team or organization is to start observing and asking questions. Talk to the developers, the product owner, the stakeholders. Observe Events and how the work gets done.
Chances are, you’re immediately going to see stuff that doesn’t look right. Events overrunning time boxes, team conflict, missed goals, incomplete increments.
So naturally, we’ll form a list. Write down everything you see and hear.
Pretty soon, you’ll have a massive list of potential problems. These could be anything from ‘The team isn’t achieving sprint goals’ or ‘the team doesn’t have sprint goals’ through to ‘The product owner isn’t around’ and ‘I’ve never seen a customer’.
At this point, there’s no limit, just capture everything you see.
There’s also a good chance you’re still pretty early on in your Scrum journey, so perhaps you don’t even know what to look for. I’d suggest listening carefully to what people are saying, and write down anything that seems like it’s making life difficult.
It’s probably also a great idea to think back to some industry ‘good practice’. The Scrum Guide. XP and DevOps practices. Lean budgets and decentralized decision-making. Are there places where these things are being misunderstood, misapplied or are entirely missing?
Spend a few days at least gathering these insights until you have a nice big list and can move on to;
Step 2: Themes and connections
Now you have a massive list of potential issues. It might look something like this:
There’s a good chance there will be a lot more items than this, and that’s fine too. That’s why step two is about finding themes and simplifying.
Look for things that are potentially related and combine them or put them next to each other. Try to avoid duplicates by creating a single item that captures the idea behind many stickies.
Once you’ve made it a bit more manageable we can start separating our stickies into our first two columns.
Symptoms and Dysfunctions
Symptoms are the specific negative outcomes you can see. These might range from ‘Not finishing work that’s started’ to ‘Dave and Andrea hate each other’
Dysfunctions are the missing pieces of good Scrum/Agile practice. Maybe we’re not forming Sprint goals, or we have no CI/CD practices.
Sometimes you might not be sure which column a sticky should go in to. This might be an indicator that there are actually two things, in which case we might want to split it, identifying what we think the dysfunction might be that explains a symptom.
Either way, you should be looking for relationships between these two columns. Which symptoms might relate to which dysfunctions?
For example, the team not finishing work during the sprint (symptom) might be related to the Product Owner not being present in sprint planning (Dysfunction). The Scrum guide tells us the PO is an important team member for sprint planning, and the team might be telling us that they often can’t finish work because they’re unsure what is required by the customer. Perhaps they’re getting bogged down trying to figure out how to solve the problem during a sprint.
There are no right answers here though. There are no ‘correct’ relationships, this is about using your knowledge of Scrum and Agile, as well as your coaching insights gained from talking to the team and stakeholders. We’re not looking to ‘answer’ anything, we’re just forming a hypothesis.
“I believe this might be linked to this” is all we need for now.
As you’re linking these symptoms and dysfunctions, it’s probably also worth thinking about priority. You might Find that one dysfunction is linked to multiple symptoms, in which case you would want to move it up the list. You might have consolidated many symptoms that were raised by stakeholders into a single ticket, in which case you might also want to raise it up the list.
The general idea is to make sure that the top of the list has the most symptom-dense tickets as this gives you a starting point for which to tackle first.
Once you've moved things around and starting linking things, you might end up with something that looks like this:
Now that we’ve got our list of dysfunctions and symptoms, it’s time for..
Step 3: Purpose
Our dysfunctions that we’ve categorized relate to specific ‘missing pieces’. These might be missing or misapplied elements of Scrum, of XP, of DevOps.
So the best way to start creating a plan for change is to think about the purpose of those missing pieces.
This gives us a chance to reflect on why those practices are beneficial so we can later come up with our actions. Instead of just jumping to problem solving, we can distill the problem down to it’s essence.
And example could be;
Dysfunction: Daily Scrum takes 30 minutes
Purpose: The daily Scrum has a 15 minute timebox because the ‘team should talk throughout the day’. Spending more than 15 minutes is a sign we’re not collaborating throughout the sprint.
The bold section might be all you leave behind on the sticky note once you’ve thought about the purpose, and acts as a placeholder for later steps.
This is a powerful activity for a few reasons. Firstly, it makes us really stop and think about why these practices exist. Often as agile practitioners we get caught up in the rules without reflecting on the why, and this forces us to consider that.
Secondly, because this will often change the way we approach solving the problem.
I know early in my career I was a Scrum zealot. ‘The timebox is 15 minutes so I'll make sure it’s less than 15 minutes. Why? because the Scrum Guide says so!’
But this is a terrible reason to do anything!
So by realizing why the timebox exists, the solution I create in the next step might not be about just ‘sticking to the timebox’, but rather increasing collaboration.
As you’ll see in the next steps, this is incredibly important as it allows us to use the timebox problem as a measure so we know if our actions are successful, but allows us to solve a real problem that has a real benefit for the team.
Instead of thinking of ourselves as Scrum Police, we can start thinking about how Scrum can be a tool to make the lives of developers easier.
As you can probably imagine, we are aiming to come up with a ‘purpose’ for every one of our identified dysfunctions. Sometimes, One purpose might relate to more than one Dysfunction, that’s okay, as long as we have a connection for almost everything.
The end result might look like this:
It should be pointed out that this might seem like the most obvious step to skip. Maybe you’ve been doing this a while and you want to jump straight to a solution, but remember how much time we spend teaching agile and Scrum teams about the importance of purpose, and not solutioning before you understand the problem?
Yeah, that means us, too.
Right, now we can move on.
Step 4: Solution Hypothesis
Okay, so we have a big list of dysfunctions. These are our missing pieces of good agile practice that we’ve tied to our explicit negative outcomes we can observe (or that our teams are telling us about)
It’s time to come up with a solution, but it’s very important to remember why we set out on this whole journey to begin with. So we have an empirical, hypothesis-based way to try to solve problems.
It’s incredibly important to remember that we don’t need to know the ‘right’ solution, our goal is to look holistically at the dysfunctions, the symptoms, and the purpose, and devise a potential solution that we believe could conceivably address our symptomatic issues.
This will require a large dose of common sense, of your own agile knowledge, and of course, a willingness to try and fail.
That said, there are a few key lenses I always bring to each of my ‘purpose’ statements that help me define a solution;
The pillars of empiricism
Transparency. Inspection. Adaptation.
There’s a reason these three pillars are at the heart of Scrum, as well as most scientific and philosophical enquiry.
When looking at a ‘purpose’ statement (tied to our dysfunctions) ask yourself the question; Is there a way I can make this problem transparent so the rest of the team or organization can see it?
Is there a way to introduce an inspection opportunity so we can regularly look at the issue?
Can we adapt an existing process, event or accountability in the team or organization to solve the problem?
The servant-leadership accountabilities of a Scrum Master
The Scrum Master is a true leader who serves. They serve the team, the Product Owner and the organization. These words are an important grounding when defining a solution.
Is there a way the team could self-manage a solution?
Could the Product Owner, being accountable for value delivered, have a stake in solving the problem?
Does the whole-organization potentially benefit (or be harmed by a lack of) the solution?
The 6 stances of a Scrum Master
When it comes to defining a solution, thinking about the very important stances of a Scrum Master (which apply equally to Agile Coaches) can be helpful.
Is there an impediment that could be removed to solve the problem?
Could I facilitate a session or workshop?
Could I coach the team in a new practice?
Could I bring an experiment to the next retro?
Could I mentor someone in the team to solve the problem?
Could I teach a team or group a new approach or framework?
Ultimately, there are no right or wrong answers to any of this. Once again, this is about thinking through the problem and forming a hypothesis using some combination of the questions above, or perhaps something entirely different.
The goal is to come up with one or two potential solutions for each of our purpose statements until our dysfunction map is starting to look somewhat whole, perhaps like this:
Now if you remember our dysfunction map from the beginning, you may know what our last step is. Measure.
Since we’re forming hypotheses, we don’t actually know if they’re going to solve a problem. We don’t want to just assume we’re going to do the right thing, so we need some way to measure that we’re having the required impact.
This is actually the easiest bit, as all we need to do is look at our symptoms from earlier in the chain. We should expect that, if we’re right, implementation of our solution will lessen or remove one or more symptom. We just want to reframe this to make it clear.
So ‘Daily Scrum overruns every day’, which was linked to our ‘Daily Scrum is a status update’ dysfunction gives us a nice easy measure; The team Consistently keeps the Daily Scrum to 15 minutes or less.
Now, whatever solution we’ve decided upon, which could be a Scrum Training workshop, or mentoring someone in the team, or dealing with a manager who attends the Scrum with questions, simply needs to be assesed relative to solving that problem. We can try it, and see if our measure is affected. If it is, awesome! If not, we can revisit and come up with another solution.
The last thing we probably want to do then is come up with some related measure for all our solutions, and do some final organization, like below:
I’ve colored sections just to separate some general themes, but this doesn’t mean anything beyond ‘this stuff is a bit related’. We have a couple of measures linked to a couple of solutions, and these form some general coaching themes.
If you’re anything like me, these become ideal candidates to then form a backlog.
So the green section up top becomes a Coaching Backlog item I might call ‘Product planning’
I’ll be aiming to mentor the PO and collaborate on creating a Product Backlog, and coaching the team in Sprint Goal definition.
My aim is to solve the problems of plans that constantly change in sprint, leading to unfinished work, and unfinished work being shown in sprint review.
And I’ll know this has been successful when a product backlog exists, is discussed regularly with stakeholders, and when the team regularly sets and achieves sprint goals.
And there you have it!
The idea now is simply to take this content and turn it into your high level coaching plan, with a priority and outcomes that give you a concrete plan of action.
You can then share that backlog with your team, your stakeholders or anyone else that might have insights for you, and continue adjusting it as you learn and experiment.
It’s important to repeat one last time that this approach is simply about giving you a jumping off point to create a plan for change that’s based on what’s really happening and what can be observed. This makes it empirical, and prevents you jumping from one fire to the next with no rhyme or reason, which is the pressure we are often under.
Do not treat this as a silver bullet or some fixed plan once it’s created, this is a simply an ideation tool to prevent analysis-paralysis, and to put boundaries around the steps you might take.
I hope this provides some help, and keep your eye’s peeled for some even further deep dives via a book, an online course, and a workshop, all of which I hope to deliver soon. Reach out if this seems valuable to you.
