The Dragonflame

Thoughts, stories and ideas.

12

Apr2016

Scrum and conflict transformation

Conflict, by definition, is something omnipresent in our lives. Be it internal (between personal goals, for example) or external (with other people), conflict seems at time to be a continuous state of various degrees.

In Scrum, conflict has multiple dimensions that depend on the degree to which the scrum methodology has been implemented.

During Agile transformation, the most pregnant conflict is the one between Agile adopters and company policies and culture. There may be also conflicts between coaches and future scrum team members, as well as between team members themselves.

While 'doing Scrum', there are the natural conflicts between the Scrum team and outside influence, customers as well as between Scrum team components (product owner, scrum master, development team) and finally the daily conflicts between team members.

Any workflow implies other types of conflicts: between priorities, between tasks and ... wait for it ... even git conflicts!

Conflict transformation is a process through which a given conflict is transformed into a peaceful and sustainable outcome. Though the philosophy itself was designed to apply on a bigger scale while specifically targeting violent conflicts, it's the daily small conflicts that make the most of this method.

Johan Galtung prescribes a series of steps that begins with conflict mapping (stakeholders, their goals, issues and manifestations of the conflict), going through dialog and ending with reaching a new set of common goals. While his design envisions multiple conflict transformation specialists working in parallel with different stakeholders, there are many other points which are extremely valuable to a Scrum Master of Scrum Coach.

The fist, which is also the most basic method of transformation, is adopting a different formulation of the conflict itself. This can mean either simply adopting a new perspective, redefining how the conflict manifests itself or redefining a simple goal. The adoption of a different perspective is best illustrated by the silly example of a git (source control) conflict: once you change the perspective by putting it through a diff visualisation tool, it becomes clear how each part that caused the conflict fits and how should the final goal be formulated so that all the parts fit while keeping the software in working condition.

In other types of conflicts, this kind of transformation can be achieved by a reformulation of the manifestation. There aren't two people with big egos, there are two passionate developer arguing loudly driven by the same goal: to make the software better. The delivery manager trying to micromanage the team doesn't have a compulsive syndrome but is driven by specific needs that may be met in different ways.

In more complex cases, the classic doctrine comes to the rescue:

Mapping the conflict formation: all parties, all goals, and all issues;
Bringing in forgotten parties with important stakes in the conflict;
Having highly empathic dialogues with all parties singly;
Each conflict worker may specialise on one conflict party;
In these dialogues identifying acceptable goals in all parties;
Bringing in forgotten goals that may open new perspectives;
Arriving at overarching goals acceptable to all parties;
Arriving at short, evocative, goal-formulations;

However, in the case of Scrum, the only conflict worker present is the Scrum Master. It's his responsibility to relate to all stakeholders while protecting the separation of responsibilities inside the Scrum Team. The transformation of conflicts rather than defusing them momentarily is essential in an Agile environment since the disruption caused can severely impair the ability to accurately forecast team work as well as the evolution of the product.

As an empirical process, Scrum needs to be surrounded by a stable environment which empowers the team to do their work. Conflict transformation is a technique that can ensure such an environment is a sustainable state.

For this purpose, I believe it is extremely useful (if not essential) for a Scrum Master to cultivate the ability of drawing out holistic, overarching goals that cater to all stakeholders' needs rather than focusing on plain negotiation techniques alone.