Making Sense of Wicked Problems with Issue Mapping and Scrum

Recently, I had the good fortune to be able to attend a class a long-time acquaintance, Paul Culmsee, was offering on Issue Mapping. This was one of those once-in-a-blue-moon events because Paul lives and works on the other side of the planet (he's from Perth, Australia) and he was making a special trip out to deliver the course on the invitation of a local software consulting firm here in Toronto, Navantis, Inc.  I've known Paul for several years  and have followed his uncommon-sense blog, Cleverworkarounds.com, for some time, and I participated as a reviewer for the book he co-authored with Kailash Awati and had published last year, The Heretic's Guide to Best Practices.  It was in this book that he laid out how he uses Issue Mapping to help organizations disentangle their problems.

So, you could say I was a motivated attendee; but I digress: This was an excellent class.

Issue Mapping is a technique for facilitating productive meetings that deal with wicked problems, ie. those that are difficult to clearly identify and resolve because they often have incomplete specifications, contradictory elements and fluid properties that are difficult to discern or categorize and inherent, complex  interdependent parts.  Agile software delivery advocates have long-known about the wicked problems involved in software development (I previously wrote about them here) - frameworks like Scrum, XP and Kanban are all aimed at conquering and dividing the chaotic forces that wicked problems unleash on teams charged with delivering value.  Naturally, I found the topic of techniques for disentangling complexity in groups extremely interesting.

Issue Mapping Explained

Issue Mapping was first devised by Jeff Conklin who leveraged the research of Horst Rittel and Melvin Webber to help groups "unpack" their wicked problems (see his book Dialogue Mapping: Building Shared Understanding of Wicked Problems).  It is comprised of three simple elements:
 

1. A Shared Display such as a laptop connected to a projector, or the good old whiteboard or flipchart;
    
2. A Notation with simple rules for how content is captured into the Shared Display;
    
3. A Facilitator who is skilled in capturing group interactions into the Shared Display using the Notation schema.

(**Note:  I will be using the terms Issue Mapping and Dialog Mapping interchangeably

Issue Mapping notation is based on Horst Rittel's IBIS or Issue Based Information System argumentation scheme which was first developed in the 1960s and 1970s to support the coordination and planning of political decision processes.  The basic premise of IBIS is that irrespective of how complex or wicked a problem is, it can be distilled into four basic elements or nodes:  Question, Idea (or Answer), Pro arguments and Con arguments.  These nodes are assembled according to a basic grammatical structure that builds the "map" of the issues under discussion by a group:

Like a standard English sentence, the  map is read from left to right beginning with a root question that opens the exploration.  Ideas are then presented in response to the question with supporting Pro or dissenting Con arguments, which can give rise to succeeding Questions and Ideas.  Relationships between the nodes are shown with arrowed lines pointing to the left to show the path back to the root question.  While the map can be freehand drawn on a whiteboard, the standard is to have the facilitator use a lightweight tool such as the freely-available Compendium, which I used to make the above map. Once you get the knack, it becomes quite fluid to create the maps as the conversations flows.

Making Argumentation Visible, Creating Shared Understanding

Issue Mapped meetings differ significantly from their stodgy counterparts by being significantly more interactive.  Instead of a PowerPoint death march where attendees are talked at or through, they are now engaged as "designers and contributors" to the meeting's content and resolution by the facilitator who helps them see the logic of their problems in real-time, causing a natural shift of their attention toward the screen as the problems are unravelled.  This has a powerful grounding effect that helps to minimize the impact of distracting influences (what Jeff Conklin refers to as "fragmentation") that would otherwise prevent reaching a shared understanding of the issues.

How Can Issue Mapping Benefit Agile Projects?

I see Issue Mapping as a natural fit for Scrum teams and projects and especially for Scrum Masters and Coach/Facilitators:

• Project Chartering and Vision:  Perhaps the most thorny of wicked problems - "What should we build? Can we build it in time?  In-house or contractors?  A mix?  Should we do this at all?"  Issue Mapping can help facilitate this decision-making process toward a useful conclusion.
  
  

• Setting Sprint Goals:  Similar to visioning, but with a reduced scope - Issue Mapping can provide a fantastic means for capturing why certain decisions were taken to set a Sprint Goal and to help align the team and Product Owner.
  
  

• Kickstarting a Product Backlog: Often, Scrum is brought in to help remedy a project that is in dire straits, such as the one Jeff Sutherland describes in his short business fable, The Power of Scrum.  In these situations, there isn't usually enough time to do a proper build-out of the Product Backlog as would happen in a greenfield project - you just need to determine what you can accomplish in the next two weeks to show progress.  Issue Mapping can help bring everyone into alignment on the objectives they want to set for the first iteration.
  
  
• Creating a Definition of Done:  The #1 gotcha that trips up most new and even experienced agile teams - "How will we know when we've completed a feature?"
  
  

• Facilitating Sprint Reviews:  Capturing the feedback that stakeholders generate while inspecting a Sprint's product increment can sometimes be chaotic.  Issue Maps could be used to give some coherence to the commentary and help to inform the next Sprint Planning session.
  
  

• Facilitating Sprint Retrospectives:  This was my first immediate thought for using Issue Mapping within a Scrum project because it has to do with aligning a team's expectations of itself with a future state they want to achieve. Continuous improvement is sometimes a difficult nut to crack for new teams - a brief session with maps could help illustrate what problems the team believes they need to work on next.
  
  

• Intra-Team Conflict Management: Working on a Scrum Team can be stressful:  Take a group of intelligent, creative people, throw them into a pressure cooker where they need to strive together to deliver value and ROI every two weeks and you are bound to have blow-outs.  Since Issue Maps are inherently neutral, they can help explore why problems occur and what can be done to resolve them. By holding a mirror up to reflect them back to the team, they can use the session to take the pressure out of the situation and come up with a respectful path forward.

Do I Need a Facilitator?

Absolutely.  Just as you need a Scrum Master to ensure the rules are followed and the team and Product Owner are working as productively as possible, Issue Mapping is dependent upon a skilled and impartial practitioner. Because wicked problem solving can involve some heated and impassioned debate, it's necessary to have a facilitator who doesn't have a "horse in the race" so as to avoid situations where they may be accused of bias.  While the rules of Issue Mapping and IBIS should take the starch out of these scenarios most of the time, I think it best to have someone who is naïve to the topic so that they can reflect-back statements and arguments to encourage clarity for everyone at the table and not just the acronym and abstract concept junkies.

How Do I Get Started?

I recommend picking up two books:  Dialogue Mapping by Jeff Conklin and The Heretic's Guide to Best Practices by Paul Culmsee and Kailash Awati.  The first gives you the basics of using IBIS for mapping wicked problems while the latter is a "sequel" that expands on how to use Issue Mapping in contemporary settings.  There's more to this than just tossing up some nodes on a screen - there is value to understanding the types of questions that arise in mapping problem wickedness and strategies for gaining insights and clarity.  And of course, you can also take an Issue Mapping course from Paul or one of his authorized designates at Seven Sigma, LLC!

Getting familiar with the IBIS notation and using a tool like Compendium to capture notes for Scrum meetings is a good way to begin before trying it out with your team.  I'd start with simple dialogues such as roughing in your Definition of Done or your next Sprint Retrospective to get the feel of capturing dialogue in real-time with a forgiving audience.  Don't make a big announcement that you're going to do Issue Mapping - just let it happen and answer the questions that naturally arise and follow where the conversation leads.