Resolve a Conflict in 6 easy and 1 difficult step

Tried Out

CRD # 1 at Scan Agile 2009When presenters propose sessions for XP Days Benelux, we always recommend they try out their session, as many times as possible. We should all know the power of iteration and feedback. You need some time to get it right. If you’re slow like me, you might need years to get it right.

The first tryout of the “Solve Conflicts without Compromise” session was run as a “Birds of a Feather” session several years ago at the SPA conference. The session (and the technique) worked, but only barely. Then, two breakthroughs happened at the same time:

Suddenly, the technique became a lot clearer. Bill Dettmer’s explanation is very clear and practical; the session at Agile 2008 showed that it worked and could be fun.

Solve Conflicts without Compromise

CRD # 2 at Scan Agile 2009So, after a few more iterations, an updated session was created. It’s now been run twice:

  • At  Agile Tour Besançon, in French. The participants gave a lot of useful feedback at the retrospective.
  • At the Scandinavian Agile open space, in English. The pictures show the three groups analysing a conflict for their “customers”. There was no time for a retrospective, because the conference was closing. I hope the three clients will blog or email me about their experience.

The next two runs will be at the Belgium Agile/XP User Group meeting on November 5th 2009 and at the XP Days Benelux conference on November 24th.

So, what are the 7 steps?

  1. Create a blank Conflict Resolution Diagram (CRD) like in the image below. 5 boxes connected with arrows. Easy.
  2. Articulate the conflict. State the problem in one of two forms, both impossible choices between conflicting prerequisites:
    • One chain of reasoning says “DO THIS”; another chain of reasoning says “DON’T DO THIS”. Now I have to choose: DO THIS OR DON’T DO THIS? I can’t have both.
    • I need two things, A and B, but they’re mutually exclusive. Now I have to choose: HAVE A OR HAVE B? I can’t have both.
  3. CRD # 3 at Scan Agile 2009Determine the goal and requirements on each side? Why do we need those two conflicting things? Because of two requirements. Why do we need those two requirements? Because we need them to reach a common goal.
  4. Evaluate the reasoning. Throughout the whole exercise we must ensure we maintain clarity: is each step in the reasoning crystal clear and well-understood by everyone? Is the reasoning clear?
  5. Develop underlying assumptions. If the CRD says “To achieve X we need Y”, ask “Why do we need Y to achieve X?”. All the answers are the underlying assumptions of the reasoning. Use “extreme wording” to make the assumptions stand out and almost beg to be invalidated. For example: “Why do we need to introduce Test Driven Development to achieve better quality?” Because…
    1. TDD is the only way to improve quality
    2. TDD is the most fun way to develop software
    3. TDD catches all errors
  6. Evaluate the assumptions. Which assumptions are valid? Which assumptions are invalid? Which assumptions could be challenged. If there are no valid assumptions behind a step in the reasoning, the reasoning is invalid. At this point, the whole conflict may have “evaporated”.
  7. Hard: Create injections. This is the creative bit where we find ideas to invalidate those assumptions that hold us back from creating a win-win situation, one where we achieve our goal in a way that satisfies everyone involved.

Solve conflicts-lWhy is this difficult?

When I see the participants in action, there are some difficulties that appear every time:

  • It’s hard to maintain the consultant’s stance and only ask questions. That’s why we have strict rules about what the consultants can do: they can only ask a limited set of questions.
  • We want to jump to the solution immediately without taking the time to understand the real problem. That’s why the session doesn’t allow talking about solutions, only about problems.
  • We censor our assumptions. Instead of brainstorming all our assumptions, we only talk about those that seem reasonable. That’s why there’s a lot of pressure in the session: you have to come up with at least 25 assumptions in 5 minutes. That’s just not possible if you think about the assumptions.
  • The most interesting assumptions are those that we no longer think about, the things that are “common sense”. That’s why we have people external to the problem questioning the client and why we bring in some “fresh blood” with a fresh perspective halfway through the session.
  • It hurts when we really think about a problem. It’s easier to just settle for a compromise. That’s why we can’t accept any solution where one of the involved parties is not completely satisfied with the outcome.

