Published on December 19, 2019
4 min read
Take a peek at how the GitLab team holds monthly 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.
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:
Retrospectives are publicly live streamed each month. Take a look at the retrospective for 12.5. 🍿
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. 🍿
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.
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.
Find out which plan works best for your team
Learn about pricingLearn about what GitLab can do for your team
Talk to an expert