Should I mention that the team culture is toxic at a retrospective?

Question

At my work, I've started helping out another technical team. I've been to a couple of standups now and my first impression is that the relationship between the business area and technical team is completely broken.

Every standup has been very tense and involves the business person drilling each member of the technical team and making lots of passive-aggressive comments. It can be a bit of a gray line, but from what I've witnessed, it kind of borders on bullying. To the point, I've actually had to ask one member after one standup if they were actually okay and they were pretty upset.

I've talked to each of the member of the technical team and it sounds like this has been happening for the length of the project. It feels that the business area does not trust the IT team at all and there's a lack of understanding of what IT does and how long and expensive things can take to implement.

I'm not saying that anything said is without merit either. There are definitely things that could be improved. Nevertheless, the relationship as it is is counter-productive, bad for morale and you can't really improve the processes of a team in this environment.

As an outsider, I feel there's an opportunity to try to reset this relationship. I'm thinking of raising these issues at the retrospective. However, I'm scared it might be a little too confrontational. Plus, a lot of these issues are probably symptoms of larger problems in the project which I don't know the context of and will probably take longer than one retrospective session to solve.

I know the retrospective is supposed to be a safe space to voice any concerns and suggestions for improvements, but would the issue of a toxic work environment be too big of an issue to raise?

Answer 1

You should absolutely address it, and I wouldn't refer to it as toxic culture necessarily (I agree with @GregoryCurrie that just bringing up toxic environment in a retro is something for a private manager discussion). I would recommend you discuss a few actions that are toxic and referring to them as negative behaviors impacting the interoperation of the team. You should be able to define it for the team and identify why it's causing such a problem for you and for the team. I would recommend having a few ideas on how to eliminate it.

The problem in referring to it as toxicity is that it is a "blaming" language. People who are behaving in a toxic manner are going to get offended and shut down. By addressing the behaviors, it begins to change the habits of the team. It's easier to have concrete examples of behaviors and instances, and saying something to someone that they did one thing that negatively affected you is much easier to stomach than statements that suggest an "always" state.

It's also helpful if you go into it as part of the problem yourself. People feel less accused if you are able to call the behavior out in yourself. They're also more likely to join you in correcting the behavior because now they have a partner in the solution rather than someone judging them.

The retro needs to remain a safe place, and that means not just blatantly accusing people. It means taking the people out of the problem and addressing that. The person isn't bad, the behavior is bad.

Answer 2

Joel already wrote a pretty good answer and I have to agree with him on the general direction and outcome. I would like to give you another reason why it is the correct course of action.

Any problems in the team should be brought up in the retrospective. Only if they cannot be solved there, the team should decide to involve someone else, like a manager.

But you have to make sure that what you bring up is actionable. Your problem only goes away if you can come out of the meeting with a set of actions that solves the problem.

"The team culture is toxic" is nothing actionable. It's unspecific and opinionated. Some will say yes, some will say no and then you are back in kindergarden. Without any changes in the future or positive outcome.

You didn't really give any examples, so I will have to make one up: lets say the business people ask you about your project status multiple times like they don't believe you. Maybe because they actually don't.

When we are in our status meetings, I have to repeat myself multiple times. I feel like you either ignore what I said or you don't believe what I said. I would like for us to find a way that I only have to say it once.

Now, this is not an opinion. You either have to repeat yourself, or not. Anybody can be present and witness that. On the other hand, the business people may have good reasons to ask you very detailed questions like "did you test it", "did you deploy it to QA", "did you push your changes". Probably because in the past, they just believed it when people say "it's done" and then it wasn't.

So now you have an actual, factual example of behaviour you would like to change and you have asked how to change it in a constructive way. You can now go on and discuss actions.

For this made up example the action might be to have a list of questions ("definition of done" of you do Scrum) that has to be answered for any item to be considered done. When your turn comes to go over the status of an item, and it's done, just go through this list and confirm every bullet point. "I did the coding, Alice did the code review, we deployed to DEV and Bob tested it. Charlie deployed it to QA just an hour ago, you can inspect it there if you want to. It's done." Or maybe you find another solution.

