All Things Agile - Episode 010 - Resolving Team Conflict

Welcome to another episode of All Things Agile. In this episode, we discuss the tough subject of team conflict. Whether your Agile or not, every organization is bound to encounter team conflict. We'll discuss how to resolve existing conflict as well as preventing it from even occurring.

I am also very excited to announce that the next episode will feature an interview with notable Agile author, Ken Rubin.  Ken is the great mind behind Essential Scrum. I hope you enjoy this episode and make sure you subscribe to catch the upcoming interview using this link: iTunes. Reviews on iTunes are also always appreciated. Do you have a question that you would like answered in an upcoming podcast? Please send your question to: [email protected].

All Things Agile - Episode 010 - Resolving Team Conflict

Transcript:

Welcome to the All Things Agile Podcast! Your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast on iTunes, and please check out our sponsor: TeamXcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile Podcast! First off, I want to get started by issuing an apology for the delay in getting a new episode out. The reason why is because I have an upcoming guest and unfortunately, we are not able to get the scheduling worked out in time for this episode. But, I am pleased to announce that Ken Ruben, author of Essential Scrum, will be the honored guest in our next episode.

That said, I want to go ahead and issue another episode. I don’t want to keep you waiting too long – and with that, I hope you accept my apologies for the delay in getting this episode out to you. Now, before we begin, a quick reminder that this podcast is for informational purposes only and accepts no legal liability. So the topic for today will be ‘Resolving Team Conflict’. Virtually any team you will be working on is going to have some degree of conflict. It’s just part of human nature. You can’t all agree 100% of the time, even though Agile encourages more of a democratic approach to what the team is working on and the approaches that they use, there’s bound to be some degree of conflict on any team that you work on.

Now, before we dive into solutions to resolving team conflict, let’s first identify the different types of conflict. One type I think is just general healthy conflict and what really we’re referring to is debate. Using the word ‘conflict’ is probably inappropriate in this particular case. An example of debate, you may have people that share different ideas and solutions and what type of technologies should be used, or different coding practices, whatever. That’s fine. Having those healthy debates, discussing ideas, is actually a good thing. In this case, it allows you to have differing points of opinion which can be discussed, evaluated and reach an ultimate decision on. And that’s fine. That’s a healthy form of debate or conflict, if you will. And, if you have a little bit of that on your team, that’s fine and I wouldn’t worry about it.

What we’re really going to be focusing on in this particular episode, is unhealthy debate. And I would describe unhealthy conflict or debate as a case where it’s really impacting the team. Where it’s creating what I like to call a toxic environment. You can definitely tell it when you’re part of a team that’s having this because it just brings everybody down. It brings the morale down, and it just feels like the team has been poisoned, if you will. And you’re going to see evidence of that not only in the morale, but the conversation, the level of communication and collaboration are going to go down. You are going to see people that are going to be engaging in using a lot of inappropriate language. You’re going to have a lot of people getting into some sort of personal battles with each other or one-upmanship, and it just really destroys the overall team morale and ultimately, the productivity. And you’ll actually begin to see this long-term in the metrics where you’ll start to see a team that was doing really well, and then they start to perhaps have their velocity dip down and more and more of their stories are being accepted late, etc. So that definitely has an impact. I would definitely classify unhealthy conflict as conflict which is really bringing down the team. It may be disrespectful, and it’s simply just not in the long-term viability of the team. So that’s kind of how I would probably classify the two main types of conflict that I see, either healthy, just discussion of topics and technologies versus some things more personal and toxic. And so we’re going to talk about the latter and how do you resolve it?

Now, I have personally seen these cases come up numerous times in my career, and if you are particularly in a situation – your team or teams that you’re coaching or another team in your company that you’ve seen this kind of just not quite right environment, just a little bit toxic, that’s not uncommon. First off, it’s bound to occur on average. So that said, even though it’s a common experience within a company, you certainly don’t want to maintain that toxic environment. Because here is an interesting point that I have seen personally which is if one team is currently experiencing a level of poison, if you will – not only does that team’s morale drop and their productivity drop – it can spread to the other teams. It’s true.