What’s in it for me?

  • The CRD provides a structured method to investigate a difficult conflict and channel our creativity.
  • You don’t have to settle for compromise and mediocrity. You can get what you really need.
  • It’s a lot easier to bring about changes if everyone affected benefits. As Machiavelli noted: “You will only get lukewarm support from those who will benefit from the change and strong resistance from those who stand to lose”. What if there were no losers?
  • Your projects can deliver more business value per cost if you can find the breakthrough ideas that make those painful tradeoffs (or more correctly: horse trading) between stakeholder goals unnecessary?
  • You can get more sales if your competitors offer “EITHER/OR” solutions and you can offer “AND” solutions. But first the customer has to regain hope that a solution is possible. Going through a CRD exercise with a customer and offering to invalidate all the assumptions that cause their conflict is an offer they can’t refuse.

The ChoiceWhat do I need?

  • A bit of time. Most participants got several ideas to resolve their conflict within the 90 minutes of the session.
  • Some simple materials: pen, paper and plenty of Post-Its
  • The willingness to think hard
  • The openness to share all assumptions
  • The courage to challenge every assumption, even those that are “holy” or common sense. Especially those.

It’s simple, but not easy. The question is: do you want an easy life or a meaningful life? That’s the choice you have to make.

Oh! “Easy OR meaningful”? That sounds like a conflict! Why can’t I have both?

How would you evaporate this conflict?


Resolve Conflicts without Compromise at XP Days Benelux

I present the “Resolve Conflicts without compromise” with Jef Cumps at the XP Days Benelux conference on November 24th.

Bring a conflict to the session and come out of the session with several ideas to turn this conflict into a win-win situation. If you don’t have any conflicts, you can learn how to help others solve their conflicts as a Systems Thinking consultant.

Solve conflicts without compromise


Toyota Way at XP Days Benelux 2009

Portia and I present the “Toyota Way Management Principles to Sustain Lean and Agile” at the XP Days Benelux 2009 conference.

Come and learn how we’ve applied the Toyota Way management principles to introduce Lean and Agile methods in such a way that the companies can sustain the change.

Flow Haiku


Bottleneck Game at Agile Tour Lille 2009

I present the Bottleneck Game at Agile Tour Lille on October 30th 2009.

Come and play to discover the Theory of Constraints and the “Five Focusing Steps” to really improve processes. Experience how and why Agile, Lean and Real Options work.

The Bottleneck Game


Customer Value Analysis in London 3-4 November 2009

Customer Value AnalysisWhat is Customer Value Analysis?

Customer Value Analysis is the name we came up with to describe the process we use to derive User Stories and Acceptance Criteria from project and company goals. It’s nothing new, it contains a lot of tried and tested Business and Functional Analysis techniques. It’s incremental and iterative, so that it’s a perfect frontend process to “feed” an Agile development team. It’s pull-driven, so you can keep your team fed with high value User Stories, just-in-time, when they need it and in the form they need it.

We’ve seen many projects where the Onsite Customer or Product Owner became the bottleneck, as the development team’s velocity improved. Customer Value Analysis contains the process and techniques we’ve used to exploit and elevate the analysis bottleneck and subordinate it to development again. Now the development team can continue to improve, because the Customer can keep up.

The companies where we’ve applied Customer Value Analysis are always suprised by how much value their teams can deliver. How do they do it? They

  • Identify the high value needs
  • Derive the leanest possible implementation that satisfies the needs, by taking small steps and really understanding the situation
  • Challenge constraints and assumptions to find breakthrough solutions
  • Describe the solutions with User Stories and Acceptance Criteria
  • Do this efficiently, reliably and repeatably

Come and play with us!

Portia and I deliver a series of Customer Value Analysis training sessions, organised by emergn in London. You can expect a hands-on, fun-filled and very intensive session where you can learn and experiment with all the techniques on a real project.

The next training course is on the 3rd and 4th November 2009 in London. See you there!

If you’re interested in a session in Belgium or your country or company, let me know.