You are the scrum master of a scrum team that has one developer who disagrees with team decisions

I am dealing with a similar situation; previous teams merged into one with subsequent respecifying of roles and grades. Some legacy political forces were in play.

As the Scrum Master you are the master-servant of the team including coaching. Many agile commentators forget the master part but the business is paying you to impose your will upon the team to make them a productive, cohesive unit. You are not a tea-boy. Reaffirm to yourself that you are in control of team.

In the immediate instance I took the following actions

Commitment to the Team

Sit the entire team down including the warring developers and tell them that from now on the team will finish all discussions with the following mantra

  • Agree and commit
  • Disagree and commit

Either way, the meeting will close with a commitment to the team that an approach will be used and each developer will do their utmost to see the course of action succeed.

Non-commitment will not be tolerated.

When Developer A and B next decide to engage in a lengthy debate about a particular aspect simply tell them that the matter is decided and as a team we (IE you) now expect commitment.

I know some individuals on this forum may take issue with treating developers with such a hard line but in my experience not all team members respond to gentle encouragement to adopt a team spirit. People love change but some hate being changed.

In the longer term you could invest time in

5 Dysfunctions of a Team

The 5 DOAT is a fairly popular framework for producing high-functioning teams. Each dysfunction is, coincidentally, mirrored by the 5 Scrum Values of

  • Commitment
  • Focus
  • Courage
  • Openness
  • Respect

The 5D book is a very short read and a number of different workshops and team building events can be organised around the themes. I have attended two Workshops whereby we implemented the 5D and in each time the team emerged stronger, with more empathy and with a higher output.

To illustrate the differences in the team considering using the personal timeline tool.

Each team member draws up a personal timeline of high points and low points across a horizontal axis of time. It can be as detailed, colourful or personal as you like it.

It requires high levels of courage to be the first presentation which is why the Scrum Master should go first.

In our sessions normally half the team end up crying as people tell the stories of their life that led them to the current team.

Stories of family deaths, heroic war actions, divorces, bankruptcies, abusive husbands followed by educational attainment, spiritual fulfilment, marriages.

The personal timeline over a couple of bottles of wine and pizza was the best team building exercise we ever did to understand everyone's motivations and empathise with them. You will learn which developers fear being a bad father allowing you to prioritise their children's events, which developers were high achievers (harness their ambition), which team members suffered a life-event which impacted their productivity etc...

It may be that Developer A and B both list joining the new team as a low point and by offloading that vital information to the team you see an immediate improvement.

In short you build a tribe that has an inherent loyalty to itself.

Lastly, consider letting one of the developers go.

It does the following

  • Reaffirms who is in control during the forming stage. You.
  • Solves the issue
  • Sends a strong message to the team that you expect team loyalty and productivity
  • Will not tolerate negativity for the sake of old allegiances, it is a new day.

Good luck.

I personally do not believe that any new scrum team survives first contact with the process without losing an individual who refuses to accept the new status quo.

Results

I should also add that my approach, focussing more on the master part, has worked extremely well. We had to let one developer go (the team had lost all confidence in him) but everyone else has gelled and adopted a Scrum mindset.

We have month-long sprints with Planning sessions have decreased from 18 hours in total to lasting less than 6 hours (due to disagree and commit) and our stand-ups went from 41 minutes to 23 minutes on average.

In addition, senior management were happy that the team were under the Scrum Master control rather than a runaway train they were previous. The Product Owner is much happier that the Scrum Master is willing to lead when required and allow Agile principles to guide wherever possible. I am writing a white paper on our experience at present.

For those horrified at my strong line I should also add I took a similarly strong attitude to management, streamlining the amount of meetings, updates and reports the team were scheduled to attend.

I can already envisage a time when I leave the role as I feel the team will be a completely self-managing unit who no longer require a Scrum Master.

Edit in 2021

This answer, whilst highly upvoted, is the answer of a junior Scrum Master on an Agile journey. There is a considerable amount of advice in this answer that I do not agree with any longer and have matured beyond.

The language is unnaturally combative (I had recently left the Armed Forces) and shows a strong misunderstanding of Servant Leadership, even going so far as to use the word Master. It refers to imposing will upon a team which is absolutely not the role of a Project Manager, Delivery Manager, Scrum Master or other equivalent.

Learning to use influence is a sign of business maturity and reflected in the Agile Manifesto.

I have left this answer on Stack Exchange to show that everyone is learning and evolving and we draw upon our experiences. I would not approach a feature team with this attitude any longer and would seek to find a way of working together wherever possible.

