You Need More Conflict, Not Less

By Agile Conversations authors Douglas Squirrel and Jeffrey Fredrick.

When teams first adopt Agile, Lean, or DevOps practices, they often think that they’ll have less conflict with the new methodology. “We’ll stop fighting over deadlines because we’ll estimate the work first,” they say, or “Work in Progress limits will mean we don’t get overloaded.”

Surprise! The estimates and limits and tests usually lead to more clashes, not fewer—and this is a good thing, because the conflicts give us the chance to learn from each other. Here’s an example of how to take conflict and turn it into a learning opportunity.

Take Raj and Odette, a system administrator and a developer respectively. Now that they use DevOps methods, working together to build and deploy their software, they think they’ll have fewer battles over deployment scheduling and system maintenance. But in fact they had a huge blowup over a recent production failure. Raj wrote a “conversational analysis” to help him understand the argument and learn from it.

(Try reading the right-hand column first, then both columns together.)

Following the scoring process we describe in Agile Conversations, Raj looked for two elements that are typically missing in conversations gone wrong: curiosity and transparency. 

Curiosity. Raj circled all the question marks he’d used in the right-hand column and then looked among them for genuine questions, those where the answers might surprise him and change his mind. There’s just one question, and Raj concluded this wasn’t genuine. In fact, it was a statement (“You should do automatic restarts”) masquerading as a question. So his “Question Fraction” was 0/1.

Transparency. Raj underlined all the sentences on the left that were not shared on the right (i.e., things he thought and felt but didn’t say). Being really charitable, he said he’d eventually shared his concerns about overnight workload, but underlined everything else on the left that he failed to mention aloud, including his feelings of betrayal and anger with Odette.

Difficult conversations like this one typically score poorly on both elements, so Raj wasn’t deterred in his quest to improve. He rewrote the conversation to boost both transparency and curiosity, aiming to learn techniques he could use when, inevitably, he had a similar conflict with Odette or another developer in the future. Then he tried role playing the conversation with a friend to practice the changed mindset and language, which felt foreign at first but more natural as he tweaked it during the role play.

After revising and practicing, Raj spoke to Odette again. (Again, don’t forget to read the right-hand column first.)

This isn’t a perfect dialogue by any means, but Raj has managed to ask two genuine questions and to share some of his thoughts and feelings. By responding productively, Raj has gotten two new insights: some error messages have recovery instructions, and Odette does know about and empathize with the workload of system admins. 

Raj put time into learning from his conflict with Odette, and as a result was able to learn important information and adjust his collaboration with developers for greater productivity and collaboration. If you invest similarly, you can mine your conflicts for valuable insights, building relationships and improving team performance very quickly.

- About The Authors

IT Revolution

Trusted by technology leaders worldwide. Since publishing The Phoenix Project in 2013, and launching DevOps Enterprise Summit in 2014, we’ve been assembling guidance from industry experts and top practitioners.

Follow IT Revolution on Social Media

• 
• 
•