But take it one step at a time. Pick a factual thing and improve it with actions. Grand sweeping statements without any real content, like "this is all toxic", will get you nowhere.

Answer 3

The best improvements to discuss at retrospective are ones which are actionable

The most satisfying retrospectives are ones where the team decides to do something with differently, and begins implementing the change right away.

The problem with discussing things that are "toxic" is that "toxic" is a word that basically means "this is something I feel is bad and I don't like." It's hard for a team to implement a change to your emotional state, because emotional states are inherently subjective.

It is much easier to implement a change to the process your team uses. It is also easier to talk about changes when you state the change in terms of what your process should do; it has the benefit of de-personalizing the discussion greatly.

In your specific case, I would suggest that you discuss the fact that business people are talking at your daily stand up, and suggest a process change to prevent that from happening. Many teams who use Scrum do not allow non-members of the team to speak at stand-up at all, because it gets in the way of what stand up is supposed to be. The stand up is supposed to be for the team to organize itself and solve its own problems, not to give status reports to other people in the organization. Having business people participate makes the meeting less useful for the team.

Note here that, when I state your problem above in the context of the process change, I don't make any commentary at all about how bad the behavior of the guests at the meeting is. It doesn't need to be said, because now we're talking about actionable changes that will be a benefit to the team regardless of how rude your business people are. Even if their rudeness comes up in the discussion that takes place (which it probably will if your retrospective meetings are psychologically safe), you can still have an appropriate conversation about it because you can always just steer everyone back to your proposed process change and away from how Business Bob is A Big Jerk.

Answer 4

Yes, this is a subject which should be brought up. And you as an outsider are in a very good position to mediate here. But resolving conflicts like that still requires delicate handling, and the project retrospective meeting might not be the right place for it.

When you believe that one person is the problem here, then you should first talk to the problem-person in private. Addressing their personal faults in public is the exact same toxic behavior you are accusing them of: You undermine and humiliate them in front of the team. Some people might think that giving them "a taste of their own medicine" might be well-deserved, but it is unlikely to achieve much. Most people will just get defensive or aggressive instead of reflecting and changing their behavior.

A better approach would be to talk to that person in private.

• Use I-Statements to explain the problem: "I have the impression that the relationship between you and the team is not very good". "I witnessed situations like [example] which might harm team morale".
• Focus on the benefit for the project and for the person you want to change: "I believe that this is doing more harm than good for the project because of [reasons]". "I believe that your job might get easier if [...]"
• Provide solutions: "I made the experience that technical people take criticism much better when [presented like this]".

Answer 5

In principle, you are correct. A retro is the place to discuss endemic issues that affect the development process.

In practice, toxic behavior is not easily rectified. Because if it was, it would generally self-correct itself when people clash with each other in the workplace.

It's not impossible that having a big group conversation swings everyone around to seeing each other's point of view, but in my experience toxic elements tend not to be so open-minded.
For reference, as a consultant I've worked for many clients who needed the extra manpower due to a manpower shortage stemming from a toxic workplace (that they failed to identify and address).

Toxic people tend not to play nicely with others, at least the people they are toxic to. That's arguably why they're toxic.
Generally speaking, it is better to sidestep the toxic elements and instead address this with a party that is not personally part of the toxic culture, is personally affected by any issues the development team suffers (or at least cares about the issue), and is able to exert pressure on the toxic elements.

This could be HR, if the issue is a lack of manpower due to people leaving, or flatout unacceptable behavior such as bullying. This could be sales management, if the toxicity is causing delays and failures to deliver. It could be the CEO, if the toxicity is causing allround issues in the company.

Escalate, escalate, escalate. Be prepared for the toxic elements to flatout lie and claim the problem is the other party. I'm not saying they will definitely lie, I'm saying to be prepared so you have counterproof ready to dismantle their claims.

Never bring up something that you don't already have proof of. Toxic elements who have been able to get away with their behavior tend to be quite skilled at picking apart anything that critiques them and rely on getting the benefit of the doubt; so make sure that your case is ironclad and irrefutably proven. It is better to levy a small but surefire complaint now than it is to make a huge complaint with some bullet points being unsubstantiated or unclear.

