In order to generate the best results from a retrospective, the following
elements must be present:
A safe environment for feedback and discussion
A plan for advancing discussion from facts to conclusions
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 the manager should act as
this moderator - however, in some circumstances the manager may feel a strong
need or desire to participate in the conversation. In that case they should
find a peer, Director, or other member of the team willing to moderate.
Emotions are not only allowed in retrospectives, they should be
encouraged. Emotional language ("I was angry when…," "It made me sad
that…") not only helps convey intensity, it also helps expose issues that
may have been difficult to sort out otherwise. Make sure all participants
know they are free to express their feelings, although we do expect them to
stay consistent with our values.
When possible, all parties should be present. No one should have to worry
about sharing concerns or experiences because another party isn't there to
represent their side of the story. This includes stakeholders outside of the
team, where necessary - if someone's role or contributions are going to be
discussed, they should have the opportunity to contribute to the
retrospective as well.
When necessary, get people face to face. After a particularly difficult
iteration, or when there's a strong risk that emotions will be running high,
it's almost always worth the cost to have everyone in a video meeting to talk
through the retrospective in real-time.
Having a plan
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:
Introduction - remind people of the purpose of the retrospective, and
that the conversation should be scoped to the project/iteration under
review. Ensure everyone understands the rest of the agenda.
Gather data - don't try to draw any conclusions up front, simply
collect facts. This can be done by constructing a timeline, soliciting
impressions ("what made you mad, sad, or glad in this iteration?," etc.), or
any other number of fact collecting exercises.
Generate insights - now that you have all of the facts, try to work
together to identify patterns or causal relationships (because we did
x, y happened).
Decide what to do - with the insights firmly in hand, it should be
fairly easy to identify action items for the team. This could be things
to change with our process, it could be things to experiment with in the
next iteration, or any other number of things.
Close the retrospective - make sure everyone who participated receives
positive feedback about how they helped create these results. Observe any
surprising or unexpected results from the retrospective, which confirms that
the retrospective was valuable. Make sure all of the action items are
appropriately assigned to one or more team members with clear expectations
for when they should be completed.
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
Retrospective of Retrospectives
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:
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:
Any issues marked with retro label that have been updated since last retro.
What went well during this month
What went wrong this month
Issues created to address what went wrong this month (labeled with 'retrospective X.Y')
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