(This is part 3 of a series on applying devops principles and practices to game development. The main post is here and all posts can be found under this tag.)
In our post on devops philosophies, we emphasized the continuous process of learning and revising, and said that a good place for that to happen is in retrospective (or post-mortem) meetings.
So what is a retrospective?
It's a team meeting in which you all discuss an event, including summarizing (or detailing) what happened, what the effects were, any successes or failures, and any work or process changes you want to make as a result of it.
An "event" could be something like a show-stopping bug that made it through development, testing, and release to your players. It could be your website going down for an hour or six. It could be a massive blow-up in team communications.
It could also just be a sprint or some other unit of time or work. Finish a big feature's development? Have a retrospective. Do you plan for work a month at a time? Have a retrospective before you plan.
The idea is to make these meetings painless and productive so there's no issue in having them whenever they're needed.
We here at Future Proof have them at the end of each weekly sprint, before we do the next sprint's planning. If any emergencies or incidents have happened since the last retro, we also discuss them there.
No Blame
An excellent spin on these is what's called a "blameless retrospective": to have a retrospective that is honest about accountability without engaging in punishment or retribution. If you want your team's dynamics to be healthy, especially in the long run, it's pretty crucial not to punish team members for their mistakes while trying to figure out what happened and how your team can improve.
When you allow blame and punishment during retros, people will tend to be dishonest or make excuses. You don't need excuses or lies, you need the facts of what and when things happened, how they happened, and how they were resolved. Etsy calls this focus the creation of a Just Culture.
(This is not to say that disciplinary or personnel problems shouldn't be handled at all—just not in this meeting.)
What's the Agenda?
So what happens during these meetings? What do you actually talk about? Here are four questions to answer during a retro:
- What went well?
- What went wrong?
- How can we fix what went poorly?
- How can we keep doing what went well?
There's no fixed structure for this meeting, but I'd recommend finding and settling on a structure that works well for your team. Predictability can help things run smoothly. For instance, you might answer each question for all people (e.g., "Everyone, what went well for you?"). You might instead answer all four questions for each person in turn (e.g., "Melissa, what went well for you? What went wrong for you?")
The last question, "How can we keep doing what went well?" is one that's often overlooked. We tend to focus so hard on what went wrong and how to fix it that we can forget that improving our process also means not losing what's already good. We need to keep those things that are working, and we need to keep an eye out for the pleasant surprises. If someone reports they tried a technique they looked up online or heard at a conference and it worked out well, then talk about whether that can be applicable going forward.
And lest you think this is all technical technique and process, consider the case of someone being tasked with cold-emailing a few YouTube/Twitch streamers with press keys to their game. It's a thing the team has done before, and the response rate is typically middling to poor. This time, though, the person decides to leverage some interesting wording or a format that they heard at a conference, and lo and behold, 30% more streamers respond, even if just to say, "This looks cool, but isn't my style."
The way you communicate with folks outside your team? That's a process. That has techniques. Keep your eyes open for all of these things.
Digging Deep
When you get to the problem-solving questions, you may find you have to circle back to the "what" questions more than you think. How to fix a problem or keep a working process can be very situational or environmental. That cool thing you did in the emails to the streamers might only work on those streamers once. Keep it in the toolbelt for the next time you're reaching out to new folks.
This forces you to really drill down into the "what"s. "The site went down," isn't a very good answer to "what went wrong?". "The site went down, but we weren't notified by UptimeRobot or Pingdom because the server returned a 200 (OK) response with the error page" is an answer. And what you fix isn't that the site went down—for those of us with small budgets, our sites will inevitably go down—but you can fix the fact that your server pretended things were fine and you had to be told by folks on Twitter that your site was down.
Getting good at this drilling down takes practice. It takes a lot of practice. If we don't consider learning this to be part of our jobs, regardless of whether we're artists, programmers, or business development, we're going to be inclined to rush through this meeting with superficial answers.
One rule of thumb: the answer to "what went wrong" is almost never as simple as "a bug got deployed" or "the site went down". If that's the first answer that comes to mind, pause a moment and think about why that happened or why that became a stressor/disaster.
The more regularly you do it, and the faster you close the loop on emergencies or sprints, the more useful this tool is. Some teams have retros the business morning after an emergency is resolved. Site goes down on a Tuesday night and you flail around until 03:00 to get it running? Take some notes and be ready to talk about it at 10:00 on Wednesday.
Takeaways
What does this meeting produce? (By the way, if your meetings aren't producing anything, add that to your first retro's "what went wrong" list.)
You should come away from a retro with at least two of these three items:
- A clear understanding of what events happened in a sprint or during an emergency.
- Actionable items in your work backlog to improve your processes.
- Items added to your team list of process/environmental annoyances
Also try to get an understanding of how your team perceives their performance. Are they frustrated? Do they think they did really well? Paying attention to the team's morale (including your own, if you work alone!) is pretty crucial to making sure folks' needs are being met.
Tips
During these meetings, someone should take notes, and those notes should become team-accessible as soon as possible. It doesn't need to be a dictation of the meeting, but capture the highlights and action items.
Whatever your actionable items are, put them immediately into your task tracking software. Don't let them languish in the Google Drive folder of retro notes. All this chatter is to genuinely make change.
Managers that aren't in the weeds on a project don't need to be at these meetings, even as silent observers. If they want an after-action report about a sprint or event, send it after the retro. Including managers can make it really difficult to keep retros blameless and actionable.
What These Aren't
Notice that this is pretty different than what you might see on a stage at a conference. Those post-mortems or retrospectives are outward-focused; their goal is to communicate and share ideas from their project to you.
It's often surprisingly difficult to implement ideas from other people's retros, because their situation and their environment are different. They themselves may not understand yet why something worked, just that it did.
If you get interesting ideas from a talk, make sure to give them a critical eye for whether they're appropriate for your project and whether they're solving a problem you actually have. Copy-catting processes that cool companies are doing isn't necessarily a recipe for success. Adapt them, or leave them on the back burner if they aren't useful now.
Your own retros should be internally focused. Your team shouldn't be working from a motivation to seem cool, market themselves, or look good in the eyes of the larger company or industry. These are for internal consumption and improvement.
Our Games
Exploit: Zero Day is our browser-based puzzle game about hacktivism. It's in closed alpha for the moment, but you can get access by joining the mailing list. You'll receive an access code in the next monthly newsletter. YouTubers, streamers, and press, request a copy from distribute().
Our first release, Ossuary is available on Steam, itch.io, Humble, and IndieGameStand. Press-like people, you can also request a copy of Ossuary from distribute().
View on YouTube
