How HR can become agile with retrospectives
4 mins, 51 secs read time
There are many practices the Greenhouse Engineering Team has used to become healthy and high performing. But if I had to choose just one to impart to another team, it would be the retrospective. It’s easy for a People Team to adopt and it’s the one process that can improve all your other practices.
Agile software development teams have been using retrospectives since 2001 to continuously reflect on their work and improve anything from coding standards to UX design to cross-team collaboration.
A Retrospective is a weekly meeting where the team discusses current pain points and decides on action items to resolve them. The format is wonderful because it’s not specific to one kind of problem or domain; it’s applicable in any environment with a repeating pattern of work such as building software, managing a team or recruiting amazing employees. The only other requirement is an appetite for improvement.
Retrospective best practices
A Retrospective meeting is most effective with three to seven participants. Teams usually meet every two weeks for an hour during the course of a project or the lifetime of a team. In the early stages of a project, it can be beneficial to have meetings every week or extend them to an hour and a half. A moderator should be selected beforehand, usually at the end of the previous Retrospective. It’s a good idea to rotate the moderator role at each meeting.
The ideation phase
At the beginning of the meeting, the moderator sets a timer for 15 minutes. This is the ideation phase of the meeting. Each team member is given a pile of blank index cards and a sharpie and writes a brief description (think headline length) of something they want to talk about on an index card. They indicate if it makes them “Happy”, “Meh”, or “Sad”. Each topic gets its own index card.
Once the timer is up, the sharpies go down. The moderator sets a timer for 10 minutes. They collect the index cards and organize them into the three categories, “Happy”, “Meh” and “Sad.” They then review all of the cards with the team. Each card is read aloud, leaving 30 seconds if the topic needs to be explained a little more. This is not the time to have a discussion about each card; the moderator should be vigilant.
The Happys will be a time for celebration. Cheers and applause are common here and should be encouraged. It’s helpful to cheer everyone up, as the discussions to follow may be stressful. The moderator will keep an eye on the time to make sure that all the cards have a chance to be read aloud before the timer goes off.
The selection phase
The team has now entered the selection phase. The moderator sets a timer for five minutes, and the team votes on what to spend the remainder of the meeting discussing. Each team member gets three votes, using their sharpie to mark their votes on the cards. They can put all three votes on one card if they’d like. Once everyone has finished, or the timer is up, the cards are ordered based on votes.
The discussion phase
The moderator sets a timer for 15 minutes and the person who wrote the card being discussed is given one minute to kick off the discussion. The goal of the discussion is to generate action items.
The role of the moderator is to keep the discussion on track and continuously petition the group for action items. Action items are the heart of the retrospective. Without them, the meeting does not have a reason for existing.
Once the timer is up, the discussion phase repeats for the next two topics, setting a five-minute timer for each.
Reviewing and assigning action items
The last five minutes of the meeting is spent reviewing action items. Each is assigned an owner – an important step in the process as it ensures that someone is now responsible for making sure the item is moved forward.
Adapting retrospectives to People Teams
While this is a very structured format, it’s also very adaptable. As you can see, there is no part of this process that is specific to software development. When it is a part of software development, common topics consist of testing strategies, tooling improvement, deployment concerns and interpersonal dynamics.
The regular application of the bi-weekly Retrospective works for every team, however. People Teams are no different. The most effective retros are with team members who interact often or perform the same role. Great areas for discussion are prospecting, candidate communication, negotiation and, of course, onboarding.
Retrospectives are also useful for cross-functional teams like your hiring team. We’ve used the Retrospective format to improve our own interview process. For example, our engineering focused recruiters invited our engineering hiring managers along with some of our interviewers to Retrospective meetings.
We discussed which interviews in our hiring plan worked well and which ones we had some concerns about. The recruiters came armed with our interview pass-through rates and the results of candidate surveys.
With everyone together, we were able to implement changes to make sure we were measuring the right candidate attributes and presenting a level playing field for candidates from different technical backgrounds. We also discussed offer acceptance and candidate engagement.
As a result of what we learned, we now give candidates more time to ask their future managers questions about the team – which also allows more time for us to sell the candidate on why Greenhouse is the right choice.
There are many ways to apply retrospectives to your People Team to make sure you are continuously improving your process. Applied vigorously they can help not only improve the candidate experience but the health, happiness, and effectiveness of your People Team!