How we use GitLab to automate our monthly retrospectives

As an Engineering
Manager at GitLab I spend most of
my working day using GitLab for a variety of tasks – from using issue boards for team assignments, epics for tracking longer-term initiatives, and todos and notifications to manage my own workflow.

We also use GitLab in a number of unconventional ways, so I wanted to share with you one interesting use case we've been experimenting with.

GitLab stage group retrospectives

Each stage group at GitLab has its own retrospective, which then feeds into the
GitLab-wide retrospective we have for each monthly release.

The Plan team is fairly widely
distributed: we have people on four continents, and only two members of the team
are even in the same country as each other. We wanted to try asynchronous
communication wherever possible, so we used GitLab issues for our
retrospectives, too.

A quick note on terminology: we say team to refer to a manager – like me – and
their reports. We say stage group to refer to the people who work on a
particular DevOps stage, even across multiple teams. The Plan stage group is
even more widely distributed.

Automating retrospective issue creation

Creating the retrospective issue was fast, but adding links to notable
issues that we shipped or that slipped was time consuming and
tedious. In the spirit of xkcd 1319, I decided to automate it, so I
created the async-retrospectives project. This project makes
retrospective issue creation a hands-off process:

1. It uses scheduled pipelines to create an issue on the 1st of each
   month. As our development month runs from the 8th to the 7th, this
   is a little early, but it allows the team to jot down any thoughts
   they have while they are still working on the release.

   

2. The issue is created using the standard GitLab API, using a protected
   variable to hold the credentials.

3. When we create the issue, we use quick actions to add the correct
   labels and due date in a convenient way. (This is also possible
   without quick actions, but quick actions are more convenient for me
   personally.)

4. Another scheduled pipeline runs on the 9th of each month to update
   the existing issue's description with the lists of issues (slipped,
   shipped) I mentioned above.

   We make our retrospectives public after we conclude them, so you can see this
   in action on the 11.8 Plan retrospective:

   

I only intended this for use in Plan, but a nice thing about a company where we
give agency to people to solve their problems is that people like me are able
to try out things that might not work globally, like this.

As it happened, it's also been picked up by other teams and groups. We
configure the creation in a YAML file, just like GitLab CI is configured, to
try to make it as easy as possible for other managers to contribute and set this
up for their team.

Our experience running asynchronous retrospectives

What works

We've had a lot of positive experiences from these asynchronous
retrospectives. In particular:

1. No one is disadvantaged because of their time zone. If we had a video call
   with our time zone spread, we'd have some people on that call in the middle of
   their night, or missing out completely.
2. Because they are written down from the start, and because comments in GitLab
   are linkable, we can very easily refer to specific points in the future.
3. Also, because they are written down, the comments can include links to
   specific issues and merge requests to help other people get the same context.

What needs improvement

Asynchronous retrospectives aren't perfect, of course. Some of the downsides
we've noticed are:

1. Video calls are simply better for some things. In particular, the discussion
   does not flow as smoothly in text as it can in a verbal conversation.

   We also conduct our engineering-wide retrospective in a public video
   call, so we retain some opportunity for synchronous discussion.

2. Similarly, team bonding is slower in text than in video calls.

3. Participation can be lower if it's something you don't have to do right now,
   but can always defer to a later date. We are continually looking for ways to improve
   this.

Over all, we don't intend to go back to video calls for retrospectives,
and we're really happy with the results. You can see all public
retrospectives from the teams and groups at GitLab in the GitLab
retrospectives group on GitLab.com.

Photo by Daniele Levis Pelusi on Unsplash