In my experience as an Agile coach, I’ve seen firsthand how organizational dysfunctions and inter-team conflicts can be the “elephant in the room” when it comes to productivity. I’m always looking for new tools to resolve organizational issues, so I jumped at the opportunity to attend a Dysfunction Mapping workshop hosted by Michael Lloyd.
Dysfunction Mapping is a 5-step iterative process for Agile practitioners to identify and solve team and organizational problems, known as dysfunctions for this workshop.
Step 1 is identifying a Symptom – what’s a pain point that people are experiencing? An example might be “Too many meetings”. Step 2 is brainstorming an underlying Dysfunction of the Symptom. For the example of “too many meetings,” the underlying dysfunction might be “unclear decision-making authority leads to meetings being needed to make decisions.” The final 3 steps are to identify the “why” of how a solution might fix the problem, come up with a tactical action to resolve the Dysfunction and measure the solution’s effectiveness.
This workshop is a nice way for Agile Practitioners to show how they’re improving teams, organizations, and removing impediments. Check out the Dysfunction Mapping website for a more thorough overview of the process.
Here are five takeaways I gathered from his workshop:
A good funnel is helpful for getting leftovers into your Tupperware and not all over the counter. It’s also vital for identifying and solving organizational issues.
In Dysfunction Mapping, the funnel is the mechanism for identifying the symptoms the team or organization is facing.
I’ve found that the funnel is natural when you’re first starting with a team or organization. Everyone can’t wait to tell you all the symptoms they’re experiencing.
It’s important to remember that as you stay with a team or organization, you need to build in a continuous funnel of symptoms – how can you continue to identify symptoms that your team or organization is facing? Scrum teams have built this mechanism into their Sprint Retrospective. For organizations, you need to ensure you can get input from a wide range of individuals – whether through a regular survey, coffee chats, or any other mechanic that helps you stay in touch with the organizational pulse.
“A problem well-stated is half-solved” – Charles Kettering
The Dysfunction Mapping analysis starts by identifying symptoms that people are experiencing and performing a root cause analysis to identify the underlying root causes (which are called Dysfunctions in this workshop).
The value of a root cause analysis is hard to overstate – it ensures that you’re solving the actual underlying problem that the team or organization is facing.
This session helped remind me that you shouldn’t immediately neglect the symptoms after performing the root cause analysis. For one, the symptoms are the pain points that members of your organization are feeling, so minimizing or eliminating the symptoms will have the impact that people feel the most. A timely follow-up that shows/proves how the symptoms have been mitigated can be a huge part of your success story.
It’s easy to get wrapped up in the solution and forget to explain the “why.” How often do you hear someone explain the reason as “because the boss said so” or “because [insert framework of choice] said so”?
It’s an excellent reminder to explain the “why.”
Metrics are a great way to prove the impact your change had. However, they’re often neglected for change efforts because it’s hard to measure these kinds of outcomes.
Non-traditional metrics can provide evidence for behavior shifts that are harder to get traditional measures for. An example given was using a checklist. If you’re trying to reduce a behavior that someone on a team does, keep a running checklist before and after you try to impact the behavior. You would likely keep this type of sensitive data private, but it provides good internal feedback that the behavior drove the intended outcomes.
Missing from the Dysfunction Mapping framework is a mechanism to report your successes, which I believe is a mistake. For Agile Coaches, Scrum Masters, or other Agile practitioners, it’s essential to advocate for yourself so that the teams or organizations you impact will know the dysfunctions that are being removed.
While not every improvement needs to be reported, it’s important to ensure your organization is aware of key improvements by communicating the removed Symptoms or the improved Measures.
Whether you run it as a one-day workshop or as a framework for continuous improvement, Dysfunction Mapping is a great tool to add to your toolbox to alleviate organizational dysfunctions. While I’ve used similar ad-hoc processes before, this structured approach can ensure that you’re thoroughly dissecting and resolving dysfunctions for your organization.