Bob Marshall wrote on his popular blog, that retrospectives make no sense if they are not about a hypothesis – or in other words, if they are not about analyzing why things didn’t go as we envisioned. This was followed with others voicing their agreement (example). While I agree with Bob on many things this time I think he missed the point of retrospectives as such.

Retrospectives for me are not a part of the process of “manufacturing” software per se, as they are not related to the product (software). Their purpose is not testing some pre-formulated hypotheses about the process – their point is discovery leading to self improvement. This discovery is achieved by stepping aside from the process, stopping and taking a look back to reflect on what happened, then considering our present state as a team and finally looking into our future. And key focus here should be us as a group of people – humans – being (experiencing our existence) together: how we related to one another, how we related to those not on the team, how we felt about what we were doing and – lastly – how we were doing it. By discussing this as a group we also develop stronger bonds – retrospectives are an important part of the true team-building process (as opposed to silly, artificial “team building” trips and parties).

Retrospectives – at least the way I treat them – are akin to group therapy sessions for teams. I’m not using this analogy lightly, I think some elements of retrospectives are therapeutic. That’s why I see value in them being led – at least from time to time – by outsiders (coaches). Paradoxically it is easier for groups to open up with the assistance of a stranger, who is not part of teams’ internal dynamics nor local politics.

No matter who leads a retrospective any pre-formulated hypotheses or (worse) outcomes are an impediment to the discovery process. We should approach a retrospective totally open-minded, curious maybe as to what will surface this time.

That is why we should retrospect regularly, using varied techniques to avoid routine and stagnation. Retrospecting only when there is a hypothesis to test (as a lady from Target Processes said they do) is, in my humble opinion, a suboptimal practice – it is loosing most of the value retrospectives can bring.