Scrum Master Confabs - Managing Scrum Team Conflict

On 6 September 2020, we did a discussion on the Agility Thinking Whatsapp group about the below scenario and many of the practitioners actively participated. We all know there is more than one solution to any problem. We let our practitioners discuss how would they approach such scenarios when faced and have documented for those who are looking to solve similar scenarios. 

"Deepak is the Team Lead of a Development Team. He helps the team in making technical decisions and also acts as a mentor for new members. Vinodh is the Product Manager of the team and is very new to the role and also in taking up decisions. Due to the pressure of Stakeholders, Vinodh brings up a new feature in the middle of the Sprint for the fifth time for he is unable to say no to them. The team feels bad for switching their work in the middle every time and says this is unfair. Deepak stands up for his team and he counters Vinodh by saying, "You better learn your job faster or it is going to get difficult for us". Vinodh feels embarrassed by this statement and tells Deepak that he is better to deliver what the business asks for. That's why he is getting paid. 

This conflict escalates into a verbal war between these two people. Let us say you are a Scrum Master/Agile Coach who is present in the meeting room when this happens. How will you tackle this?"

Deepak Agarwal: Explain to the Product Manager that this is not how Agile works and that he cannot introduce new things in the middle of the sprint. Also, explain the consequences of doing that:

- there might not be something to present at the end of the sprint since requirements changed in the middle

- the team feels pressurized because of this and that affects productivity and delivery

- the stakeholders suffer because they'll not get to see things on time

- the product manager will suffer because he won't be able to deliver something on time

With that, I'd also explain to Deepak why it is essential to assist Vinodh in learning how things shall be done instead of calling him out in a meeting.

Note that, these discussions would be done separately with Vinodh and Deepak after ending the meeting there to avoid further escalation of the situation.

Later, the team and I can help Vinodh in explaining these things to the stakeholders to set the right expectations.

Saravana Kumar Mohan: The scrum master could help the team realize that all problems are opportunities to come up with a better solution that works for everyone. In this example, the scrum master can lead by helping the team identify the cost of not accepting a change mid-sprint... This helps the entire team understand the nature of changes coming in and also the impact... Helps the team prioritize work based on empirical evidence and gives the PO some perspective to share/defend with the stakeholders as well...

The process will point out if it's critical and with this clarity, based on the value being delivered, the entire team would have lesser resistance to such a scenario...

Of course, this is easier said than done... 🙂

Ramkumar Arumugam: The Scrum Master can have separate conversations with Vinodh (PM) and Deepak(TL). SM can highlight the impact of change management on the team's velocity and commitments from the past sprints with data like burn-downs, and tech debts to support his viewpoint. SM can also coach Vinodh(PO) on prioritization, negotiation, and how to say NO to features that are not needed. SM can coach Deepak(TL) on implementing some engineering practices (micro-services, developing in small batches, automation, etc) that can reduce the burden of task switching. 

Ideally, SM must have intervened during the second or third time when this change management happened to avoid this.

Shailesh Canchi:  Changes are inevitable but if it becomes a pattern of abrupt changes that adversely impact the sprint goal, puts people at unease, demoralize the team, and ultimately lead to fragmentation and confrontation among the team should be put to an end immediately.

SM/Coach should have taken note of the pattern and should've nipped it in the bud.

SM Role:

1. Should sit with PO and understand the reason for abrupt changes.

2. SM should coach the PO to better handle the changes rather than bringing them abruptly.

3. If required SM should facilitate a call between the stakeholders to bring them to a common ground.

Dev Team:

1. SM should encourage the dev team to bring up the issues upfront rather than waiting too long and losing cool.

Verbal Altercation:

1. As SM, I would jump right in and stop the confrontation first.

2. Issue a break for sufficient time, so, that tempers would cool down.

3. Reconvene the meeting and help the team understand the impact of such altercations on the team and personal level.

4. Enable individuals to put forth their issues in a polite way.

5. Finally, make peace between both.

Vineet Pasari: I would sit with both Deepak and Vinodh individually and have a chat with both guys...

