In addition to the public function-wide retrospective, each Engineering team should be in the practice of holding their own retrospectives. The results of these retrospectives should then inform the function-wide retrospective for any given release.
In order to generate the best results from a retrospective, the following elements must be present:
Not every retrospective will require both of these elements - for example, an iteration where "nothing went wrong" may see retrospectives that don't benefit from a safe environment. Similarly, an iteration that has nothing but "obvious" problems will probably have a productive retrospective even without a strong plan for the discussion. However, even iterations that seem fine on the surface can harbor deep problems, so it is always best to be prepared.
Retrospectives are inherently conversations about what went well and what went wrong in a project or iteration. While it's easy to talk about what went well, what went wrong can be a touchy subject. Without a safe environment, issues may go unmentioned and the team won't improve as rapidly as they otherwise could. In order to collect as much feedback as possible, we recommend that you observe the following:
All retrospectives should have an impartial moderator. This moderator actively attempts to remain objective and is focused on guiding the conversation forward throughout the meeting. If participants feel that the moderator has a stake in the conversation, they may feel as though it is not safe to voice dissent or share concerns.
Normally a manager should act as this moderator. In some circumstances the moderator may feel a strong need or desire to participate in the conversation. In that case they should make it clear that their participation is as an individual participant, not as the moderator. If the moderator wants to take a very active role in the discussion, they should find a peer, Director, or other member of the team willing to moderate.
It's easy for retrospectives to go off the rails if there isn't a good plan for collecting actionable insights. If the moderator doesn't guide the conversation successfully, the retrospective could be dominated by a few "loud voices" or could stay focused on the facts and feelings about the past iteration without drawing any conclusions. To make sure the conversation is productive, we recommend that you have a clear agenda for the conversation. The moderator for the retrospective is then responsible for ensuring the agenda is followed and completed. While the specific nature of this agenda will vary from team to team, we recommend something that follows this general pattern:
Right now we are leaving it to individual Engineering Managers how they would like to collect retrospective notes - GitLab issues, Google docs, etc. After the retrospective is complete, the Manager has until the public retrospective call (shortly after the 22nd every month) to make relevant notes from the retrospective public. Teams are encouraged to link to these notes from their team page in the handbook.
As part of the retrospective process an Engineering retrospective is performed which is a summary of retros. Please review the Engineering Retrospective for documentation and format of the meeting. To track the work an issue will be opened per release. An Example issue: https://gitlab.com/gitlab-com/www-gitlab-com/issues/3990. Engineering Managers should save ample time between the closing of their individual team retrospectives and the Engineering retrospective to review notes/generate content. In particular, the following content should be added:
In the case where a manager feels an issue can/should not be created, please include that in the what went wrong section.
We recommend the following resources if you'd like to learn more about running effective retrospectives: