What are you doing with Agile teams who no longer run retrospectives?

This is a great case to try out the "5 Why's" mentality and dig into the root cause of their previously useless retrospectives. The times I've dug in to dead and dying retrospectives, the reasons tend to fall into a few different categories.

Failure to act

Too many retrospectives end up as bitch sessions, with no real outputs coming from the event. If a team doesn't exit having committed itself to actions as strongly as it makes its sprint commitments, it's not making progress. I wrote on this here.

No longer having fun

If the team's not enjoying itself, it's hard to create the safety and energy needed for effective retrospectives. Shameless self-promotion: Ken and I are talking about this at Agile 2011.

ScrumMaster visibly doesn't care about ceremony

The ScrumMaster is often a leadership figure on the team, and a visible lack of caring from that one individual can easily poison the entire team against the retrospective. This can then pervade the organization, leading to anemic or non-existant retrospectives.

Failure to close the loop

Implied by @Rob above, there needs to be a visible evidence of progress from the retrospective outputs. I prefer doing a brief "Sprint retrospective review/demo" at the beginning of each retrospective, where the team will reflect on their action commitments from the previous sprint and how effective they were. Essentially, this is putting the 'C' and 'A' on to PDCA.

Ceremony becomes forced

I've observed ScrumMasters that go around the room and ask each person for a plus, a delta, and an appreciation. The overall effect felt somewhat like kindergarden, and a small piece of the team's soul was dying with each progressive request.

Approach no longer creates variation

Teams that do plus/delta sprint after sprint will eventually find that lens to be ineffective at discovering new improvements. They need to try a new format of some sort, and there were a few suggestions here.

Lack of Trust and Safety

Responding to Jean's comment (Thank you, Jean!), I'll add lack of trust as its own point. There are cases where management behaviors and team dynamics have conspired to create an environment that is toxic to retrospectives. In many cases, I find these are the results of other causes, not a cause in and of themselves, but there are occasional situations that are truly dysfunctional on the trust side. These cases are often the result of politics in the organization, especially where vendors & contractors are involved and creating the need for an "aura of perfection".

It sounds like you have a larger problem in that you aren't getting the right things out of the retrospectives. Pushing them to run retrospectives isn't going to help, providing a real reason to do them will.

• Do you have metrics you can collect to show the imprvoement made by the retrospective? Number of features implemented, number blockers encountered ... somthing. If you have a graph that is trending the right direction, then they can't help but see the benefit.
• Do you ensure the feedback is address from the retrospectives? I would be fed up if 5 times in a row I said "we need to do x" and nothing ever happened as a result ... conversely if I said "this thing sucked" and a sprint later we were doing something different ... then I would look for other things that sucked as well.

So my answer to the teams would be "OK, so the current methodology sucks, fine, how can we improve it? here are some ideas, what would you like to see coming out".

I would also qualify it by saying done properly the retrospectives can help all of us do better in our jobs, help us learn more and help us keep our jobs against the competition who is continually improving against us.

Actually for developers I would say that retrospectives help us improve which means we can give you nore work you enjoy doing rather than having to constantly fix stuff that is broken and chase your tail around.