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.)
|What Raj thought and felt||What Raj and Odette said|
|How thoughtless! We have 150 services to run—how can we possibly know when to restart and when to phone?||Odette: Raj, I can’t believe your team woke me up to investigate a simple error. They didn’t even try restarting the service.|
|Your “simple error” could have brought down the whole cluster. We did the right thing, and you know it.||Raj: I’m sorry you’re annoyed, but the night shift followed our agreed protocol for critical failures.|
|What? You reviewed the out-of-hours runbook just last month! You just want to blame the sysadmins, as usual.||Odette: That protocol sucks if it doesn’t include obvious remediation steps.|
|If you gave a damn about users, not to mention us operators, you’d stop making us prop up your fragile, undocumented systems.||Raj: Sorry, but it’s not obvious to us, with so much to do every night. If restarts are needed, why doesn’t your service do them automatically?|
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.)
|What Raj thought and felt||What Raj and Odette said|
|Did I understand Odette’s statement? And does she really know how much the person on call has to do?||Raj: Can I follow up on our conversation yesterday? I’d like to check I’m understanding correctly—you’d like us to restart on any error? That would be very difficult with our high overnight workload, and seems unfair to the on-call person. Do you see it differently?|
|Oh, I didn’t know that error strings had that kind of remediation info in them. And she’s clearly aware they have a fragile, error-prone service.||Odette: No! Our service has so many errors, you’d have time for nothing else. But when the log message explicitly says “please restart,” you could at least try doing that.|
|There might be something we could do to avoid this in future.||Raj: I see! It seems to me we could get the restart instruction out of the logs and into our runbooks. Would that be useful?|
|This would help reduce our on-call stress levels a lot.||Odette: Sure! I can show you a list of the error messages if you like.|
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.
To learn more, read DevOps for the Modern Enterprise: Winning Practices to Transform Legacy IT Organizations from Mirco Hering.