You can have a team that is doing really well, but if their neighboring team is engaging in disrespectful behavior and yelling at each other, cursing at each other, it’s going to impact the neighboring team. They are not going to want to come in to work that day. Their morale starts to drop and then their performance starts to drop. So another reason why you want to deal with unhealthy teams head-on is because not only do you want to help that team, but you also want to ensure that the degree of poison really doesn’t spread to the other teams and disrupt them as well.

Alright, so let’s talk about some practical tips that I’ve personally implemented in the past and found beneficial. Again, every company’s unique, every team’s unique – you’re responsible for your own actions, but something that has worked well for me is to focus on the present and the future. Often times when you’re trying to resolve team conflict or coaching the teams through conflict situations, the team members may get too focused on the past and the things that happened. And, what I mean by this is that I’ve certainly seen cases where people get into paper trail battles. You know what I’m talking about? Where you have someone who has an email that they sent 6 months ago, and they bring it out. ‘Six months ago you said blah blah and now you’re saying this!’

So you have these people that hold on to every little piece of communication, every little email and their real honest reason why they do so is so that they can spit it back out later. And candidly, that’s not healthy. And when you really analyze it, those persons, those individuals are focusing their attention on things that occurred in the past, right? ‘Two weeks ago you said this; last year you did that’ and so they can get into a lot of negative debate, a lot of disrespectful behavior sometimes because they’re so focused on past hurt. And they’re not really learning to forgive and let it be water under the bridge. And they’re just holding on to that pain, and they’re then letting that disagreement, anger, and pain, poison the waters in the present and then going forward towards the future. And you don’t want that.

One of the first things I like to focus on when trying to coach a team is to – sort of phrase of the idea is: keep the water under the bridge and keep it there. Okay? Don’t say ‘Oh well, yeah, okay we can move forward’ and then the next week later ‘Again, I told you 4 months ago that this is the way we’re supposed to do it’, etc. And again, that leads to that negative behavior if you’re always bringing up the past. And so whenever I’m sort of involved in trying to coach a team, I try to think about staying present, right? Think about: never mind the past, whatever happened in the past has already happened – we can’t get back into the DeLorean and go back in time and try to fix it. So in that case, what can we do right here, right now? Stay focused and present. And if you’re speaking with them and they start going ‘Well, what about that 3 months…?’ just say Stop! Stop. That was in the past, we can’t change it – what we can change is the present, let’s focus on that. And it’s not easy to do, but try to hold a hard line on that. Just say ‘That’s in the past, let’s learn to forgive and put that behind us and carry on for the present and the future.’

Now, if you can work on that and allow the team to avoid getting into those negative conversations about the past, then I’d say the next step is to focus on what actions or changes they can make here in the present to avoid future pains. So, for example, if part of the past pain was say, for example, some of the defect procedures were not being followed, as an example, and people were complaining about it with each other about whose fault it was – this person didn’t follow procedure and they should have, and someone has a paper trail from 6 months ago. To avoid that situation, I would say: Identify what changes could prevent that problem from happening again. So, for example, you might do six sigma root cause analysis, if you will and say ‘Okay, what really happened? Why was the process really not being followed?’ Well, maybe one reason is because the tool being involved wasn’t adequate enough. Maybe you just need to upgrade your toolset, maybe there’s some other procedures that can be added. Maybe someone needs to go through some additional training or maybe involvement with another team can be changed or improved. Or another team member’s schedules can be altered to allow them greater flexibility in the work schedule. Whatever the case may be, but the point is this: don’t dwell in the past, it’s already happened, okay? And then, for being able to resolve the team conflict, identify actions or steps that can be processed right here, right now and able to prevent that future pain.

In terms of where it’s a little bit more personal – that does happen sometimes, where you have teams that for whatever reason, people harbor personal grudges towards each other, and even if all of your policies and tools and procedures are all well and good, some people may, simply put, just not like each other. It certainly can happen. Again, most of the time, teams will be okay with just changes in their practices. But, there will be cases where people just simply have personality clashes and where I’ve seen that in the past – if it’s really that strong, I would say it can be sometimes worthwhile to go ahead and switch some team members around. There can be cases where, for whatever reason, those overlapping personalities just bump up against each other just a little too strong, but you can take that individual and perhaps shift him to another team, and he’ll work perfectly well there! Because at the end of the day, all team members are not equal. We each bring our own level of skill and personality and really, you don’t want everybody on the team to have an exact mirror copy of each other, in terms of skillset and personality. You need that diversity because it helps produce a more well-rounded and ultimately balanced team.

