Agile: in a sprint retro can I bring up a negative which isn't affecting me personally but I know another team member has a problem with it?

Question

I've been working in a particular Agile/Scrum team for about 5 months now, and I am conscious of a specific concern (that's been mentioned to me in private) for a few weeks, from 2 different team members (out of 8). The concern doesn't affect me directly but I recognise that it does affect those team members and it is legitimate, not just a "gripe".

In our last few retro's (where we "anonymously" add things to a board along the theme of "Things that went well" / "Things that didn't go well" or whatever) these concerns haven't been added to the board. I think they are either conflict avoidant (understandable) or think it won't make a difference as it is just "talk for the sake of it" or similar.

I didn't pursue the people but they have independently told me that they have concern X and Y (which are genuine problems). And they don't want to raise it because of thinking the others will lambast them for it, or they won't be perceived as team players any more, or similar.

Could, or should, I raise concern X and Y on our next retro? If they are not things that personally affect me, but I am aware of them as things affecting "the team".

I could speak about why I added them, if asked.

Answer 1

I don't see any problems with raising concerns that you are aware of yet don't directly impact you. There may be ramifications to your relationship with coworkers if they see that as breaking some level of trust with you, but there's nothing from the process side that would prevent someone from raising a concern or issue on behalf of someone else.

The larger concern, though, is why the individuals don't feel comfortable raising the issue on their own. The retrospective, and really all cases of team interactions, should be open and honest. Everyone should feel comfortable raising concerns that they have. If something is preventing people from raising a concern, there may be any number of other concerns that people have that you aren't aware of and aren't being discussed. This can be an impediment to a true culture of continuous improvement.

Answer 2

I agree. These people are asking you – privately – to speak for them anonymously, and you also feel that it is an issue worth raising. Therefore, after carefully considering (perhaps, with them) exactly what is the issue and what might be done about it, I would recommend that you do raise the issue "as though it were yours."

Now, you also have a separate issue: that some members of the team don't feel that they can speak freely. That they will be "lambasted." Sometimes, teams need to be gently reminded that (so to speak) "the only thing that actually matters here is the football." Everyone keep your eyes on the ball ... the ball ... the ball.

Answer 3

In my experience a retrospective meeting is a meeting where the team comes together in an informal setting to discuss how the team is working and what changes are needed for the team to improve, this can be on working together or independently.

Examples that happened at the company I work for are: "not having the product owner on the planning meeting explaining the stories was detriment for a good estimate of the effort", or "Instead of learning to install and deploy LDAP, we could use the sign in of the SQL database as authentication for the application saving time and money for the project"

The truth is that this meetings are not used as it is intended to help the team, or the team dont trust each other and don't accept criticism for improvement, I saw plenty of this as well.

the Scrum master should emphasize the Agile Prime Directive as stated by Norm Kerth, this is a way to allow trust that no one will be ridiculed or bashed for what they say:

"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." --Norm Kerth, Project Retrospectives: A Handbook for Team Review

But for the best answer for your question, talk with the people that has the issues, see if they want to talk in private with the Scrum master since he is the one that should be helping to resolve anything that blacks the development team to be productive and approach the Scrum master privately to discuss the issue.

Issues can and should be discussed with the Scrum master or any other supervisor at any time and not only on retrospective meetings.

Answer 4

Don't raise it as a problem, instead raise it as a possible improvement.

A lot of the discomfort in retrospectives comes about when there is a focus on identifying issues. This can result in blame or embarrassment for team members. I recommend you carefully shift the focus away from identifying issues and make it more about ways the team can get better. This will help the team to be more relaxed in the retrospective and to enjoy the process.

For example, instead of:

Some team members have introduced production defects this sprint

You could instead write:

Should we experiment with more test automation and pair programming to improve our quality?

Answer 5

The short answer is YES, you should.

The long answer is:

The purpose of the retrospective meeting is to improve the team in any way (processes, communication, etc.) This is usually done in the following way:

• by stating what the team is doing well, so they can continue to do it
• by stating what the team is doing wrong, so they can stop doing it
• by stating how the team can improve itself

This is not mandatory. It is just a recommendation that most people follow.

If you think addressing the issue (that your 2 teammates have told you about) will help improve the team in any way, then you should raise it during your next retro. Here are some tips to maximize your chances of actually convincing your team to take this issue into account:

• present it in a polite way
• explain why it is a problem
• state that team members might benefit from solving this issues
• mention that solving it does not require a lot of effort (if this actually is the case)
• come up with an actual solution to the problem (don't just whine about it)
• if the team accepts that this is problem that needs to be addressed, make sure that by the end of the meeting, someone is designated to make sure this issue is solved. Otherwise, it will just be left hanging.

I also have some comments regarding the fact that your colleagues told you about this issue instead of raising it during the retro.

This usually means that are not comfortable in the team. My guess is they don't get along with the other team members or they're somewhat afraid of your boss.

It's ok to do this for them now, but you should encourage them do speak their minds in the future. They're adults, not children. It's ok to give them a push in the beginning, but if they can't stand up for themselves, what are they going to do if you leave the team/company?

Also, make sure you're going to be backed up during the retro by these 2 colleagues that told you about this problem. That's the least they could do. Otherwise, you risk making a fool of yourself in trying to solve someone else's problem.

Hope this helps!

Answer 6

the answer is: maybe.

In an old Team, the PO and I had personal problems for months. On a retro day, we clashed again, in a bad way. Cant remember what it was about that day. The Team thought we should talk about it, but neither the PO nor I where in the mood for talking about it. Being forced to talk about just made it worse. During that retro, the PO said: He cant give me what I expect, and I shall switch to another team.

Instead of switching to another team within the company, I switched the company! Great decision for me personally, definitely not the outcome my team wanted. That problem needed adressing, but sometimes a retro is not the right place, especially when there are personal issues at play.

So ask the team members if it is ok when you bring it up for them. Also ask, what's the underlying issue that prevents them from speaking up. Why dont they dare to do so themselves? With this information, you can form a better decision.

Answer 7

Does the issue impact the project in any way? That should essentially guide you. If it impacts, bring it up by all means. The very fact that people are discussing it privately with each other means that they are also concerned on the impact.

Answer 8

Well... Some team members can take some of the retro issues as bad criticism (I really don't think they should and personally I think it is unprofessional, but it happens), and sometimes losing motivation or co-operation after bringing the issue to the table is worth less than "living with the problem". So it's kind of a "trade off" you should consider.

If that issue affects the team in a way that the team feels uncomfortable or the efficiency of members is disrupted, or affects the project in a way that they make something wrong or will lower the quality of the product - I would bring it up anyways, for the sake of the team and the project. This is exactly what that meeting is for.

However, if it is just a behavior or a person's method of working that sometimes getting into your way (without harming your work) or you think they could do better - in that case, if I would care enough, I will bring it up to my teammate personally as a recommendation.

Do not ignore issues that can harm the product's quality, make the whole team uncomfortable to work with each other or can get the team a bad reputation.