There are 2 occasions when a team is required to have a retrospective; at the end of a sprint and at the end of a project (or phase). These are prescriptive ceremonies for Scrum teams to reflect and improve.
I was asked recently if there is ever an occasion when a retrospective would be conducted outside of the traditional end of an iteration. By the book there is not, however Scrum is a methodology built upon Agile Principles and so it makes sense to be fluid in interpretation rather than sticking to hard and fast rules. By the book is a starting point for any Scrum team, the team is free to adjust their interpretation but by doing so it is likely that results may vary. It is important that a team begins from the prescription of Scrum and only over time do they add, remove, and amend ceremonies, workflows, and artifacts.
In theory you could have a retrospective at the beginning of an iteration, but this is the other side of the same coin when you consider an end of iteration retrospective – one iteration and is immediately followed by the next. What about a retrospective during an iteration?
I’ve come across a few specific occasions where a retrospective has been conducted in the middle of a sprint, in general you can have a retrospective at any time. When there is something of significance to discuss you should be having a retrospective, you are likely already doing this in a informal manner. As a Scrum team is self-organising and made up of people, conversations are common and should be encouraged. The only difference between a typical conversation and a retrospective is that the Scrum Master is there to facilitate and document findings from the discussions. If you’re a particularly good Scrum Master you will always be listening to your team, never interfering or leading the decisions but listening. Listening is the most important aspect of being a Scrum Master – you learn a lot more by letting others speak. I like to make notes throughout the sprint, documenting all the key events that occur during a sprint. With this information in hand you can more effectively facilitate the conversation throughout a sprint allowing the development team members to focus on the details of doing the work while you consider how the team works as a whole.
I’ve conducted retrospectives where a team has had problems during sprint planning, more often than not it has been a question of delivery item description quality – lack of information provided on tickets, leading to deliverables not being delivered when expected. The development team wanted to know what they needed to do to know when they had completed their work, and not find themselves constantly chasing moving targets. This particular instance highlighted the importance of locking down a sprint commitment and all information contained in those deliverables, to ensure the integrity of team velocity.
I myself have called retrospectives immediately following a daily stand up, to facilitate the conversation of seemingly innocent behaviours that may be negatively impacting the team. Watching team members type away at their laptops while their peers share information, then giving their own update to the attentive group without a hint of irony. Playing games on a smart phone, colouring and doodling in notebooks, it all comes down again to the most important skill of any team member – listening – to best serve oneself and the team as a whole.