InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Conflict is Human: Let's Use It Well

Posted by Deborah Preuss on Mar 18, 2010

Sections
Process & Practices
Topics
Agile Techniques ,
Agile

Conflict is actual or perceived opposition of needs, values and interests, which may occur internally (within oneself) or between people or groups of people. We talk about "healthy" and "destructive" conflict, and generally we have worked very hard to eliminate it. There is a whole professional field of study called "conflict resolution - a range of methods for alleviating or eliminating sources of conflict.

Some, however, maintain that conflict "resolution" is illusory: that it is impossible to change others, and that effective conflict resolution is more about self-awareness than about 'strategies' for 'dealing with' others. For those of us coaching "self-organizing" teams: how do we navigate in this territory?

Lyssa Adkins, author of Coaching Agile Teams maintains that not only does "resolving" conflict not work - it can also be counter-productive. "On great agile teams, conflict is constant and welcomed by all as a catapult to higher performance." In her ADP2009 keynote, and in this Better Software article, she presented a model developed by Speed Leas for helping teams learn to de-escalate from destructive conflict into constructive forms of conflict.

Focus on language. What people say and how they say it is the main key for assessing the level of conflict on an agile team. The team will be in conversation frequently, so there will be many chances to focus on language. Pay attention to the words people choose.
At level 1, team members engage in conflict openly and constructively.
At level 2, the conversation changes to make room for self-protection.
At level 3, distorted language such as overgeneralizations, presumptions, magnified positions, and either/or emerges. Real issues get lost.
Level 4 becomes more ideological.
Level 5 is full-on combat.
The goal of navigating conflict is to de-escalate. Knock it down a notch or two. ...Teams - even new ones, even broken ones - can often navigate the conflict by themselves, even conflict in the level 3 range. Even if it's not perfect or the "complete" job you could do for them. ... If you observe long enough (which should feel like a really long time) and decide that your intervention is needed, there are a few response modes you can employ [these are described in the article] ...
Teams that actively navigate conflict and de-escalate regularly can learn to thrive in level 1 conflict... They dance on the edge of discomfort - just enough so that they can come up with the best ideas and build upon one another to find astonishing new possibilities. This is how they use conflict as a catapult to high performance.

Ironically, our Agile community - seemingly bursting at the seams with coaches - suffers no less than others from unhealthy conflict. In Escalation is Killing Agile – Can We Please Stop It? Rally coach and trainer Jean Tabaka made an appeal to the community at large to stop the destructive one-upmanship over Agile methods. Some mistook this for a plea to avoid conflict. Not so, she later replied in Escalation is Killing our Healthy Conflict in Agile:

Some ... [inferred] that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must. In this model, Kaner insists that, to get to high performance, we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.
yes conflict and emotions are good for teams. by Yves Hanoulle Posted
  1. Back to top

    yes conflict and emotions are good for teams.

    by Yves Hanoulle

    I love this article.

    One of the model's I use is the Bruce Tuckman: Forming-Storming-Norming-Perfoming.
    Most (80%)team's (better word in this case would be groups) don't pas the storming phase because they want to avoid conflict.
    My friend Jim McCarthy says they are not avoiding the conflict but are avoiding the resolution. (The conflict is there, it might be hidden now. It will exp(l)ose at some time)

    I know people that were proud they never ever had one discussion in their 10 year old marriage. We are 10 years later. They still did not have one conflict. They are no longer married. (Without any conflict or discussion.)

    A technique I use with teams to take quick decisions (and to see where peopel don't agree with eachother)
    is Decider
    liveingreatness.com/files/core-protocols-3.03.h...

    Planning Poker is also a technique to see conflicting idea's.
    Relative estimation can do the same.
    If people don't speak up enough in relative estimating meetings. I sometimes let them do the estimations in silence. (Moving the cards in silence.) It might look strange but doing things in silence, makes the conflict more clear.

    Yves

Educational Content

Jesper Boeg on Priming Kanban

In this interview, Jesper Boeg, author of the new InfoQ book – Priming Kanban, discusses the keys to using Kanban effectively, and how to get started if you are currently using other approaches.

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.