Agile retrospective

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.

---

End of quarter

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.

• Departmental teams, like Product, Sales, Engineering, Marketing
• Bigger teams collaborating towards a common goal, e.g. Product and Marketing working on specific KPIs together.
• The whole company, evaluating the quarterly activity across all departments and their collaboration.

Having a retrospective that covers such an extended period, requires heavy facilitation and a good onboarding on the important work delivered during that period.

Suggested set up

• Perform asynchronously the first three steps of the retrospective process.
• Provide a healthy period for everyone to share notes, probably 1 week for each step, using the Team O'clock step timer.
• Coordinate asynchronously with all team members, sharing the Team O'clock retrospective link in the channels of choice (email, company messaging app)

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.

Right after a feature release

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.

Suggested set up

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.

Right after an incident

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.

Suggested set up

• If possible have a sync session, or at least have a sync discuss step session.
• Make sure to leave room for everyone to talk!
• Keep the meeting short, not spanning longer than an hour
• Action items should be closely related to processes, with a focus to avoid a similar incident in the future
• You can add 2-3 action items per involved team.