However the references and the concept of Disagree and Commit are still strongly encouraged for all.

Last post 11:04 am June 19, 2019 by John McGinty

Hello all,

I have read a very good article from Barry Overeem and agree that Scrum Master can remove a Development Team member when he/she becomes an impediment.

https://www.scrum.org/resources/blog/myth-13-scrum-master-cant-remove-p…

Actually, Mike Cohn said the same thing in the following blog:

https://www.mountaingoatsoftware.com/blog/removing-team-members

However, that is Scrum Master responsibility or Development Team? I mean what is the correct answer for the question "who should remove the team member?"

My answer was Scrum Master but I am not sure if it is correct.

I guess if you guys took PSM I exam, you might see the similar question like "who is responsible to remove Team internal conflicts?

I am pretty sure it should be Development Team!

Can anyone correct me if I am wrong at something? otherwise I am still confusing of 2 answers.

Thanks & Regards,

Khiem

If the team decides, after all that is realistically being tried to solve the issue, the team member is still an impediment and the only workable solution is to remove him/her, the Scrum Master facilitates this. He is than probably going to work with HR and that kind of departments to either find a fitting spot somewhere else in the organisation or find a different challenge for that person.

Is it good for a Scrum Master to have "authority" over anything other than what Scrum means?

One of the stances a Scrum Master may have is that of being an agile coach. I remember Esther Derby and Diana Larsen talking about how it is sometimes necessary to "coach people off the team". That's probably the best way to look at it.

Thank you very much for your all response.

Just to confirm what I understand is correct, the story can be described as follows:

1) At first Team as self-organizing will try to solve the internal conflict with her/him by itself. 

2) After all efforts from Team are failed, (s)he is still an impediment then it is Scrum Master's responsibility to remove her/him (out of the team). Of course, depending on the context, Scrum Master can find his/her own way to help the removal process happen in a nice way.

@ Ian: I cannot find the book or blog you mentioned. Can you please check again?

I don't recall the original context or reference, but the same matter is discussed by them here: https://www.futureworksconsulting.com/perch/resources/pdfs/yourestillneeded.pdf

On one of our past projects, the XP team brought in two team members from other parts of the organization. One very bright, highly experienced programmer contributed good ideas to the team but was unwilling to entertain anyone else’s. The other individual was always “too busy” to pair or attend standup meetings, preferring to stay after hours and work alone on weekends. His desire to appear super-productive hurt the team. Often, his work was full of code smells, and other team members took on extra work to rewrite it. His predilection for overtime provided an object lesson in the value of maintaining a sustainable pace and the downside of the “hero” culture. The manager could see tension escalating as a result of these two individuals’ inability to work as team members, and sat down with them to “coach” them off the team. One left the company; the other relocated to a different department.

There are two elements to the question

1. Who can change the team

2. How can a team be changed

At Cohn's article states the team acts with a container or a system or organization which has formal and informal working practices. On of the practices will be who has the authority to change a team be that a group of people or an individual. The how is the process of that change so there is due process.

In my years of dealing with teams I get two types of individuals that create tension to remove:

1. Lazy/uncooperative

2. Disruptive

The effects of these characters is normally picked up by the SM who would look to improve performance. If it becomes difficult for improvements to be seen then organizational process kicks in due to working rights.

If you get to a position where the team wants to kick someone out then the rules of doing so need to be shared before hand.

Setting up the Team rule before hand is a good practice, then if Team can make decision to kick someone out I think Scrum Master can find a nice way to proceed the process. However, I have seen more situations like Ian described. There are reasons that can impede the Team's decision to remove someone: 

- Team members can complain about someone's behavior and don't want to work with him but still reluctant to agree on a team member separation.

- A team member is a indispensable or doing tasks well in team. Even though he is also disrupting the team's culture, team way of working, team members can accommodate with him. This becomes a tough situation for Scrum Master as managers also doesn't want to replace him due to business reason.

At the end of the day Scrum is based on two things: a functioning team and empirical delivery.

Team members don't have to like each other but they do have to respect eachother so to not work against the goal of the team (looking to display the Scrum values which are rather good). If there is behaviour that is not defined as acceptable they there must be sanctions otherwise you won't have a team. 

If you have a team member that is indispensable that doesn't want to share then you have another problem. Quite simply if the individual doesn't want to be part of the team let them operate out side of the Scrum team. It's better he's outside of the tent. You should also look to cover their skill ASAP as it's an embedded risk.

I hate to say it but it's not about being nice to everyone.