"Dead horse" topics banned at sprint retrospectives, is this good practice - why or why not?

Question

I'm asking as a member of an Agile (Scrum) team, not as the PM/PO/Scrum Master.

On this project there are a handful of well-known impediments / problems / things that didn't go well, which are a recurring theme in every Sprint.

We are developing software but I didn't want to go into all the details, so, an anonymous-ish example from a house renovation project could be:

Client can't make a decision what layout they want for the kitchen until they receive the samples from the 3rd party supplier, but the 3rd party supplier keeps delaying it for unknown [to us] reasons. (They can't get a different supplier because of "whatever reasons") So we can't start building the cabinets because we don't have the layout.

That's just a made up example but it's the sort of 'impediment' I mean.

I see them in my head as "dead horse" topics (as in 'beating a dead horse'). Although we have tried to solve or mitigate them, they aren't really under our control.

It's accepted by the team that we can't resolve them at this point, but they are still hurting our productivity in each Sprint. (e.g. couldn't make any progress on building the cabinets, as the client still hasn't been able to specify what layout they want. We wasted a lot of time mocking up design ideas without any real idea what they wanted, but they rejected the designs.).

So now in each Retro (we have 2-week sprints, so every 2 weeks) we go through what went well, what could have been better, etc. People were calling out these "dead horse" topics in each and every Retro as they were genuine impediments or things that didn't go well. Generally met with a collective eye roll or groan like an unspoken "yeah, that's pretty much the main thing thats gone wrong and it's quite fundamental but what can you do!"

As a result "dead horse" topics have now been ruled out from discussion in retros, and we aren't allowed to bring up those subjects (e.g. no layout requirements due to the 3rd party dragging their feet) as part of "what went badly" discussions. But I feel like it's a bit of an 'elephant in the room' - (sorry for all the animal metaphors!)

Questions,

Is this a standard or good practice in facilitating a retro to 'censor' known issues like this? So that they don't just keep coming up over and over when no one can do anything about them?

If this isn't the standard approach, how should the subject of "known 'dead horse' issues that were a problem but we know we can't resolve" be addressed?

Answer 1

Is this a standard or good practice in facilitating a retro to 'censor' known issues like this?

Yes and no. I feel it's wrong to censor anything, especially talking about impediments at a retrospective. On the other hand, discussing the whole issue again and again and again when nothing has changed is unproductive and wasteful.

As an example: in my old team, the office building had no A/C. Since the building was rented and the landlord bankrupt, the landlord would not invest in AC and the company did not want to invest at all in a building they did not own.

So there was no A/C and it was hot. But there was nothing that could be changed. We reported it, sprint after sprint as an impediment and a drag on production. But that#s all we could do.

But since nothing changed since last sprint, there was no point in discussing it every time. We put it on our stickers, we reported it upwards and that's it. Then we went on to discuss and spent time on topics we could change.

So to summarize: it's never ok to censor, but it's a good practice to accept what you cannot change and start to change the things you can, without beating the dead horse.

Answer 2

The Scrum team alone cannot solve every impediment. It is a good idea to have some kind of escalation path for issues that are outside of the control of the team, but are recurring and damaging.

As a Scrum Master I would often look to escalate this kind of issue using a reporting process.

For example, I might produce a sprint report that says something like:

We noted in our retrospective this sprint that there is a recurring issue with the 3rd party supplier that is negatively impacting on the team. We believe this may reduce the productivity of the team by as much as 10% due to the impact of waiting times and delayed starts.

You may find that once you regularly highlight a productivity impact that you get the attention of your management.

I would also consider an information radiator approach to this kind of issue. For example I might put up a list of the team's 'top three recurring issues' on the wall in a public area of the office.

This approach can be particularly powerful if the same issues are being reported by several Scrum teams.

Answer 3

A retrospective should not ban topics. And a retrospective must not waste people's time, either.

With that said, what you could do is categorise the retrospective items according to different influence categories:

• Items the team can change
• Items the team can influence
• Everything else / Items the team needs to accept

Once you have done that, the team should focus the retro on the items the team have more control and less on the items out of control. With time, people will naturally raise items based on the level of influence the team may have instead of keep beating dead horses.

There's a plethora of examples of Circles of Influence around the internet, below I picked one from https://www.innovationgames.com/circles-and-soup/ as it also offers a way of looking at this as a game for the retro.

A last note - sometimes the borderline between "influence" and "accept" is very thin and depends on SM skills. If that's the case, BenLinders suggestion may be a good approach (i.e. have a specific meeting to break the problem down).

Answer 4

Censoring an impediment from the retrospective doesn't solve it. As it looks to be a major impediment that's blocking the team, maybe it's worthwhile to arrange a separate meeting to analyze the problem to get a shared understanding and find a way out of the impediment?

The advantages of planning a specific meeting are:

• You can focus on the impediment and give it the attention it needs. It's more effective.
• You can choose a specific technique to truly analyze it (like 5 times why, value stream mapping, etc).
• In your retrospective, there will be room to address other important things. Learning and improvement don't have to stop due to one big issue.
• As a team, it's a great opportunity to practice problem-solving skills.
• Since it's a separate meeting you can choose who needs to attend. It's isn't necessary that the whole team attends this meeting, and it could help to invite people outside the team that may have insights or can help you solve it.

Would something like this work for you?

Answer 5

If the same impediment is being raised Sprint after Sprint, that brings up a few questions.

Is someone actively working on resolving the impediment? Maybe it can't be resolved within the Scrum Team and maybe it can't be resolved in a Sprint, but what is being done to minimize its impact and ultimately resolve the underlying issues?

During Sprint Planning, are people aware of these impediments, and if they are, why is work that is likely to be impeded being brought into the Sprint? If the work is so high value that it truly is the next work that should be done, then maybe more effort or resources need to be dedicated to handling the impediment. Otherwise, maybe the work needs to be deferred - started but unfinished work is waste, so why would you knowingly introduce waste into your development process?

It seems wrong to bar certain topics from being discussed. But it's also wrong to not be working to resolving these impediments and wrong to knowingly add work that will be impeded.