Why your agile retrospectives don’t have accountability

Let me know if this sounds familiar. To close the agile retrospective:

We usually take a photo of the board and our action items and post it to Slack. We never look at them though.

We take photos of post-its and occasionally put them in Confluence.

Everyone takes their own notes and from there it’s up to them.

Our scrum master usually keeps them on a Wiki page. But I don’t know that anyone actually goes back to those notes other than the scrum master.

These quotes came directly from customers prior to using Sprintlio. The worst part is, this theme of displacing responsibility for action items from agile retros is the norm. Without realizing it, these teams care more about archiving information than they do about actioning it.

It’s our belief that if your team doesn’t take the time between sprints, releases, iterations, or projects to reflect on learnings, identify opportunities to improve, and be accountable for those next steps — it defeats the purpose. After all, the twelfth and final tenet of the Agile manifesto is that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”.

An agile retrospective is about more than just the discussion. It needs to be followed by action or the repercussions will become more severe over time. Yes you can run an agile retro anywhere and for free. You could do an entire agile retrospective on a napkin if you want. But if your team isn’t taking the follow-ups from that napkin and delivering on them in the next sprint, you are setting yourself up for a catastrophe. A manager turning a deaf ear to their team is no different than the elected politician ignoring the people they represent.

If your method of tying a bow on the agile retrospective is taking a photo of the discussion and posting it in the team wiki, you’re letting down your team. But we can turn this around. Quickly. Next time you’re coming up with this list of action items do the following:

1. Lessons vs. To-dos: Identify which action items are lessons (or themes) and separate them from the concrete to-dos. Make sure to remind your team of that lesson in a constructive way when suitable between this and the next agile retrospective.
2. Assign owners: For the concrete action items, immediately identify who the owner is and make sure they are aware of the task before the agile retro is closed.
3. Add due dates: If suitable, add a due date immediately. Let the team and the owners know about this too. Even if this date is flexible, it creates an anchor for the team and the owner to work off of. A tentative date is better than no date.
4. Export to backlog: Add all of the items to your team’s project management backlog. Even the silly ones. Make sure the team knows they’ve been heard and that their input is receiving the attention it deserves.
5. Type them: Type the action items out! Do not take a photo! Make sure this list is included with the archived discussion. If it’s not typed, it will be impossible to find later and even less likely to be actioned.
6. Add to next invite: Immediately add these items to the calendar invite of the next agile retrospective to make sure they are front and center before the next agile retrospective.
7. Start every agile retro with them: At your next agile retrospective, when you are setting the stage, include a part of the conversation to discuss open action items from the last agile retrospective. Create a narrative of action and delivery within your team.
8. Editor’s note — we received this via comment from Chris Riesbeck and it was too good to exclude: “Treat agile retro to-do action items exactly like user stories: They go in the backlog. They get put on the task board for an iteration. They get story points if you do such things. They have tests for done. This will force items to be actionable, visible, and accounted for in terms of cost.” I love it.

Action is more important than archiving. Make sure you and your team build a habit of reflecting on the completed action items to identify learnings for your respective team and company-wide. It’s about improvement, not just discussion.

There are easier ways to give your agile retrospectives accountability. We’d love to show you.