13

I'm a Scrum Master in a project. The development team was merged from two separate teams and now counts 8 people. John and Peter are previous teams leads - very experienced C++ developers, who know the business domain and the product very well.

The issue is that those two are just like cat and dog. They clash daily. Mainly due to different technical opinions. Like we should/should not use this pattern across the application, code style etc. They do their best to keep the communication professional, but I see it becomes harder every new day.

So, the Scrum self-regulated team does not happen. Nobody comes to me and says "We need to get rid of John, as he is the troublemaker". And frankly I also doubt who the troublemaker is. Each one separately is technically good and able to lead the team. They just do not cooperate at all.

Needless to say, that the rest of the team is frustrated. Some guys support one or another side, others try to remain neutral. As we plan to release quite soon, removing one (or both) is not really an option for the project sponsor.

What I do now is primarily serve as a mediator between the two. Holding endless meetings, listening to the points, facilitating agreements and so on. This takes vast amount of time and decreases level of hate for couple of days till next conflict arises.

What else can I do with conflicting team members?

19

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 productivness
  • 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.

  • 2
    Great answer, thank you. The personal timeline excercise looks very promising. I guess the number of wine bottles will drastically impact the timeline detalization :) – Vadim Tikanov Nov 27 '14 at 10:05
  • 1
    Regarding the conflict. What you suggest (enforcing decisions, replacing people) is beyond Scrum Master responsibilities. However, we're at the point where the Scrum just does not work (yet). So I'm going beyond SM role to PM role, directly managing the issue. – Vadim Tikanov Nov 27 '14 at 10:15
  • @VadimTikanov - Good luck. Please let us know how it goes. – Venture2099 Nov 27 '14 at 13:30
  • 1
    This answer is extremely useful, beside having sometimes conflicts within the team, the personal timeline seems very useful for other cases I have with team members that indicate loyalty but might have personal issues. Love it ! – Ian Segers Dec 13 '14 at 15:49
0

Maybe it is too late to contribute this topic but I hope it may help somebody, somehow.

You didn't have to loose one of your developers, it was not necessary.

A good coach could solve these kind of conflicts for all of their's good: conflict management!

The problem was not two that developer were "bad" people; they were different and they were in need of to be heard and concerned. There might be a solution which might satisfy everybody, however, it required a different approach, which is "collaboration".

Every person in a team wants to be considered and taking into account.

If the coach has had approached the situation to solve this concern, the result might have been different.

The key point is that: the solution might satisfy everyone's concerns; John, Peter and the Team!

This is not "compromising", this is "collaboration".

The two developer might be responded differently if the question was this: "Yes, I understand your point and I respect that, AND I need you to consider my point and the team's point..."

So, there might have been more than 2 points, maybe 4 or 5. And it was possible to find a solution which fully satisfies every concern...

This is called "conflict management" and it requires a lot of knowledge and experience...

Regards,

Emin

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.