5

Is is right if a team member moans about a 'bad performance' of another team member in retrospective? In my understanding, teams will always look at the team performance, never on a single members performance in scrum.

In the described case, a team member came back after 3 weeks of holidays and said that the 'performance' of a certain project, which is supported by just one other team member, would have been unexpectedly low. No request why this might have been the case, no constructive criticism. The scrum master didn't intervene. IMHO this is against the 'rules' of scrum - for good reasons.

Improve this question
1
  • Obviously there are situations were someone is inept and shouldn't be on the team. When is it appropriate for the team to discuss this?
    – Nathan
    Commented Dec 19, 2015 at 23:43

3 Answers 3

Reset to default
11

Is is right if a team member moans about a 'bad performance' of another team member in retrospective?

No, that's not okay. Most SM's will explicitly call out the rules up front which will include "No personal attacks. Attack issues, not people."

If the person was bringing the issue up that a particular project is under-staffed and thus can't keep up with business/backlog demand, that is a valid issue and something worth discussing. But if it is a play at a particular person "Oh, that project is slow because Bob is working on it" then that's not okay.

Speak to your SM out of session and raise it with them to get their thoughts. Taking aim at a persons performance in a public setting like that could be considered workplace bullying.

Improve this answer
6
  • very good answer. It's important to establish the rules for the retrospective, and those rules to have been formulated by the whole team. Some people advocate having those rules written up and on the wall / flip chart - during the retrospective so everyone is easily made aware of them.
    – G.H
    Commented Dec 9, 2015 at 12:21
  • All this being said, there are still many situations where the root cause of an issue comes down to people (often leaders); even teams with rules and best intentions will find that "endpoint" using things like the 5-Why method. For example, "Why did item X take much longer than our average?" (because it had a lot of bugs), "Why did it have so many bugs?" (because Bob doesn't follow tech practice Y), "Why doesn't Bob do Y?" (because... Bob doesn't really care), "Why doesn't Bob care?" (because he isn't engaged by work)... which then leads to very heavy culture/leadership/hiring discussions. :)
    – Jeff Lindsey
    Commented Dec 9, 2015 at 17:03
  • 1
    Just want to observe that these rules are NOT Scrum rules, and not mentioned in Scrum. They are basic common decency and part of a working agreement.
    – MrHinsh - Martin Hinshelwood
    Commented Dec 9, 2015 at 18:21
  • "Bob doesn't follow tech practice Y" - is there something we can do to make it easier to follow? Maybe automate it? "Bob doesn't really care" - what can we do to help motivate Bob? Perhaps he should work on different bits of the code. Maybe he could do the spikes in the next sprint? Retrospectives are about working together as a team to help overcome individual deficiencies.
    – Barnaby Golden
    Commented Dec 9, 2015 at 18:21
  • @BarnabyGolden Absolutely, I was just pointing out that stopping at "changing what Bob works on", or trying to motivate him can be another form of addressing symptoms rather than root causes. I would definitely not recommend digging deeper in a roomful of peers or retro format, but there is a surprising amount of "because endpoints" out there that are along the lines of "I am simply not engaged by my company's purpose, values, leadership or current direction".
    – Jeff Lindsey
    Commented Dec 10, 2015 at 16:20
4

When team member start complaining or personally attacking other team members, the retrospective facilitator should intervene. This kind of behavior will damage the culture of the retrospective meeting, which is not acceptable.

Feedback in retrospectives can be personal, but it has to be constructive and should be given in a blameless and respectful way. In the example above this was clearly not the case, again that is something that the meeting facilitator should address immediately.

Suggest to find out why the Scrum master did not intervene. Is the Scrum master unaware of the damage that was done? Inexperienced or unsure what to do? Coaching and mentoring might be a suitable solution to ensure that the Scrum master is capable to deal with situations like this.

Improve this answer
1

The Scrum guide says very little about individual Development team member characteristics. One thing it does say is

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment.

This implies that Developers behave professionally and that the whole team is responsible for creating the Increment.

When Developers screw up, they need to know they will be supported by the team rather than ostracized. A Development team must be coached by a Scrum Master to improve the way its Developers interact. It sounds like the Scrum Master would serve the team well to institute the following practice within the Sprint Retrospective:

Retrospective Prime Directive

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Improve this answer

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.