How should we implement and keep track of recurring or intangible retrospective action items?

Question

Our Product/Tech team has been transitioning towards Agile project management in the last year or so, and we hold daily standups, weekly planning meetings and biweekly retrospective meetings. We also use a Kanban board.

As the team's Scrum Master, I've been trying to make the retrospectives more actionable, as some team members have pointed out that we often end up discussing the same issues that don't get solved. I'm worried about the impact of this on team members' morale and desire to participate, so I've tried several approaches to make things more concrete, such as 15% solutions, and limiting the number of action items that we commit to doing to the bare minimum (i.e. 1-2). We've also been adding those items to our Sprint board to give them visibility. This has helped quite a bit with ad hoc, concrete action items.

What I'm struggling with right now is what I call "intangible" action items, i.e. items that are linked to habits or behavioural change and/or are recurring in nature. Here are some examples:

• When pulling a PBI into Building, take some time to think about how it will be reviewed so that it doesn't create bottlenecks in the Ready to Review column
• When estimating roadmap items, multiply by 2 so that we provide more realistic estimates
• During the scoping phase, map out dependencies so that we can plan the work better

I could of course put all of these in a document and share it, but it would probably end up on the proverbial shelf and never get implemented. From my experience, even when these solutions emerge from the team to tackle very real problems, because of their intangible nature, they quickly fall by the wayside when things get busy. Hence my question: How do you make sure those action items get implemented? How do you keep track of them?

Answer 1

What I find an effective way to keep those kinds of "behaviour change" actions under the attention of the team is to hang them next to the kanban board, large enough that they can be read from a distance. And once in a while remind the team about those actions when you think they might have lapsed.

Answer 2

There is also term "built-in quality". It means, that the process policies you describe, should be as closer to place where they are needed, as possible. For example, set WIP limits on your board, like in Kanban. Or call columns correspondingly, or put a short note with oncoming rules on it.

Answer 3

This are my two suggestions:

• Action items derived from a retro need to find it’s way into a document
• You can add a task into the current sprint to address issues raised in the retro and it should be marked as completed only if you found a true way to get rid of the issue forever

It seems like you don't think that getting this into documents would work, but I believe that you need to convince your team that documents represent agreements. They are not meant to be static, they are expected to change in order to respond to the needs of your project.

Answer 4

If it's behavior change, then my experience is that shouldn't take more than a couple of sprints/weeks before the new behavior becomes a habit. My suggestion is to treat them as any other action, put them on your task board and follow up regularly.

If after some time they still need a lot of attention, then there's a deeper problem. The recurring action might be a retrospective smell that needs attention.

Does this make sense?

Answer 5

The best way to implement such changes is directly in the system itself.

For point 1: You could modify the DoD for the column before building to include "prepare review criteria" or even make it an extra column before Building.

2: (Aside from the fact that I am sure there are better alternatives to estimating) I would modify the system that uses the estimate. For example if you multiply it by 1000 to get a price, start multiplying it by 2000 instead.

3: This too is either an addition to the DoD of the Scoping column, or an extra column before or after it.

Answer 6

A "Shu" suggestion: Make these issues visible on a dedicated Retro Issues Backlog. When the issue re-surfaces put a red dot on it or when it persists put a yellow dot on it. When a new dot appears, ask the team to brainstorm reasons or conditions that allow new dots. Ask other teams if they have the same situation or how they deal with it.