Scrum Master’s Diary
Sprint 87, Day 10
Sprint goal: release version 4.3.0.
Everyone hates conflicts, right? We are happy when there are no conflicts. However, in a cross-functional Scrum team conflicts are unavoidable, due to the different roles and competences of the team members.
This is not a bad thing. As an experienced Scrum Master, I can tell you that conflicts in a Scrum team are actually welcome for at least two reasons: (1) inspection and adaptation, and (2) creativity. Conflicts show us that something is wrong and needs to be changed – hence the increased inspection and adaptation capabilities in Scrum teams. At the same time, different perspectives foster new ideas, options and insights, needed for great decisions necessary for developing great products.
So, the trick is NOT how to get to the non-conflict zone with the Scrum team, but the key is to handle it and turn it into something meaningful and beneficial to the team.
A Bit of Theory – Levels of Conflict
Let’s look at the characteristics of conflict in general, before going to an example. In short, there are 5 levels of conflict, as defined by Speed Leas:
1. A Problem to Solve – most constructive
2. Disagreement
3. Contest
4. Fight/Fight (Crusade)
5. Intractable Situations (World War) – most destructive
As conflict progresses from level 1 towards level 5:
- the goal of the conflicted parties will shift from resolving a specific problem, towards winning the argument and lastly to destroying the other person(s)
- the language will go from fact based, towards personal attacks and lastly to ideologically dismissing the other person(s)
- the communication will go from open towards defensive while hiding some info, and lastly to blaming and no communication at all
Usual Conflict in a Scrum Team
In a Scrum team, conflict often happens between business trying to maximize value, while staying in the time-frame, and development trying to keep quality at maximum. In practice, this is usually a conflict between a Product Owner (PO) and a developer (if there is still hierarchy in the team, this is usually a system architect or a lead developer).
In my previous blog post I have explained one such scenario in more detail. Here I’m going to briefly summarize it (for further understanding of the full context, I suggest you to check my previous post). Our PO, Patrick, was trying to meet the release date by believing he is cutting the scope. In reality, he was cutting quality so the lead developer, Dave, protested. This quickly escalated into a heated conflict.
Applying the Theory in Practice – an Example
As a Scrum Master I wanted to teach my team about conflicts through resolving one, while empowering PO role and teaching the team how to collaborate more effectively. I started the retrospective with the conflict explained above:
Me: So, let’s talk about that situation between Dave and Patrick earlier. What was that about?
We started with a problem to solve (why a bug got into the release through PO’s decision), but the situation quickly heated up and in few minutes conflict reached level 3 (Contest). In Contest, it is all about winning, not problem solving (level 1) or defending and preparing for compromise (level 2).
Dave (developer) started attacking Patrick’s decisions focusing on the negative impacts. Patrick (PO) responded with very defensive language focusing on protecting his autonomy to make decisions and how Dave is not right. Phrases like “you don’t get it” and “I have to…” were thrown. There was even “I feel embarrassed by the code released” and “I know how to make good decisions”, showing the levels of frustration and how personal things were becoming on both sides.
The language and boiling energy was telling me things are going south, quickly. It was time to intervene.
De-escalating the Conflict – an Example
Me: OK guys, stop! This is getting way too personal now (de-escalation attempt), so as SM I’m taking over (role boundary) until the situation is calmed down, and you can resume normally (agreement to give the control back to them).
I explained that they are in a level 3 conflict and that we need to de-escalate while addressing their legitimate concerns. Then I briefly explained what level 3 conflict means. After that was clear, the next goal was to start a dialog between them.
I started by explaining some of Patrick’s motives and how that falls into the PO role. Then Dave’s motives were explained and put into a developer role perspective. Once the conflict cooled down, I gave the reins of control back to them. They both got the opportunity to build on the conversation that was started, adding any untold motives and opinions.
After the exchange, we moved to closing the conversation. I asked do they understand each other better now. They did, and other team members understood the situation better, too. With the conflict de-escalated, we were ready to move on.
Learning and Moving Forward
Next thing on my list was to teach how each Scrum role (SM, PO, Developer team) guards different aspects of a good product (development), and how achieving a balance of these aspects is crucial. In order to prevent future heated conflicts, we agreed that it was not the personal winning, but the collaboration towards a mutual goal – excellent software!
Me: Good. Your motives are clear, roles are clear, but we still have that problem to solve. Let’s now work together on that one. For starters, can someone explain the difference between scope-cut and quality-cut?
Dave knew, so he explained it to the rest of the team. The team (including PO) agreed that in the future they should exclude a feature with the bug from the release, and provide a hot fix for it in the next sprint (if the date of the release cannot be changed).
The conclusion is, the retrospective kicked off with the conflict, and ended with the team members learning something new and being motivated to learn even further during the next sprint. Specifically:
- Team understood Scrum roles and responsibilities better
- Team learned the difference between scope-cut and quality-cut
- PO wanted to collaborate on integrating value-driven decisions into our release process
- Team asked for a conflict learning workshop
- Team became more capable in resolving conflicts on their own
Takeaways
- Conflicts are natural in every team, especially in a (cross-functional) Scrum team
- Conflicts are very useful when controlled. They can be utilized for assessing, learning and improving
- Language and communication are excellent tools for assessing the conflict level
- You need to develop people’s soft skills in order to help them work together as a self-organized team
Did you have a similar situation in your Scrum team? What were the reactions of the team members?