If one person, for example, is a little bit more thorough and another person is a little bit more sort of quick to act, actually having them on a team together can sometimes help because the person who’s more thorough will help balance the other individual out and ultimately, you can end up with a sort of a middle ground which is actually pretty well and functional. However, if you have those personality clashes where perhaps you have two individuals that are for example overly thorough and they may be bumping heads with each other, maybe that person belongs on another team and maybe there’s another team out there who needs that type of personality and skillset and they may actually be a welcome addition.

Now, it is kind of like a last resort to implement team member changes to shift the morale, but it is certainly better to do that than to let the team continue in unresolved conflict. And I know it takes a little bit of guts to go ahead and to talk to people and say ‘You know, I think we need to move you to another team' but you got to think about the overall team and the overall organization with the other teams. And again, if you let this team remain unhealthy or toxic, it’s going to spread to the other teams and you certainly don’t want to do that and that’s not fair to the other teams, to have that happen. So, again – I always start first by avoiding getting into the past trauma state, focus on the present, evaluate what options can occur in the present, changes and practices, etc; they can be implemented to prevent future pain and if it is a situation where it’s kind of a deep personality clash more so than the practices, there need to be team member changes. And that’s okay, and that does happen – I have certainly seen it happen in other teams as well as my own teams before. And that’s okay – in a larger organization, it’s bound to happen sometime.

I would say, kind of like an ultra-last resort, I really hate to see situations where a team member is removed from the company. That has happened, I have seen it happen, but that is such a last resort action and I would certainly encourage any Agile professional that’s trying to help a team experiencing conflict, that they truly keep that as an absolute last effort action. And the reason why it’s because it’s my belief that it’s easier to coach and maintain than it is to replace. Whenever you replace a person in your organization, you’re incurring cost not only with recruitment, but also with the interview process – people have to take time out of their days just to interview the guy or girl – but you also have to consume time with training and getting them up to speed and having them learn the culture and the ins and outs of the team, team practices or they may be new to Agile and you have to train them with that. So all that process can easily take a couple of months. And in doing so, the team’s velocity is already impacted. So I personally recommend, whenever possible, try to coach through the situation and reach a solution, rather than simply just throwing in new bodies. That’s my experience and that’s my belief. So, again – this is sort of a fourth option there, kind of last resort.

But those are the strategies that I’ve employed to try and resolve team conflict and that’s a conflict once it’s already occurred. And I’d actually like to take a moment and cover a different topic which I honestly think many Agile professionals don't even consider, and I haven’t seen it mentioned too much in articles or books, and that is preventing team conflicts. The material I just covered a second ago is in relation to resolving team conflict once it’s already occurred. But, the old adage is that an ounce prevention is worth a pound of cure. So you might ask yourself: how can we prevent team conflict from ever even occurring?

I’ll offer, I’d say about 4 suggestions that I believe, if you can implement them, they may help you. I’ve certainly seen them help teams in the past. The first is co-location. When you’re able to bring the team together physically, like they’re actually physically sitting next to each other, it often times helps prevent team conflict. If you have teams that are composed of a lot of full-time remote members, it can be difficult to maintain a healthy team. And the reason why is because of the bandwidth of communication. And the highest bandwidth of communication is face to face, where the person can see the other person’s gestures, the tone of voice, etc. And if they’re remote too much, then you’re doing a lot of email, a lot of IM chats, etc. and it’s so easy for the words to get misinterpreted, to get lost in translation. And so, in that case, it’s just bound to result in team conflict eventually. So if you can co-locate the teams, and I mean physically co-locate, like in the same office area, that really helps with being able to reduce the chances of team conflict ever occurring.

