How GitLab handles retrospectives

Each month, GitLab’s engineering team hold a retrospective to learn and improve as much as possible from every monthly release. Retrospectives are the preferred method for GitLab team members focused on improvement and ensures that our technical debt doesn’t grow faster than our code base.

“When we say retrospective, here’s what we have in mind: A special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and gener-ate action. Retrospectives go beyond checklist project audits or per-functory project closeouts. And, in contrast to traditional post-mortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues – if not more so.” — Agile retrospectives: Making good teams great

Since retrospectives can cultivate a culture of transparency, trust, collaboration, and communication, we want to share the steps our team takes in order to ship every month.

Engineering-wide retrospectives

In line with our value of transparency, we livestream the meetings to YouTube and monitor the chat for questions from viewers. We also have a publicly available document for retrospective notes so that we can efficiently refer back to decisions, insight, and comments.

In each retrospective, the team methodically works through the same discussion points:

1. Previous retrospective improvement tasks: The moderator reviews the improvements the team identified in the last retrospective and discuss progress on those items.
2. What went well this month: Teams are encouraged to celebrate the ways in which we exceeded expectations either individually or as a team.
3. What went wrong this month: Teams are encouraged to identify mistakes and unmet goals. The focus is to highlight areas that didn’t meet our expectations as a team.
4. How we can improve: The team engages in blameless problem solving to identify how subsequent releases can improve. Are there changes we can make in workflow? Is there a potential silo forming? Do changes need to be made in communication and collaboration?
5. Improvements for next release to track: At the end of each retrospective, the Engineering Productivity team triages improvement items identified during the retrospective. Having a single owner of triaging enables the awareness of the bigger picture technical debt and backstage work required. The individuals issues are assigned to other teams or engineers to execute.

Retrospectives are publicly live streamed each month. Take a look at the retrospective for 12.5. 🍿

Team retrospectives

Team retrospectives are held to inform the function-wide retrospective for any given release. Sean McGivern, engineering manager, Plan:Project Management, wrote a great article on using GitLab CI to automate monthly releases. Using scheduled pipelines to create an issue early in the release cycle, teams can contribute to the retro issue while they’re still working on the release.

“It doesn’t matter whether you have four or five labels of things on your retro board, or exactly how you do the retro. What does matter is the notion of thinking about what we're doing and how we can do better, and it is the team that’s doing the work that does this, that is the central thing.” — Martin Fowler

In this team retrospective issue, the Create:Editor team takes a look at what went well, what didn’t go well, what can be improved, which issues shipped, and which issues slipped in the 12.5 release. In team retro issues, individuals can gauge how others experienced the release and discuss points raised by teammates.

Here’s a video of the Plan team holding a retrospective to discuss recent slipped issues. 🍿

Asynchronous retrospectives

Since GitLab is an all-remote company, we strongly encourage asynchronous communication, since team members can be located in any of the 65 countries where GitLab team members live. We apply asynchronous communication to our retrospectives to ensure that everyone can contribute and document their experiences.

Asynchronous retrospectives are not just for remote teams. They can also be used by colocated teams to facilitate open discussion when team members have the bandwidth to dedicate to problem solving. Furthermore, asynch retros can serve as a dedicated place where people can quickly jot down their thoughts when they suddenly remember an experience, rather than be forced to remember everything during a dedicated call.

Retrospectives: The impact on culture

When retrospectives are run efficiently, these meetings can build mutual trust, communication, and collaboration. They cultivate a culture of continuous learning and improvement, two characteristics of any strong Agile team. The more teams can determine how to efficiently build software, the more value they can bring to users.

Cover image by Shane Aldendorff on Unsplash.