Respect for the Individual is a part of my company’s culture and a huge part of my personal belief structure. When I was a kid and would get in a fight with my siblings my parents usually took the “stop your fighting now; kiss and make up” approach. So, as I grew up and entered High School, University, and the workforce, that was the approach I would most often take; if I saw conflict arise I would encourage the parties involved to stop fighting and “kiss and make up”, as it were. What I’ve come to understand as a Scrum Master and Agile Coach is that conflict is not always a bad thing. In fact, in order for self-organized teams to reach their fullest potential, conflict is necessary.
I was first introduced to this concept by Lyssa Adkins and Michael Spayd at the 2012 Scrum Alliance Global Gathering in Atlanta. They were leading a break-out session entitled “Embracing Conflict: A Systems Intelligence Approach to Conflict Facilitation for Scrum Masters, Coaches & Leaders”. There I learned that there is a difference between Productive Conflict and Unproductive Conflict. In essence, Productive Conflict is issue-driven, where the conflict is centered on a disagreement on how to address a given need, whereas Unproductive Conflict is ego-driven. This was a fascinating concept to me at the time – that there exists a type of conflict that is not only okay but should be encouraged! Despite their masterful instruction, I still struggled with this as I naturally shy away from any form of conflict. I’ve gotten better in the year and a half since I heard this message, and would like to share some advice from what I’ve learned.
I have a son who is almost six. He can drive my wife and I crazy with what she refers to as “Whyarrhea”; he asks “Why?” so often that it’s as if he has no control over it. I fear that my colleagues may feel the same way about me! I always want to understand “Why?”. Why did you choose that tool? Why are you producing that metric? Why are you having this meeting? Why are you working so many hours? You get the idea.
People who feel compelled to do things without understanding why they are doing them scare me. So, when I see conflict arise in my team, I start asking “Why?”. I want to get to the root of what they’re arguing about, and I don’t stop asking “Why?” until I get all parties to the same root problem. Once I understand what they’re really arguing about, I get them to explain their contradictory solutions so that we can all weigh the pros and cons of each. Once each solution is explained, I ask what it will take for us to get to a consensus, be it a proof of concept, cost/savings analysis, weighted requirements matrix, etc. I remind them that the solution doesn’t have to be perfect, just good enough.
This approach doesn’t work if the conflict is ego-driven, and this root cause analysis, logical solutions approach will reveal Unproductive Conflict fairly quickly.
Ask the Stupid Questions
I come from a background of software development, but I like to act like I don’t sometimes. If the team seems to be chugging along without any kind of disagreement I may throw a wrench in the system by asking something they might consider being a stupid question. “How are you going to test that?” “Why don’t you do it this way?” “I heard about this Open Source library we could use, why don’t we try that?” These questions are good at introducing Productive Conflict in one of two ways. First, I might strike a chord that resonates with one of the team members who didn’t want to speak up at first, thus bringing out a beneficial conversation that might not have otherwise taken place.
Second, the team members may find that they agree on a decision but not for the same reasons; by trying to answer me, they may find that there is an underlying factor that they disagree on which may impact implementation details or future decisions. Without the “stupid question”, this realization may have occurred much later down the line, if at all. Some may think that not ever revealing a disagreement is a good thing; what they do not realize is that the conversations that those disagreements create and the consensus that results makes the team much better than they would otherwise be. The sooner we can make that happen, the better.
Solicit Ideas prior to Conversation
What is the point of Planning Poker? Most people will tell you that it’s to prevent influencers from running the show when the team is estimating the work, which is definitely one of its major benefits. Without something like Planning Poker, the timid on the team would be left to accept the estimates of the bold, resulting in a lack of ownership and some rather passive-aggressive Retros when commitments are not met.
This concept can and should be extended to other realms as well. Use this when picking a tech stack. Discuss the need first; make sure that everyone understands what the purpose will be behind whatever language, library, or tool they will be picking. Then let everyone bring their solution proposals to the table, with everyone revealing their recommendations at the same time. This gives everyone a voice and produces conversation that might otherwise not have happened.
Separate Ideas from People
Great, high-performing teams embrace Productive Conflict because they don’t associate people with their ideas. All ideas belong to the team, and no person is belittled because their idea was not chosen by the team. This is difficult for many people; it is hard to have your idea rejected without feeling rejected as a person. You can help by referring to ideas by a name or title appropriate for the idea, such as “Spring” or “EJB3”, and not “Bob’s idea” or “Susie’s suggestion”.
You can also reinforce the team’s ownership of ideas by congratulating the entire team for a job well done when ideas are successfully implemented. We succeed or fail as a team, not individuals. If an idea isn’t working out then let’s fail fast and do something different; it does nobody any good to dwell on the fact that the idea was so-and-so’s to begin with. The conversation that led to the decision to implement the idea should have involved everyone and ended with team consensus. That means that, by the end, it was the team’s idea, not one person’s.
My CIO, Karenann Terrell, uses the phrase “Respectfully Real” when she wants to discuss something we could be doing better at as a division. She encourages others to voice concerns and even dissent, so long as it’s done respectfully. She understands the power of embracing Productive Conflict. She sees what Lyssa and Michael see – that teams have their own attitudes and behaviors, and that Productive Conflict is an essential tool at improving the team as an entity beyond any of its individual members. Not all conflict is productive and respect for the individual is paramount; however, trying to squash all conflict with a “kiss and make up” approach instead of leveraging it as a tool for growth shows a lack of respect for the team and does them a disservice.
What are your thoughts on conflict? What methods do you use to identify what particular type of conflict is arising? How do you foster an environment that promotes and encourages Productive Conflict? I’d love to get your thoughts. I also hope that I did justice to Lyssa and Michael; if you would like to learn more about taking a Systems approach to Agile Coaching, I suggest you look them up and learn more directly from the source.