3

A developer has repeatedly shown an unwillingness to co-operate with the team in a few ways: being passive aggressive, sometimes not creating stories/tasks for the work he is actively doing, pessimistic and arguing about the way we point stories. This problem has been going on for months.

He tends to over-engineer things. This developer is overall a nice guy. He is a strong, intelligent developer and a hard worker.

IME, it's best to focus on the issues and not the people. I'm struggling with finding ways to point out the issues in this case without pointing at the person. I am the scrum master. I've been approached by another person on the team about at least some of these issues. Should I discuss these issues in retrospective or just pull the person aside and try to work it out between the two of us?

Improve this question
2
  • 1
    Ask this guy how he would improve the estimation process. Ask him how he'd do things differently in general. You might find out that this guy just wants to take off the Agile training wheels and experiment with the process a bit. Of course, you're equally likely to just find out that he's a jerk. The point is, an open and honest conversation in a safe environment is in order.
    – RubberDuck
    Commented Aug 8, 2016 at 1:34
  • I won't put it as an answer but also considering having this person moved from the project. The truth is that 1. Some individuals are uncoachable (that's life) and 2. Most Scrum team do not survive with all members intact. If individuals do not have growth mindsets and refuse to engage then simply take action. Remember that the goal is self-organizing NOT self-managing. The dev does not get to decide to simply not do Scrum. wengu.tartarie.com/wg/wengu.php?l=Sunzi
    – Venture2099
    Commented Aug 16, 2016 at 15:44

6 Answers 6

Reset to default
5

I'm sorry to see that this has been going on for months. Did it ever come up in the retrospective? During stand-ups? Since it seems to be hampering the team I would have expected that one or more team members had raised it in a retrospective. Then that would have been the first spot to discuss it.

How do other team members feel about how this developer behaved? How do they react to it? Reason for asking this is that I prefer to solve it with the team together, and not in a one-on-one. It's not an issue between you and him, it's a team working problem. Even though it has been ongoing too long I'd prefer to take it at team level first. But that should happen now, this has been ongoing too long.

My suggestion is to pay attention how the team reacts on him, and use their reaction to discuss the matter. Signal the issue when this happens in a stand-up, planning, or any other opportunity and then agree with the team on how to take it up (a short retrospective sounds suitable). If you want to do it in a retrospective, then some of the exercises that you can use are a one-word retrospective or a perfection game.

Note that since that has been going on too long you need to deal with the damage and the feelings that have build up over time.

Also you may want to look back why this hasn't popped up in the retrospective, learn from that, and find a way to deal with similar problems quickly in the future.

Improve this answer
5

Go with Mantra:

"Praise in public. Criticize in private"

In retrospection, concentrate on processes rather than individuals.

Improve this answer
4

This is a tricky situation for a Scrum Master.

Ideally you want the team to resolve it themselves. They should recognise the problem, self-organise and work out a better way of working together.

To help facilitate this you can make the effects of the developer's actions more visible. For example, you could point out the length of planning meetings and ask if the team thinks there are ways of speeding up the way you allocate points to stories. Or you might mention the impact that unplanned work has had on the sprint goals.

It's not about naming names. It's all about emphasising problems that the team faces so that they realise they need to fix them.

Improve this answer
3

The retrospective is about making the team better - getting the team to identify what went well, what didn't, and how to do things better.

It may be tempting to point out this individual in a retrospective as "something that isn't going well", but even if it doesn't devolve to bullying, it is going to end up creating resentment in that individual.

Get this developer into a one-on-one - and without getting confrontational, ask him why he is working the way he is. Work with him to try and get a resolution.

However, be prepared to lose this guy - if you have a successful development team that is mostly working well with the process, having someone cowboy their way along is going to end up causing problems for the whole team. No developer is talented enough to offset a good team.

Improve this answer
1

I would suggest you to find the outcome of this behavior. You need facts.

Does it bring the team's velocity down? By how much?

How much time has he been working on "invisible" tasks?

Did other developers leave the team because of it? How many?

Did the over engineering cause bugs or delays? How much?

And if you want to talk about it in retrospective, talk with him first and warn him that you're about to bring the subject with the team.

Improve this answer
1

Another approach is use Sailors & Anchors ... and see what happens ... I believe in your scenario it will work very well ...

Basically Sailors will be the the things that help you sail through the sprint and Anchors will be the blockers .

This is a bit modified form of http://www.innovationgames.com/speed-boat/ taken from Innovation games.

Hope it helps.

Improve this answer
4
  • Could you provide a summary of "sailors and anchors", and why you think it will work well?
    – MCW
    Commented Aug 15, 2016 at 16:31
  • Please include that in the answer and if you can, provide citations. I did some google searching and couldn't find any reference to "sailors and anchors" in the context of project management.
    – MCW
    Commented Aug 16, 2016 at 12:56
  • Updated the answer .. i think you don't agree..
    – user666
    Commented Aug 16, 2016 at 13:07
  • Much better - thanks~
    – MCW
    Commented Aug 16, 2016 at 14:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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