While speaking with Deepak I will inform you that he is correct but only partially when he speaks about how the team feels about these frequent changes in the middle of the sprint but he should also understand that Vinodh is new to the team and instead of having a verbal fight and giving ultimatums, try to put his point across in a way which would help Vinodh make an informed decision.

And with Vinodh, I will again remind him about his vast experience and having a verbal spat which has escalated doesn't look good for him and to listen to Deepak in a fresh mindset and let me, as a scrum master be a part of the meetings with the stakeholders so that I can assist him to convince them about the frequent changes which are putting the team morale down and ultimately be bad for the quality of the product.

Arunkumar GDR: As Satisha rightly mentioned earlier in his post, every project has its own ecosystem and challenges. The SM should be gutsy enough to pick the role on firsthand only if he himself is confident and clear on core SM principles and System thinking thought. The theory is built based on the massive experience of people. Assume the theory as a baseline to start with. It's okay if all bullets in theory don't fit your ecosystem at first. Even if an SM fails in execution for a few months at the start, that's okay too. What's most important is an openness to learn and motivate people. Talk to the team, listen to their views, learn from mistakes, bridge the gap, and address the gap as a real-time action as we progress. Ensure you are with the team and make them comfortable in addressing the barriers. This is how all progress is made with any successful team. 

Some of my real-time challenges faced with the PO and SM. I would like to share this with the audience. Definitely HOW NOT to be an SM and PO. 

1. Threatening the team who doesn't listen to their orders. Trying to corner and isolate the individual team members.

2. Discriminate based on their org role and experience and in the appraisal.

3. Threaten the team to attend calls anytime all days in the week because it's an onsite ask. No guts to question onsite or say even a word. Assuming offshore as a slave mindset.

4. Request multiple versions of status reports other than scrum metrics:

5. Keep demotivating the team saying velocity is very low on every sprint. Questioning their capability without even knowing the business and tech complexity and feasibility

6. Don't reveal anything to the client. Say a different version completely to the client. Even if you are off, or engaged with org work, say you worked on something.

7. During COVID time knowing the situation and misusing it and threatening good resources to leave If they can't listen to their orders.

8. Say to read plural-sight if an experienced team brings a point on new technology without even wanting to understand abt the challenge as a PO. Hides the PO's incapability and says it's very simple at the end when the team member delivers it.

9. Finally, don't even say a word or say a thank you note or a simple email or a quick 5 mins meeting to convene and acknowledge the developers who worked really hard for years for the team. This is the basic and not ought to be taught though. Oversee everything with an egoistic mindset. 

Fortunately, our team is able to deliver the product with individual team members' capability and knowledge. In the end, not even a single team member felt the use of SM and PO. In fact, all of us honestly considered SM and PO as barriers and burdens hindering progress.

Allen Pereira: 

My Take on this:

------------------------------------

1.  Firstly, I would request both the TL & PM to back off from making personal comments and maintain the decorum of office culture & work environment.

2.  I would humbly request both of them to leave the room at that moment and meet both of them individually to sort this out amicably.

3.  Will talk to TL individually and tell him that:

·       No matter, he is very well experienced and correct but he has to ensure that stakeholders' requirements are met as per their requirements.

·       Dev TL has to give the PM an approx. the timeline that is required by his Dev team for any change requirements.

·       Also, TL has to tell in a clear manner that though frequent changes are not welcomed but expected there has to be a certain limit with regards to the baseline code/ structural changes, cosmetic changes, additional requirements, etc. 

·       TL has to put his foot down at times so that PM knows that not every time and every change will be possible in the given budget & timeline.

4.  Will talk to PM individually and tell him that he needs to:

o   Maintain calm and patience with the Dev TL to ensure work relations are not spoilt or affected. 

o   Learn the tricks of the trader faster than expected.

o   He has to rationalize with the stakeholders so that not every time the requirement keeps changing and also not drastically. 

o   PM needs to inform the stakeholders to maintain certain control with regard to change requirements, especially at such a delayed point of time when the team has completed most of the important work.

    5. Finally will meet both the TL and PM together and tell them that:

