Restrospective is one of the official meetings that Scrum considers. It is a timeboxed meeting where the Scrum Team gathers together at the end of every Sprint to look back and think about how things went.
Though the meeting is official, there is not an official “template” for it. It is on the Scrum Master to host it and define which format the meeting will have.
Personally, I like to do different exercises for every retrospective. In this manner, it is easier to get the team involved (meetings are boring for developers and the Scrum Master has to make them attractive for the team, as he is the facilitator)
This article is not about the different exercises (maybe I will share a series of Retrospective exercices, but, in the meantime, you can take a look at the Restrospective Toolbox my colleague Jimmy did as part of his Master Piece, really great job!).
This article is about the things that could go wrong, which are a lot: not every team member participates and gives his opinion, finger pointing, not having a clear goal for the meeting, leaving the meeting without any actions, not following up on the actions agreed on the last Retrospective… but, the point I want to stress today, is to keep the focus within the team’s impact area as a rule.
That is what I mean with keeping the focus of the meeting within the team’s impact area. I’ve seen too often retrospectives going away only talking about what people not belonging to the team should have done, as if the team’s actions had no impact on the output of the Sprint. This is so wrong!
Do not waste time complaining about what managers should do, how the Requirements Engineer should work, or how QA should give you feedback. Focus on how the team did, what can be improved, what should stay the same, what should the team do more, and so on.
But I said “as a rule”, and it means, that there can be exceptions 😉
Sometimes it is needed to point out some situations. Maybe managers interrupt developers so often day after day for weeks now, or maybe the Requirements Engineer does not deliver his work on time so that developers know what the constraints are. It is fine to point this kind of things out when they become the usual scenario, to set some action, and let the right person remove the impediment itself (most likely the Scrum Master). But it is not ok to waste Retro after Retro complaining the whole meeting about it. It must be the exception.
That is why I think it should be called Intro-Retrospective, because a team should focus (as a rule) on what they can have an impact on.