About   Slides   Home  

Managed Chaos
Naresh Jain's Random Thoughts on Software Development and Adventure Sports
RSS Feed
Recent Thoughts
Recent Comments

Retrospectives: Anti-patterns

It is important to understand what a retrospective is and why we need one before we jump into antipatterns.

Based on my experience, I can think of the following antipatterns with regard to retrospectives:

  • Reoccurring problems:
    If you see the same problems repeated over and over again in each retrospective, you might have missed the most important, learning aspect of a retrospective.
    Maintaining a history of previous retrospective can help as the first step. Retrospectives must be seen as a chain rather than a bunch of independent nodes. Capturing the discussion and letting the whole team follow up on the action items can be really help. Avoid one person taking the ownership of the whole retrospective.
  • Retrospectives as a way of reporting to senior management:
    Trying to capture information in retrospectives purely to report to senior management is a big smell. Retrospectives are, by the people, for the people and of the people. The focus is people and the process around them, not the senior management. Certainly, notes from the retrospective can help senior management. But retrospective is not meant for purely that purpose.
  • Dull Retrospectives [Not enough humor and openness]:
    Retrospectives with low energy levels, where the participants sit like rocks, expression less, scare me. Though retrospectives are a serious affair, they must be fun filled, enjoyable learning experience. The team should feel comfortable expressing their opinions. Monotonous format of a retrospective can make retrospectives an event instead of a regular practice.
  • Retrospectives turning into bitch session:
    If all one does during a retrospective is complain, complain and complain, it does not feel right. The team has to brainstorming and coming up with potential solutions to their problems rather than just bitching. One must utilize the retrospectives to do some root cause analysis and come up with action points.
  • Time boxed retrospectives:
    You should let the retrospective run as long as the team wants or have more frequent retrospectives. Retrospectives are important, intense discussions which involve a lot of brainstorming and creative thinking. When I enter a time boxed retrospective, I don‘t feel free to discuss a lot of issues, coz I think they can be very time consuming. So I‘m forced to wait for the volcano of frustration erupts in a wrong place at a wrong time.
  • No action items/resolutions:
    At the end of each retrospective the team must come up with a list of action items. In the coming iteration/sprint, the team makes sure those action items are resolved or discussed further. But not coming up with unanimous action items defeats the purpose of a retrospective.
  • Lack of respect for ground rules:
    Retrospectives have very simple ground rules. If one does not care about these rules, it means to me that they do not care or respect the team members.
  • Retrospectives optional to team members
    Team members skipping retrospectives is a big project smell. Even if someone is not interested/willing to speak, they can still listen to other team member‘s perspectives. The only reason I might not attend a retrospective is, when I have lost hope. And that‘s a big problem.
  • Formal structure for retrospectives
    If the teams are asked to fill out a form at the end of a retrospective, you might just a missed the forest for a tree. Any kind of formalization around self organized events is a big smell. The event losses its essence with formalization.

    Licensed under
Creative Commons License