3 Strategies for Approaching Conflict with Civility

Share on facebook
Share on twitter
Share on linkedin
Share on email

Let’s face it—conflict, especially within teams, is inevitable. But how you choose to manage the conflict is entirely within your control.

In my experience as a developer and Scrum Master, I’ve learned that approaching conflict with civility not only helps you maintain highly positive relationships, but also puts you on the right path toward building a transparent and brave team. Here are three strategies to help your agile team approach conflict with civility:

Lean into Conflict to Protect the Team

When team conflicts arise, you have two options: You can either ignore them and put work quality and values at risk, or you can lean into them to build trust and protect your team’s interests.

Sure, leaning into conflict sometimes requires you to initiate tough or uncomfortable conversations—but it’s necessary if you want to resolve conflicts faster, maintain high-quality work, protect team values, and create a safe, open environment where team members feel confident to share their concerns.

Let’s look at an example:

When any of my team members want to incorporate new code into a project, it’s required to go through a pull-request—a process where the rest of the team can review and critique the code changes. Because of this, we have a shared understanding that we need to embrace the vulnerability of critiques in order to get the best code.

However, after a new team member—who wasn’t used to working in this shared environment—received more comments on their code than usual, I noticed behavior changes that indicated they felt their work wasn’t valuable. Instead of shying away from this and assuming they’d get used to this environment, I initiated a discussion with them: I investigated why they felt this way, affirmed their value to the team, and expressed my appreciation for their input. I also explained that even though we scrutinized their work, we expect the same level of scrutiny for all work.

Embracing this conflict not only helped the team member acclimate to this new work environment faster, but also illustrates how we maintain a safe environment by protecting the team’s time, relationships and all other key elements of an agile team’s success. After all, making safety a prerequisite is one of the four guiding principles of Modern Agile—and it builds confidence for team members to speak up.

Leaning into conflict also protects the team from outside influences. I often see this with Product Owners, who are in a tricky position because they not only have to accommodate stakeholder needs—like company demands and user requirements—but must also funnel these elements down into a working product backlog for development teams. To protect the team, they need to ensure that whatever makes it to the backlog is good for development, so the development team doesn’t waste time on unnecessary features or need to revamp them later. If a request comes in, a PO may need to have a difficult conversation and say, “I know we want this, but this isn’t a priority right now.” Why? Because prioritizing dramatically increases the output of quality work, and a refined backlog will produce more feature content than if a PO can’t say yes or no.

Look with Empathy

When something conflicts with me, or I anticipate a potential conflict situation, I ask myself: “What circumstances could the other person be in where I would have made the same choices they did?” This exercise is not intended to just create a story that explains their behavior—it’s intended to prepare you for a conversation.

When you discuss a conflict with a team member, it’s crucial to ask open-ended questions on what happened instead of being accusatory. Put yourself in the other person’s position and ask for information, rather than demanding that they understand your perspective. After all, there are always plausible explanations, and this conversation is meant to discover those possibilities.

As a team, we like to build empathy through Sprint Retrospectives. Here are two examples:

  • Sprint from a Different Perspective: In this exercise, every team member puts their name in a hat. Then, everyone draws a name from the hat and the Scrum Master asks a series of questions like, “What was the most challenging aspect of this Sprint?” Each team member will answer as if they are the team member whose name they drew from a hat, without giving away their name. Afterward, the group will try to guess who that person is. Once the team member is identified, they’ll have the opportunity to confirm or reject whether that assumption was accurate. Why does this work? Because it forces you to think about the different perspectives on your team and it gives you the chance to dig deeper into each perspective. And instead of yes-or-no questions, you can make statements like, “Talk about how these Stories were or weren’t challenging,” to encourage more discussion (this is especially helpful for those who avoid conflict).
  • True Color Personality Assessments: This is another great Sprint Retrospective exercise that is based on an online leadership study. It’s a personality assessment that assigns colors based on personality types and characteristics. Based on what you know about the characteristics for each color, you can ask team members questions like, “How could the Sprint be made terrible for this particular color?” to see how they understand this personality style. For example, developers are typically green, which means they are logical and organized. How could a Sprint be made terrible for them? With unorganized meetings, vague acceptance criteria and frequent changes, to name a few. With this exercise, you not only learn how to prevent these things from happening, but you also encourage team members to understand different personality styles and how to communicate according to each style.

Walk Humbly

During conflicts, you can choose to “walk humbly” in two ways: 1) By maintaining a position as a continuous learner and 2) avoiding the hero concept. Continuous learning means you should leave all assumptions at the door; instead of assuming you’re right, approach conflict with humility and embrace the reality that a better solution may exist. No one has all the answers—but with this approach, the learning conversation moves toward the best resolution instead of who has the strongest argument in the room.

Secondly, neither you nor your team members should fall victim to the “hero” concept. Why? Because the more you believe that your best contribution is your talent, the more difficult it will become for you to separate from your contribution. It’s a vicious cycle that could make you uncomfortable with taking paid time off or may even make you question your work quality if tasks get delegated to other team members. For example, If I say I’m going to check in code every single day, then measure my value based on that, I’d be setting myself up for failure. If I evaluated myself based solely on deliverables, I’d be setting myself up for a transactional relationship with the team—but teams are not always transactional; they’re much more elaborate, and one transactional measurement doesn’t define what kind of team member you are.

Finally, if I feel like I’m on a path that could lead to a mistake or poor outcome, I talk to someone before it becomes a more critical issue. It’s much easier and less vulnerable to ask, “I’m on this path—is this the right path to take?” rather than correcting the path once you’re too far down it. Having good relationships with your team members is especially crucial in this scenario because it’s much easier to correct mistakes when you have the safety and security of a team that supports you. It’s a cyclical process, too; by correcting when you’ve made a mistake, you help build a more collaborative, secure team that embraces feedback.

When you lean into conflicts, practice empathy and walk humbly, you set the right precedent for how your teams should handle conflict. It’s not easy, and it may force you into uncomfortable conversations, but it’s the best way to protect work quality, team relationships and team values.

Want to learn how you can be a more courageous leader for your agile team? Consider the two-day Dare to Lead™ program, created by research professor and author Dr. Brené Brown. Learn more about the program and how Christy Erbeck—our principal transformation consultant and Certified Dare to Lead™ Facilitator (CDTLF)—can teach you the Dare to Lead™ curriculum and show you how to live and lead bravely.

Stay Up-To-Date