I have run into several teams who tell me that they no longer run iteration retrospectives: they were a waste of time and they weren't learning anything new. What is your answer to these teams? Should they just let go of the need to have retrospectives? If not, how do you convince them of the value of the retrospective?


2 Answers 2


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".

  • You don't mention lack of trust, lack of safety, hence lack of interest in retrospection. Imagine that the 5 whys expose this situation. What do you recommend to create enough trust to re-engage retrospection. I guess I'll also ask: perhaps retrospection is asking for too much introspection and that THAT is the real issue. May 22, 2011 at 23:11
  • Good point, added a response to assist. May 24, 2011 at 10:15
  • I've found a good way to combat ceremony monotony and a lack of interesting variation is to have a different team member run the retro each sprint. Sometimes they go very well and sometimes they don't totally work but they are almost always different. Half the time, the person introduces the retro saying, "we're going to do something similar to what we always do", and it ends up completely new and interesting.
    – chrishomer
    Aug 5, 2011 at 5:49

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.

  • I'd alter this answer a little though I think it gets close to answering my question. I agree: a retrospective that doesn't produce action is ultimately not a retrospective. Our reflection about our interactions and work should inform us about our working agreements, our deepest challenges, and our organizational blocks. Those revelations should create SOME action of SOME sort. WRT offering my own ideas up front, I would discourage that. I saw a team where the team lead (Scrum Master) tended to just take over suggestions and decisions. It ultimately shut the team down entirely. Jun 6, 2011 at 17:18

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.