The War Room a.k.a. Team Room

“So how do you feel like things are going?” Scrum Master Donny asked during his bi-weekly one-on-one session with Sasha, one of the Development Team members. “Great! I really feel like I add a lot to the team, I’m reworking the errors of others and have good insights into this feature.” “Here’s the thing. I’ve been noticing you’re really putting yourself above the rest and therefore have decided to take you out of the team.” As you might imagine, Sasha didn’t see this coming. The Scrum Master taking her out of the team, by his own, while she had the idea everything was just peachy.

But is a Scrum Master really to take team members out of the Scrum Team?

Create a foundation of trust

In all of my career, I have just encountered one situation where things gotten so far that one of the team members was removed from the Scrum Team. But before I get to how (it’s all the way down), I want to start off with the concept of trust in a team. Usually these situations point out to a greater, underlying problem.

Some questions to think about:

- What has happened that things got this far?

- Are the people involved aware of their own behavior?

- Are the people involved aware of each-others viewpoints?

- Are we as a team, as a system, able to provide and receive objective and constructive feedback?

- Are we all having the same shared goal we are working towards?

- Have we defined clear boundaries and responsibilities?

- Are we clear on our team identity and have we agreed upon how we view collaboration?

This is reverse engineering the situation a bit, but it may provide valuable input to prevent things happening in the future. In my experience, forming a base of trust is being skipped out and people have a strong tendency to dive right into the work. The whole purpose of a Scrum Team is to deliver value. It is really hard to actually deliver value if we do not trust the ones we are creating this value with. The Development Team ultimately is responsible for their own progress. In that sense they are committed to each-other to helps themselves become as great as they can be. Being able to share objective, constructive feedback helps a team grow.

Negativity is toxic

Not having this solid foundation can potentially split a team apart, creating factions amongst them. Other team members could attach to the strongest opinioned person, the person who shouts the loudest and so on (you can see where I’m going with this). Wally Kozak has a great clip about how this could potentially affect people. One that I quite regularly use when teaching courses:

https://www.youtube.com/watch?v=e5jYAVTaopY&list=PLP_Iu4htW2ILEBUToO53k9AgIoDPYwihI&index=5&t=0s

As a Scrum Master, it is up to you to make the Scrum Team aware of this destructive behavior and let them see the potential consequences. Let’s go through the Scrum Values real quick to just think about the possible impact:

Focus: a team in heavy disagreement will likely focus more on proving the other wrong and gaining people in their faction than to focus on the Sprint Goal or delivering value.
Openness: I’ve seen this so many times as soon as conflict starts to arise; people will hide everything out of fear that it will be used against them or in the benefit of their antagonist. You can imagine how this could spiral down into technical debt.
Courage: Having courage is good thing. Having courage to speak up is great. Having the courage to shut up at the right time is very hard, though.
Commitment: We commit to quality, to value, to each-other. Commit to agree to disagree. The latter two fade real quick in case of extensive conflict.
Respect: Did you ever held an eye on how you respect someone you’re in conflict with? Or their views? Exactly..

And this is just interpersonal conflict, not taking technical, economical or intrapersonal challenges into this blog.

The Scrum Master is the shepherd of the Scrum Team

In the end, a Scrum Team is not there just because they can. They exist to deliver value. The Scrum Master shepherds the process towards greatness, towards being as good as possible, towards delivering this incremental “done” pieces of work. He removes the impediments that stand outside of the Development Team’s control or facilitates to mitigate them when needed. Sometimes people are the actual impediment. Not because they want to be. I’ve never seen anyone wake up and think “I’m gonna be a big, fat impediment today!”. And given enough time, a Development Team would be able to resolve anything themselves (with proper guidance). However, we still work for organizations that pay our salaries. So (unfortunately), time and cost constraints are of effect and Scrum Masters need to take this into some account. A Scrum Master does not pro-actively remove people from the team. However, it might be the case that a person has become the impediment keeping the rest of the team moving forward. By facilitating the choices of the team, a Scrum Master could have a part in the departure of that person.

My single experience:

Here’s my story in a nutshell (emphasis on nutshell). I’ve been in this Scrum Team that had 1 specific Dev Team member that in the beginning was very much unaware of his own behavior. So I started coaching him. An older, bit more conservative type of man. He was opinioned that every one else needed to change, because it certainly couldn’t be him that was the problem. Things seemed to get better, people used the COIN method for feedback, organizational impact was better. But destructive conflict started popping up again. He started to get more personal and offensive, so I took more time for our coaching session and to go deeper. We discovered that the issues that he personally had with himself were far beyond the point of what I can help him with. He went to see a therapist. And again things looked to improve. And go back into destructive behavior again. Until the point that other team member were either just not coming in anymore or would work in a different places. Now the impediment has gone to far and brought total disbalance in value and effort. And although maybe once or twice that is sort of okay, as it might be a valuable learning opportunity, but at this point the guy had become the impediment himself. As a team we crossed out all options at hand and the Development Team decided that they would rather be productive without him. Making sure that they considered this carefully, I worked with his manager and HR so that he would get proper help and would continue to work elsewhere(outside of the Scrum Team).

As you might expect, things improved within the team soon after that.