If no one who can exert pressure on the toxic elements believe you, is willing to, or is capable of combating the toxic culture, then you're very unlikely to find a solution here. We say "toxic" because it can irreparably poison the environment, and if no one cleans it up, this may end in massive burnout, low productivity, or a mass exodus of developers. Companies have gone under for less.

Answer 6

Assuming the retrospective you are talking about is held with both the business area and the IT team, my first step would be to talk about this with the Scrum Master or the person facilitating that retrospective. Does that person see the same problems as you do? What did they already try? You could even try to talk with other persons of the team in 1-on-1s, but preferably team wide problems are discussed in retrospectives with the whole team.

In the position of the Scrum Master, I would focus on two things:

1. Everyone should feel safe enough to talk about the problem in a constructive manner (not blaming persons, but daring to say what behavior isn't working for them). You could look into working agreements (specifically for the retrospective, see also "Agile Retrospectives" from E. Derby and D. Larsen, page 47), or a Liberating Structure like Heard, Seen, Respected or What I Need From You.
2. If people can talk about it openly in a constructive manner, the next step is to let people talk about it. If only you think a problem is a problem, the group won't fix it. You can of course help with letting the group see the problem, but you can't force them. You could guide them by giving concrete examples of what you think is not going well, and how you would improve that - without blaming whoever did it. For me it works well to empathise with the bad behavior by e.g. showing a vulnerable side of myself where I made the same sort of mistakes in the past. You might want to try Spot the Elephant, Writing the Unspeakable or similar retrospective activities.

Only then you should try to fix it. Let the group themselves come up with proper solutions that they think are both viable and valuable, of course ideally via concrete action points. Fixing this within one sprint/retrospective probably is not feasible, so take your time and let the team take their time. If your observations are correct, they are probably already encountering this problem for a long time, so not fixing it within one sprint shouldn't matter too much.

Answer 7

I think the best way to have a complete solution or solutions, is to

recognize the problem first

. So, I prefer to do root cause analyze the problem as the first step. Because sometimes we face some behaviors that are results of another actions we do not know even the source of it.
So try to know you team, related stakeholders and other parties to find the root cause of the problem.
After finding the root cause or causes, consider the agile manifesto as the base guideline to solve the problem.

Answer 8

I think some of the answers above have a very rosy-coloured view of a retrospective which is hard to get right in the best of circumstances but in an environment like the one described above cannot possibly work. If this is the way that people are treated, a retrospective is not a safe-space.

The problems you are dealing with are far more fundamental and will not be solved by bringing them out in the open in a group setting. That approach will more than likely blow up.

I agree with the other answers that sure it's fine to bring up some concrete issues up in the retrospective and see if they can be addressed or fixed. The response you get to those will already go a long way in telling you whether it's a good idea to broach more fundamental issues there.

What should you do? You'll likely need to work on your relationship with the leadership of both groups and the common leadership you have and bring this issue up with them.

Answer 9

Since we're only being told one side of the story, and issues of bullying are often subjective (it is equally possible that someone could be actually bullying as it is that the other person has a thin skin and needs to learn to take criticism), it's difficult to give an impartial answer to this question. So I'm going to give 2 answers and you can choose whichever one you like:

One possibility is that this is actually bullying. This is not OK. However, as a developer yourself, "team morale" is not really your responsibility, and everyone knows that. If you go to the other team, or their boss, or whoever, and say "my team doesn't like this", then you won't be taken seriously. You need to go up your own chain of command to people in your chain who are responsible for that sort of thing. This will likely be your direct manager, or perhaps their direct manager; you don't have to go too far. If they are not present in the meetings where these issues occur, let them know there are concerns (and what those concerns are, you can repeat what you wrote here), and ask them to be present in the meeting to observe next time. If they are already in the meeting and they know about the issues, raise that these are issues you want handled; it could be that your manager doesn't know these comments are problematic and thinks everything is fine, so make it known that this isn't fine and something needs to get done. At that point, if your manager refuses to do something about it, it might be time to find a new manager. Surely, if the entire development team quits over their treatment by project management, then PM will quickly find themselves in some hot water, as they don't have people to do the tasks; at least now they can say the tasks are being done but not up to specifications, but if everyone just up and quits, they won't even have that. So it's in everyone's best interest to get this problem resolved without losing the whole development team.

Now, it's also possible that the premise of the question is exaggerated. You didn't provide any direct examples of things that were said, but only said that some comments were "passive-aggressive". You also said that some of the comments made do have merit, that mistakes are getting made. Now, since above I defended your position against the PM team, I'm now going to defend the PM team against your accusations, just to be fair. If your work is not up to expectations, you need to work on that. I'm assuming this is not the first meeting the PM team has made complaints; if they have to constantly come to you and constantly complain about the same thing over and over and it never gets fixed, well that builds frustration. It's no excuse to intentionally bully someone, but sometimes things just get said that maybe shouldn't get said or shouldn't get said in the way they are. It's also possible that things get considered "passive-aggressive" when they actually aren't, for example if a bug is pointed out as high-priority, and then it doesn't get fixed, and then it cascades into another bug, then the PM team might say "well, we marked this as high priority for a reason"; to some people that might be "passive-aggressive", to others, not. However, it is a true statement: If you fixed the first bug as high priority, then the cascading bug wouldn't have occurred, and PM team did tell you it was high priority and you dropped the ball, so they kind of have a right to be upset. In this case, you have to rebuild trust between your team and the PM team; PM thinks you're incompetent, and they're more or less saying it to your face. Complaining about it to management, if you take the above advice, isn't going to solve the problem. If you take such an issue to management, they're going to say "PM team is telling you you're incompetent, and based on XYZ metrics we agree with them, so shape up or we'll fire you", and that's if you're lucky and don't just get fired on the spot.

Take a step back, and think about the situation logically: If you remove yourself from the immediate situation of being on one team and biasing your opinion towards your "in-group", do you think it's more likely that PM team is acting belligerently for no reason, or do you believe that your team is dropping the ball repeatedly and giving PM team a reason to be mad at you? Take a minute, reflect on that question, and let that guide your next steps.

Answer 10

I'm going to guess the background to this situation is something like this:

• Your company sells a physical product, like machinery, that's completely unrelated to software development
• Somewhere along the line they realised that they need to get into software development to capture more of the market, so they hired some people to create an IT department and build software for them
• Because the company had zero experience in software and/or because they tried to hire the cheapest developers, the developers they hired were low quality and/or chancers
• Because the company doesn't understand software development, the departments that needed software were allowed to drive and control the development process instead of IT; these departments provided poor, or no, detailed specifications while setting and enforcing arbitrary delivery deadlines
• This resulted in the IT department delivering software that was low quality, which resulted in deadlines being missed, which made the departments requiring said software unhappy, which caused them to lose trust in the IT department
• Conversely, the IT department became less trusting of the other departments because IT lacked autonomy and those departments were happy to blame IT for all software issues - even if those issues stemmed from those departments not doing their part by producing specs, etc.
• Because the above issues were never addressed, the software quality continued to be poor, which continued to erode the trust between IT and the other departments, which has culminated in what you see today: other departments are allowed to micro-manage IT to a ridiculous degree, in an attempt to get software produced that is of acceptable quality

This is not fixable.

The reason is that your company, like so many others, doesn't understand what it is. It is no longer a company that sells physical products; it is a company that produces software that allows it to sell physical products. In other words, IT is not ancillary to your company, but its core. But management doesn't understand, or is unwilling to admit, this. And as long as this is true, IT will continue to be treated as the red-headed stepchild and the relationship between that department and the other departments will never be able to recover.

Even if management did have an epiphany, likely nothing would change. When trust levels are that low, it takes a momentous amount of effort to rebuild them; as in, the wrong people need to be moved to different roles or fired, and the right people need to be hired, given a mandate to shake things up to fix the problem, and actually empowered to enforce that mandate. For most companies this is a bridge far too far.

So, as to your question, no: nothing you can say or do will materially affect how the company is structured and thus how IT is treated. It's only likely to show you up as a tall poppy for management to cut down should you fail to conform to the dysfunctional company dynamic. If you don't like it, your only option is to find another job.