There is probably not much point in doing agile retrospectives, if we’re not taking good action items. In this short post I’d like to talk about some different types of action items and how to make some bad ones better.
Let’s assume in a retro someone posted ”Sad that our Python client broke the contract with the server-side API”. After discussing what happened, why and so on, our team decide to take the action item: ”Better support for the Python client”. This action item, however is not very actionable. A better action item could be “Add contract tests for the Python client”.
Generally in my experience, I’ve come across the following different types of action items:
- ”Better support for our python client”: Not actionable. We cannot immediately make it actionable. Implies that we haven’t discussed the feedback item enough. If there isn’t enough time to discuss the issue, we might want to take an action item similar to ”organise a focused discussion on the issue to decide what to do to prevent/mitigate the problem in Python client”.
- ”More pairing”: Not quite actionable. But we can immediately make it actionable by saying instead ”Set up a reminder to remind people to do more pairing”.
- ”Add contract tests for the Python client”. Very actionable. Implies that we’ve discussed the issue enough.
- ”Avoid big pull requests”: Not too actionable and we can’t make it more actionable even though we’ve discussed it enough. Consider adding signs / reminders in the office that remind you to avoid big pull requests.
It’s also important to follow up on action items. There is no one-size-fits-all solution for following up. We might want to prioritise and add action items in our team Sprint (if we’re using Sprints), or dedicate a day of the week for action items, or something else.
Emre @ RetroBox
https://retroboxapp.com
