Retrospectives are a crucial component of the agile methodology. However, having a retro should not be about checking-off a mark in our agile todo list. The purpose of the retro is to learn and then take action that leads to a better place. We learn from our past actions and results and we use that knowledge to improve our future execution.
The Geo team will have monthly retrospectives as a way to reflect on how things are working out for the team and for its members. The objective is to learn and become a better team in terms of collaboration and execution of the team’s mission.
Retrospectives enable Actionable Team Learning. By Learning, I mean that the retrospective must lead to the acquisition of new knowledge or skills. By Team Learning, I mean that the learning must be for the whole team and not isolated to an individual. And by Actionable Team Learning, I mean that the knowledge or skills that the team has acquired must have the potential to lead to change. - David Horowitz (Retrium CEO and Co-Founder)
The retrospective activity may look different from one month to another by applying different techniques according to what is happening in the team at different times. It is also a way to keep the retros engaging and avoid burnout from repetition.
Although the retrospective will occur on a regular cadence, the Geo team does not follow sprints but rather a Kanban process. This means that the insight and discussions in the retros do not necessarily need to be limited to a particular time frame.
GitLab promotes the value of remote and asynchronous work. Our retrospective process respects this value. However, the time for reflection is better served by dialogue that happens in a more synchronous way. It is essential that team members can engage with one another in meaningful discussions that lead to actionable insights. This is why although the process is built with support for offline collaboration, there is an established schedule for the different phases of a retrospective and all team members are expected to participate following the schedule.
Geo team members required:
Optional:
Occasional (by invitation)
Retrospectives will take place from Monday to Thursday during the last week of every month (i.e. the week that includes the last Thursday of the month). Overall this will be about a 2.5 hour time investment spread out throughout the week.
Retrospectives will have 4 phases:
During check-in phase the engineering manager will set the stage by describing the activity for the retro, define the context or scope of the discussion and post a check-in question that all team members must answer. The check-in question can be an ice-breaker or a work-related question that helps people get engaged into the retrospective.
This message will be sent through slack and all team members are expected to take action before the end of day Monday within their respective time zones. Reading the activity and answering the question should not take more than 5 minutes.
Right after check-in, members are expected to participate in the data gathering phase. The type of data will depend on the activity at hand. Generally speaking it will involve working individually to brainstorm and record data points into a retrospective board as sticky notes. At times, data gathering may involve fetching reports on metrics or other information from outcomes and events that happened in the last period. Data gathering should not take individual members more than 25 minutes and it can happen at any time between Monday and Tuesday.
This phase is where the meaningful analysis of the data happens. This is where team members collaborate to learn from each other and where they find actionable insights.
Throughout the day, team members are expected to read all the data collected in the board as sticky notes and start the conversation by asking each other questions in written conversation threads (i.e. comments) in the context of specific issues. It is helpful during this phase to ask clarifying questions or ask the “why” of the problems identified to try to reach root causes.
By the end of day, all team members should take a last look at the board and make sure they have seen the latest comments that may have come in later in the day. Overall team members are not expected to take more than 1 hour this day to engage in insight generation.
On the last day of retrospective the team will have a call to go over the insights discovered during the week and determine if any actions are required and what kind of action is needed. During this meeting the team will also vote and prioritize the actions that are identified so they can be assessed and detect what is important and what is feasible to do in the short term.
All team members are strongly encouraged to attend. This is a once a month meeting and a reasonable commitment for synchronous communication. In order to accommodate for various time zones, there will be two options for wrap-up calls for team members to attend. One will be friendly to anyone located in the US/EAST-WEST time region and another one for the EMEA region. As the team locations change over time, we will adjust the schedule to make sure the meetings always happen within normal working hours.
The retrospective will wrap up with a check-out activity that helps with reflection on how the retrospective itself went and if any adjustments are required.
For each one of these stages, if people are out on PTO, they can be excused from following the schedule and they can catch up with the process when and if they come back from PTO before the retrospective is over. You are encouraged to plan ahead and check-in with the engineering manager the week before if you want to provide your input before leaving for PTO.
GitLab promotes the value of transparency, so the activities and data collected for retrospectives will be public by default. However we do want to create a safe space conducive of honest feedback and a high degree of engagement. During Wrap-up, there will be an opportunity to bring up anything that should be shared privately and a new issue can be created with proper permissions to continue the conversation there. Alternatively, you may make use of GitLab's internal notes to have those conversations in the same issue.
Highlights of the retrospective will be written to a GitLab issue accessible to team members as record keeping.