o   No matter what happens, Project & work comes above everything including personal ego & attitude/behavior.

o   b. Will tell TL that the PM will try to be firm with stakeholders as much as possible to ensure the changes are controlled and that there is enough time for rework.

o   c. Will tell PM that the TL will ensure to deliver as many change requirements from stakeholders as possible up to a certain extent. Also if possible, protocols will be released first to check if stakeholders need any further changes.

Swati Shukla: This kind of happens commonly. As a scrum master, I'd interrupt their verbal war before it blows out of proportion. I'd remind them it's not productive by having this discussion. Would instead steer the conversation toward what actions we can take in the present scenario. 

For eg. Facilitate meetings between Vinodh, Deepak & leadership to understand exact expectations. And clarify that team can only deliver the work as per priority & capacity. Once this msg is clear on both sides, Vinodh will b able to stabilize the backlog and Deepak too would be in agreement with the prioritized work.

Rahul Baji: The 3rd Agile value says "Customer collaboration over contract negotiation". If we stifle agility, I am unsure if this is aligned with the basic principles.  Satisha has reminded us time and again that we are here to serve the customer.  If Vinod brings a new feature every time, then every time there needs to be a genuine cost-benefit analysis of doing the new feature vs dropping the current work.  I was an SM who would, in fact, sit with the entire team and do the cost-benefit analysis.  There is the cost of the work not done. There is a switching cost to picking up new work. There is a benefit to adding a new feature to Sprint. We may not be able to complete the new feature because of a dependency.  So the more the team ( and Vinod the PO) get used to this cost-benefit analysis ensuring we are serving the customers, the more such disagreements will reduce and the team will get aligned to customer-delight.

I think we have all worked for service-based companies at the start of our careers. There all that mattered was billable or not billable.  Customer success was never aligned with the service company's interest.  A product organization is different.  The development team is not an outsourced provider like a service company is. Hence what we develop is as important as how we develop. Unfortunately, our history has sullied our perspective into believing the service mindset is the correct mindset.  But that is true in the service company context. Scrum is essentially for product companies where the development teams care about making a difference to the customer by providing value.  Not just complaining over changing requirements.

All logic about the impact on velocity and productivity is based on the idea of measuring output. But we need to learn to drop measuring output ( used by service companies for billing because they were never aligned to customer business outcomes) and start measuring outcomes.

Rajesh Kamat: The role of the SM as an agile Coach for Vinodh as PO starts from the day he joined as PO for this team. What it means is that his role should be effective in a way that this situation is not reached. Every member joins in, no matter how much experience he or she brings in needs mentoring and this is where the SM role is crucial. Since it’s happening 5th time in a relatively shorter period, it does raises a bit of concern. Better late than never, the SM here will need to facilitate an open discussion with Vinodh, understand the pressure from stakeholders, and coach him on how he can negotiate the scheduling of the new Pbis that are coming through. At the same time, he needs to bring forward the cost that is incurred over the effectiveness of the team and the overall value of the product if such cases are happening frequently and consistently.  Customer requirements are ever-changing and had to be absorbed but that needs to be assisted with negotiations, explorations, and appropriate scheduling. 

Sandil Shah: As a scrum master, I will request Vinodh to take Deepak in a discussion/meeting with stakeholders to understand the business need. As he is a tech guy, he can understand the criticality of new needs/feature requests. He can better explain the impact of adding them in the middle of the sprint to current sprint goals. He can help Vinodh & stakeholders to sequence the activities based on dependency. If something is a must needed from a business aspect, Vinodh can make stakeholders understand and ask for priority between existing work v/s new work. As SM I will always encourage both Vinodh and Deepak to work as a team, work collaboratively, and have utmost transparency on what is needed v/s what is feasible in what timeline. That way we can reach some common conclusion and win/win situation for all i.e. stakeholders, PO, and team. In all situations, it is very much essential for the PO, SM, and tech lead to ensure maximum transparency for the team on what to pick and manage the PB in order of priority.

"We upskill and boost your career by providing a wide range of courses such as CSPO, CSM, ICP-ACC, etc. visit our website to learn more about all the courses we offer."