The Onion method, or how to facilitate conflict solving without tears

October 31, 2014

Read time 4 min

I was recently working as a coach for a client in the financial sector. Their ways of working were very traditional and the IT department was running on fear of failure. As a remedy, they had introduced heavy processes, rigid gates and strict approval procedures.

The proponents of Agile, me included, wanted to relax the rules and have less BDUF (Big Design Up Front). We wanted to follow work on the wall, not in an electronic tool. Backlogs could be in Excel, not in Quality Center. Decisions would be made in workshops and conversations, not in meetings and tools.

On the other side of the argument were Process Owners. They were highly respected individuals who had full authority over their process. Examples of processes were “Testing”, “Architecture” and “Project management”.

When the conflict turned so hot that no-one could ignore it, our Agile Transformation Team called together a pow-wow to discuss about the situation and steps forward. The meeting went extremely well and I want to share with you some tools we used to defuse the bomb.

Start off on the right foot

We started the workshop by asking expectations from everyone. To our surprise, the expectation was not to have own opinion winning but “common understanding about what is mandatory in the process and what is not“. This was a good start; “common understanding” was valuable currency in the discussion. Another important point was that we agreed there can be rules. Agile does not mean throwing everything into the waste basket.

Tool #1: Slicing

One root cause for the conflict was generalisation. When someone said “Testing” then everything about testing became under discussion (tools, methods, practises,documents etc). This made all discussions so huge, that common agreement about “this” over “that” was never possible.

We recognised four components related to any work:
1) Artefact: Document or other output
2) Process: Identifiable steps in the process (for example “Do X before Y” or “Create A during B”)
3) Working practice: How the activity is done (for example meeting or workshop, who need to be invited)
4) Tool: What tools are used and how

This helped to create structure in discussion. Instead saying “Financial Supervision (FiVa) requires that we have specification documents in ShareNet” we can say “FiVa requires that specifications are documented“. This opens completely different discussions.

Tool #2: The Onion

The Onion helps to break the Does/Doesn’t debate into more fruitful conversation. Most conflicts are caused by false dichotomies; arguments about “Always vs. Never” or “Black vs. White“.

The layers of the onion in our case were:
Mandatory: Has to de done every time using the pre-defined way of working
Alternative: Something you have to do, but you have alternative ways of working
Recommended: Not mandatory, but a recommended practise to avoid conflicts
Optional: Something you can do or leave undone and there are recommendations for good practises available

After introducing the two tools, the Process Owner created a list of items in their area: what Artefacts, Tools, Work steps or Practices there are and which level they are in the Onion Model. As you guess, most Mandatory items were Artefacts or Tools. However, there were great insights, for example proposing that a mandatory meeting would be replaced by workshop with less strict agenda.

At the end we had a very good list of well-argumented needs from each participant, for example:
– “Testing can be done using BDD, but in that case the tool should be JBehave” (Optional working practise with Mandatory tool)
– “In order to follow the Architecture Process, team must have discussion with Architecture Steering Group before projects starts. It is recommended to follow Architecture Process also in Agile projects” (Mandatory working practice with Recommended process)

Example of topics discussed with Onion Model

Example of topics discussed with Onion Model

My key takeaways from the workshop and the tools were:
1) People have a desire for common understanding. Having this said in a meeting helps to find a solution.
2) People have desire to hold on to their important things and anchor them into larger entities (“I need to have requirements in written form, therefore I command a tool and process for that”)
3) Creating alternative structure and “baskets” helps people let go things that are not really important (things that are just proxies to get something that is important)
4) False dichotomy is the enemy of conversation. Offering 3 or more alternative levels facilitates agreement.


Sign up for our newsletter

Get the latest from us in tech, business, design – and why not life.