Retrospective fatigue? How to increase follow-through on action items

The retrospective is my personal favorite among the Scrum meetings. Why? Even if there were no other meeting, role, or artefact, retrospectives enable you to invent everything else you need to improve. In theory at least.

When I was just learning how to facilitate retrospectives, I was mainly concerned about the flow of the actual meetings. I needed to gain some routine before I had freed up enough brain cycles to realize that what happens after the retro is at least as important: The whole point is to inspect and adapt, i.e. to change something. If few of the retrospectives’ action items ever get implemented and bear fruit it’s frustrating. Ultimately it leads to retrospective fatigue where teams are unwilling to participate in the retro anymore, because “What’s the point anyway? Nothing ever changes!”

So, how can you increase follow-through and make sure that more action items are carried out? As always it depends on the situation. I’ll cover:

  • A – Team can’t agree on action items
  • B – No one feels responsible for action items
  • C – Action items are forgotten
  • D – Action items are too vague, i.e. not actionable
  • E – Team blames others instead of reflecting on own behaviors
  • F – Always the same topics and action items
  • G – No new action item because “we already have a rule for that”
  • H – We tried to change issue X – no luck yet
  • I – Too many action items
  • J – Um, we’ve got no idea if there’s follow-through

A – Team can’t agree on action items

If you don’t have a facilitator, get one or nurture one. If you do have a facilitator, the “Facilitator’s Guide to Participatory Decision Making” or a training about retrospectives (or moderation techniques) will be beneficial.

B – No one feels responsible for action items

Ass kick fairyEach action item does have a name on it, doesn’t it? In the end of each retro check all action items and ask for each unassigned one who is going to take care of it. A single task such as “Write mail to admins about monitors” also needs a deadline. Recurring tasks such as “Pair program 2 hours per day” are assigned for the whole sprint (or indefinitely until the one resonsible transfers responsibility). The duty here is to remind everyone to comply. One of my fellow scrum masters lovingly dubbed this role “Arschtrittfee” = “ass kick fairy”.

If no one “adopts” a certain action item, throw it away. It’s obviously not important enough to the group and won’t get done anyway. Throwing it away makes the implicit decision explicit.

C – Action items are forgotten

Try-Keep-BoardA team might forget action items, even if there’s an ass kick fairy.  Countermeasures (simplest first):

  • Increase visibility 1 – Action items should – literally – be in everyone’s face: E.g. on the sprint board, the door, a Try-Keep-Board (see image), a rolling items list, …
  • Increase visibility 2 – Reminder stickies for each team member with their individual tasks, to stick to their monitor
  • Introduce a trigger
    • Create a calendar entry for “once per sprint”-meetings rightaway. It’s easier to cancel a meeting you don’t need than to remember and schedule a meeting during “business as usual”.
    • For continuous tasks such as “more pair programming” find a way to remind yourselves daily. E.g. make “check our action items” part of the daily standup.
    • Alternatively to setting a time trigger, you can define a triggering event such as “whenever we’ve got 3 bug tickets”.

In some cases, tasks are “forgotten” on purpose, because the responsible person is hesitant to do it. This is rampant with confrontational tasks such as “Talk to Team Brony about how their late code pushes harm our deployment and testing schedule”. Those are often conveniently forgotten. This might help:

  • Deadline – less room for “I’ll do it tomorrow”. Ideally create a calendar entry.
  • Can someone else take over or accompany?
  • Talk through the confrontation beforehand and how to handle crucial confrontations
  • Premium solution: Have a company-wide training in communication

D – Action items are too vague, i.e. not actionable

Example for a vague action item: “We won’t have failed stories next sprint”
Huh? Isn’t that always the plan? Or was it your plan to let a story fail last sprint?

What are the steps the team will take? Aim for a concrete change in behavior – including what will trigger the behavior. Ways to get there:

  • Rob asks “What could you do tomorrow in order to realize this?” Something like this is usually my first step.
  • Talk about SMART goals and explicitly check off the different letters for each action item.
  • 5 Hows (analogue to 5 Whys) an impromptu idea by Lydia. I love the idea but have yet to try it.
  • If it’s a big, important problem maybe a Micro Strategy can help.

Examples for concrete action items:

  • “We’ll learn about stories before pulling them – Recurring grooming meeting with PO on Wednesdays 9am”
  • “We’ll work at most on 2 stories simultaneously – We’ll ensure this during standup (TODO: add to standup-checklist)”

E – Team blames others instead of reflecting on own behaviors

Don’t get me wrong, I welcome teams who take initiave and confront others about problematic behavior. But talking about others is often less constructive and more a convenient way to avoid taking responsibility and changing oneself. So how do you get a team out of this attitude?

  • A PO and I once did something intervention-like, basically conveying the contents of this blog post and it worked.
  • I stress the “you” more in such teams: “What are you going to do about it?”

F – Always the same topics and action items

Hm. Is the retro always the same format? There are tons of ideas out there to vary, e.g. here, here and here. And of course, there’s my very own Retr-O-Mat 🙂

G – No new action item because “we already have a rule for that”

Sometimes, teams deal with a problem early and then never again, although the problem persists. To their minds, they’ve addressed the issue. A sentence like the following rings alarm bells in my head: “We have a rule for that. If everyone just complies there’s no problem.”

