Retros Need Action Items
Action items are small, defined, actionable TODOs to follow up on after the meeting. An example: “close all pull requests opened more than 90 days ago.” Agile retrospectives should produce many of these.
Why Are They Important?
Action items steer a retro away from conversation and toward action.
I once worked with an engineer who ran retros among all the contractors on the project. He’d push for action items after every discussion, saying: “I want to respect everyone’s time by making sure this leads to action.”
That’s my argument. When people show up to retro after retro reporting the same issues without action, they tune out. They stop sharing ideas and pain points because they feel like their thoughts have been addressed by listening.
Better than being heard is having your feedback translated into action. This might not be possible on every retro item; some points might stem from a misunderstanding, or require an employee to recalibrate expectations. But generally action is possible.
Sometimes we might not agree on the action. That’s great! Now we’re debating how to solve a problem, rather than commiserating its existence. Push for that solution.
Practice
Here are some typical retro comments, and how they could be turned into action.
Retro comment: “The QA database is different from production.”
Action item: “Add a daily cron job to pull a production backup to QA.”
Retro comment: “We keep merging failing builds into the main branch.”
Action item: “Turn on branch protection requiring a passing build.”
Retro comment: “Design PR’s are hard to review because they’re so visual.”
Action item: “Let’s add screenshots to PR’s with design-heavy changes.”
Wrapping Up
Most problems in software have a set of good known solutions. We might not know what they are yet, but demanding action is how we practice finding them.
Show me a retro note, and I’ll show you an action item.