Second way I’d highly suggest is in how you treat the team members. And what I mean by that is this: if you have a team of let’s say 7 members or whatever, and one or two of those members are always favored upon by management or leadership and always listens to those individuals and nobody else, or those individuals get included in all the important discussions and meetings and nobody else does; they’re the ones that always get promoted, that receive a healthy salary and everyone else doesn't– that’s bound to create team conflict, right? But if you can really look at the team as a team, and comprised of many different people, each bringing their own value and contribution to the team, that will significantly reduce the chances of team conflict from ever occurring. Because you’re reducing the likelihood of people feeling disenfranchised or left out. Or disrespected. So if you can prevent that – again, it’s a lot easier to prevent team conflict than it is to fix it once it’s occurred, right?

I would say that another way to help resolve team conflict is through training. I’ve seen so many times where Agile teams are just thrown together and the training aspects is never really fully delivered on. Even though it costs a couple of thousand dollars, it’s far worth it to ensure that your team gets off to the right start. You want to ensure that, for example, all the Scrum Masters become, in my opinion, Certified Scrum Masters, Product Owners become Certified Product Owners – again, these are my experiences; your actions are your actions. But that’s my personal opinion – when you’re able to have those individuals be formally trained, it really does help because they learn the right practices, not just the way that the companies or organizations are currently operating. And that’s important!

I also recommend having all of the team members receive some sort of Agile training. Again, it enables them to have buy-in, and enables them to better understand the changes being implemented and why, for them to really see the benefits. If you simply throw people on an Agile team without adequate training, I think you’re setting yourself and the team up for failure. Don’t do it. Even though there may be some costs involved in training, it is absolutely worth it to do so because the longer term cost of not giving them adequate training and education will be ten times worse or even more than the cost that could’ve just been handled up front through adequate training. So I definitely recommend doing that. Don’t skimp on training and coaching and that’s not some ad or something for my own benefit. I mean this sincerely that I have seen teams and organizations that did not train adequately and I’ve seen others that did. And it’s a night and day difference. And again, by doing that, you’ll help prevent the team conflict from ever even occurring, and that’s certainly something you want to do.

The fourth thing that I would like to throw out there, a suggestion again to prevent the team conflict in the beginning, is how you form the teams. Who’s on the teams and in what roles or capacity? So many times I have seen team conflict occur because the team members are just thrown together. Look at a spreadsheet, get some names, throw them on a team. That’s simply just not wise. You need to really examine the skillsets and the personalities. Who’s got a strong personality? Who’s going to be the person who’s going to challenge the status quo? Who’s the person who’s going to be a negotiator? Who’s the person who’s going to help bridge different people together and help people come to a consensus?

Finding out those personalities and the skillsets, including development and maybe testing skillsets, finding out those individuals and then seeing how to craft them into a functional and balanced team really pays dividends because they are far less likely to have conflict. They are going to be able to work with each other and compliment each other. If you just simply throw people together in a team, you’re just asking for conflict. And not only that – but if they’re not balanced properly, if you look at for example the work each member’s contributing during a particular sprint or iteration, you’re more likely to find that the workload isn’t very balanced and that’s usually because the team’s not balanced. They’re not properly structured. So prevent the conflict in the first place by investing time to ensure that from all the people you have across the organization, that you’re really analyzing their skillset and personalities and putting them together and positioning them to win, right? If you’re just throwing the bodies together into a team, you’re just asking for failure and conflict. If you invest the time – and really, how much time does it take, folks? A couple of days, maybe, to really take a deep look at the team members and really consider who would be great to partner up with who and if you can spend that time to partner the team members up correctly, it really will pay dividends. If you can do that, you’ll prevent a ton of team conflict down the road. So that’s four suggestions for you, in relation to preventing team conflict, on top of the other suggestions on resolving if it’s already occurred.

Alright, well I think that wraps it up, regarding for how I have personally tried to resolve and prevent team conflict. I certainly am open to hearing your suggestions. If you have any, feel free to send me an email at [email protected]. And don’t forget to check out the AgileInstructor.com website and TeamXcelerator.com website. And as mentioned earlier, I do have a special guest coming up in the next show, which is Ken Ruben, author of Essential Scrum and I’m really looking forward to asking him some really great questions I think you’ll enjoy and find insightful. Well, I think that wraps it up for this show – thank you so much for your patience in waiting for a new episode, I apologize for the delay and looking forward to releasing a new episode with that great interview with Ken Ruben. Thank you very much! Goodbye!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!