Hate to break it to you: Obviously that first action item is not working. That’s precisely why we’re talking about the problem. Again. You need to try something different! Examine:

  • Is it easy to break the rule? Is there an incentive to do so? Make it easy to comply
  • Does the first approach really make sense? Do you need to try something completely different?
  • Maybe all that’s missing is a trigger? (See section C)

H – We tried to change issue X – no luck yet

Did you try it in several different ways or just the same way several times? If it’s the latter, try a different way (see previous point G). If it’s the former… There comes a time when you have to accept defeat.

God, give us grace to accept with serenity the things that cannot be changed, courage to change the things which should be changed, and the wisdom to distinguish the one from the other.
Source

The “distinguishing”-part is very hard. How do you know you’ve tried everything? A way that’s often overlooked is whether you can gather data to convince someone. Data gathering is a great intermediate action item.

If you’ve tried several different ways and there’s group consensus that you can’t change that outside factor X, it’s better to accept defeat and explicitly bury the issue. If participants keep bringing it up, it just sucks everyone’s time and energy.

I – Too many action items

In my experience only about 60% of action items are acted on. This seems low and can lead to frustration. Also, the neglected action items are often the more important ones as they are usually harder to do.

A contributing factor to the low rate seems to be that “my” retros often end with many action items (3 – 8). In the future I’d like follow Steve Jobs’ example and put an upper limit on the number of action items to enforce focus:

[Steve] Jobs began taking his “top 100” people on a retreat each year. On the last day, he would stand in front of a whiteboard (he loved whiteboards, because they gave him complete control of a situation and they engendered focus) and ask, “What are the 10 things we should be doing next?” People would fight to get their suggestions on the list. Jobs would write them down—and then cross off the ones he decreed dumb. After much jockeying, the group would come up with a list of 10. Then Jobs would slash the bottom seven and announce, “We can only do three.”

With the next team I’ll try culling all but 3 action items to increase follow-through on the important tasks. Or I’ll go the whole nine yards and follow Jeff Sutherland’s advice:

Identify the single most important impediment at the Sprint Retrospective and remove it before the end of the next sprint. To remove the top priority impediment, put it in the Sprint Backlog as a task with acceptance tests that will determine when it is Done. Then evaluate the state of the story in the Sprint Review like any other task.

J – Um, we’ve got no idea if there’s follow-through

Well, are you happy with your progress? Or is there a “waste of time”-feeling in the air?
If so, start writing down the action items and review them daily or in the next retrospective. A Try-Keep-Board (see image in section C) is a good place to start.

Phew, that was a long one! Thanks for sticking with it 🙂

There’s probably a number of problems still missing. What have you come across? And what did you try in response?

Share this article:

7 Comments Retrospective fatigue? How to increase follow-through on action items

    1. Corinna

      Hi Ben!
      Thanks for the link (and the comment)! I really like the tips you share! In fact, I think I’ll immediately add “perfection game” to the Retr-O-Mat (plans-for-retrospectives.com).

      All the best,
      Corinna

      Reply
    2. Paula Thornton (@rotkapchen)

      Ben: I’d take issue with your ‘root cause analysis’, which on the surface is sound, but in reality is not very practical. In the realm of complexity, there is no ‘root’ cause, but often many contributing factors, no one of them any more or less relevant to the subsequent results than another.

      A better approach is gleaned through the practices of design thinking where all evidences and pursuits of ‘trial’ help to further the ‘understanding’ of the situation — while continuously challenging the current set of assumptions and verifying whether or not the ‘problem’ itself is the ‘right’ one to be solving.

      Root cause analysis is the fodder of engineering. Clearly most of what is happening in agile will have a human on the other end. You can apply root cause analysis to the code, but not to the use or usefulness of the corresponding application. As well, most root cause analysis will mistakenly point back to the ‘user’. User error is a ‘symptom’ of bad design.

      Reply
      1. Ben Linders

        Thanks for your reaction.

        The name “root cause analysis” might give the impression that you should look for 1 cause, but that is not the case. In all the sessions I have done there have been more causes, often a combination of causes. So I fully agree with you! Unfortunately, the most use term is “root cause analysis” and not “root causes analysis”.

        RCA helps you to take a system view, and understand what has happened (and can happen again). The root causes are almost always human, which is both good and bad news. It’s good because, once explored and made visible, people recognize them. But changing human behavior can take some time.

        In my retrospectives I primary look for improvements within the agile team (including the product owner). If there are issues that involve the user, I’d ask the team to find better ways to handle the situation. Which often means that they change the way they collaborate and communicate with current and future users. Would that also have impact on the way that users interact with the team / project? Often yes, but that is up to the users the change their behavior if they discover that that would be more effective. Change triggers change, but the action should start in the team, and be driven by the team members.

        Hope this explains things? Any more questions, feel free to contact me via http://www.benlinders.com/contact/ or @BenLinders

        Reply
  1. Paula Thornton (@rotkapchen)

    I’m only tracking down (and interested in) the clues in retrospection (which are very well outlined here), over my concerns for a ‘living model’. The whole sprint approach to Agile seems to fly in the face of the continuity of a ‘living system’ and entirely ignores all other aspects of ‘care and feeding’ — including feedback loops.

    What modified practices have others put into place to move ‘classic agile with sprints’ into something that is more resilient (embraces living cycles http://www.appartenance-belonging.org/en/resources/the_panarchy_loop)?

    Reply
  2. Pingback: Retros | Pearltrees

  3. Pingback: SAVE | Pearltrees

Leave a Reply

Your email address will not be published. Required fields are marked *