A guide on agile retrospective and when to conduct one
An agile retrospective meeting is held by a group of people that have worked together towards a goal with the purpose of evaluating the work delivered and processes used by the team members.
An agile retrospective is more broad of a term than the scrum retrospective as it can include retrospection with broader teams, like "company wide", "cross departmental retrospective", or to evaluate a specific instance.
A retrospective at the end of quarter is good for a high level review of the past three months. This means that such a retrospective is good for: departments (e.g. Product, Sales, Engineering, Marketing),bi or even the whole company.
Having a retrospective that covers such an extended period, requires heavy facilitation and a good onboarding on the important work delivered during that period.
It is suggested that you coordinate synchronously for the Group notes step with a smaller commitee and ask for clarifications certain individuals on need basis.
Finally it is suggested that you have a synchronous discussion for the Discussion step so that all team is aligned. If you are more than 10 participants in a synchronous discussion, please keep in mind timeboxing each participant's time, so that the discussion moves towards resolution and action items.
Usually a feature release involves more than one teams, handling a different aspect of the feature. So be mindful on waiting for all involved teams to be done with their respecting release part.
Having a retrospective on a feature release, means that all teams should be included in the respecting meeting, e.g. developers, marketing, customer success.
If possible set up a synchronous meeting with all involved members to discuss on the release. The facilitator needs to make sure that all members have time to share their thoughts during the discussion.
In case a synchronous meeting is not an option, follow the set up described above, for asynchronous steps until the final discussion and action items.
The discussion right after an incident is usually called post mortem. Using the Team O'clock online retrospective structure can help into having a structured discussion for your post mortem.
An incident is considered complete after it has been fully handled by all involved parties. Usually incident handling involves at least two teams, the one directly handling the incident and Customer Support that is informing affected customers.