So,\n how can you increase follow-through and make sure that more action \nitems are carried out? As always it depends on the situation. I’ll \ncover:<\/p>\n\n\n\n
- A – Team can’t agree on action items<\/li>
- B – No one feels responsible for action items<\/li>
- C – Action items are forgotten<\/li>
- D – Action items are too vague, i.e. not actionable<\/li>
- E – Team blames others instead of reflecting on own behaviors<\/li>
- F – Always the same topics and action items<\/li>
- G – No new action item because “we already have a rule for that”<\/li>
- H – We tried to change issue X – no luck yet<\/li>
- I – Too many action items<\/li>
- J – Um, we’ve got no idea if there’s follow-through<\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
A – Team can’t agree on action items<\/strong><\/p>\n\n\n\n
If you don’t have a facilitator, get one or nurture one<\/a>. If you do have a facilitator, the “Facilitator’s Guide to Participatory Decision Making<\/a>” or a training about retrospectives (or moderation techniques) will be beneficial.<\/p>\n\n\n\n
<\/p>\n\n\n\n
B – No one feels responsible for action items
<\/strong><\/p>\n\n\n\n![\"Ass](\"http:\/\/www.sxc.hu\/pic\/m\/n\/na\/nafrea\/1144731_fairy.jpg\")
<\/a><\/figure><\/div>\n\n\n\nEach\n action item does have a name on it, doesn’t it? In the end of each \nretro check all action items and ask for each unassigned one who is \ngoing to take care of it. A single task such as “Write mail to admins \nabout monitors” also needs a deadline. Recurring tasks such as “Pair \nprogram 2 hours per day” are assigned for the whole sprint (or \nindefinitely until the one resonsible transfers responsibility). The \nduty here is to remind everyone to comply. One of my fellow scrum \nmasters lovingly dubbed this role “Arschtrittfee” = “ass kick fairy”.<\/p>\n\n\n\n
![\"\"](\"https:\/\/retromat.org\/blog\/wp-content\/uploads\/image.gif\")
<\/figure>\n\n\n\nIf 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.<\/p>\n\n\n\n
<\/p>\n\n\n\n
C – Action items are forgotten<\/strong><\/p>\n\n\n\n
![\"Try-Keep-Board\"](\"http:\/\/finding-marbles.com\/wordpress\/wp-content\/uploads\/2012\/04\/try-keep-board1.png?w=150\")
<\/a><\/figure><\/div>\n\n\n\nA team might forget action items, even if there’s an ass kick fairy. Countermeasures (simplest first):<\/p>\n\n\n\n
- Increase\n visibility 1 – Action items should – literally – be in everyone’s face:\n E.g. on the sprint board, the door, a Try-Keep-Board (see image), a \nrolling items list, …<\/li>
- Increase visibility 2 – Reminder stickies for each team member with their individual tasks, to stick to their monitor<\/li>
- Introduce a trigger
- Create\n a calendar entry for “once per sprint”-meetings rightaway. It’s easier \nto cancel a meeting you don’t need than to remember and schedule a \nmeeting during “business as usual”.<\/li>
- For continuous tasks such as\n “more pair programming” find a way to remind yourselves daily. E.g. \nmake “check our action items” part of the daily standup.<\/li>
- Alternatively to setting a time trigger, you can define a triggering event<\/em> such as “whenever we’ve got 3 bug tickets”.<\/li><\/ul><\/li><\/ul>\n\n\n\n
In\n some cases, tasks are “forgotten” on purpose, because the responsible \nperson is hesitant to do it. This is rampant with confrontational tasks \nsuch as “Talk to Team Brony about how their late code pushes harm our \ndeployment and testing schedule”. Those are often conveniently \nforgotten. This might help:<\/p>\n\n\n\n
- Deadline – less room for “I’ll do it tomorrow”. Ideally create a calendar entry.<\/li>
- Can someone else take over or accompany?<\/li>
- Talk through the confrontation beforehand and how to handle cruc<\/a>ial confrontations<\/a><\/li>
- Premium solution: Have a company-wide training in communication<\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
D – Action items are too vague, i.e. not actionable<\/strong><\/p>\n\n\n\n
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?<\/p>\n\n\n\nWhat\n are the steps the team will take? Aim for a concrete change in behavior\n – including what will trigger the behavior. Ways to get there:<\/p>\n\n\n\n
- Rob<\/a> asks “What could you do tomorrow in order to realize this?” Something like this is usually my first step.<\/li>
- Talk about SMART goals<\/a> and explicitly check off the different letters for each action item.<\/li>
- 5 Hows (analogue to 5 Whys) an impromptu idea by Lydia<\/a>. I love the idea but have yet to try it.<\/li>
- If it’s a big, important problem maybe a Micro Strategy<\/a> can help.<\/li><\/ul>\n\n\n\n
Examples for concrete action items:<\/p>\n\n\n\n
- “We’ll learn about stories before pulling them – Recurring grooming meeting with PO on Wednesdays 9am”<\/li>
- “We’ll work at most on 2 stories simultaneously – We’ll ensure this during standup (TODO: add to standup-checklist)”<\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
E – Team blames others instead of reflecting on own behaviors<\/strong><\/p>\n\n\n\n
Don’t\n get me wrong, I welcome teams who take initiave and confront others \nabout problematic behavior. But talking about others is often less \nconstructive and more a convenient way to avoid taking responsibility \nand changing oneself. So how do you get a team out of this attitude?<\/p>\n\n\n\n
- A PO and I once did something intervention-like, basically conveying the contents of this blog post<\/a> and it worked.<\/li>
- I stress the “you” more in such teams: “What are you<\/em> going to do about it?”<\/li><\/ul>\n\n\n\n
- <\/li><\/ul>\n\n\n\n
F – Always the same topics and action items<\/strong><\/p>\n\n\n\n
Hm. Is the retro always the same format? Well, that’s what Retromat<\/a> is for.<\/p>\n\n\n\n
<\/p>\n\n\n\n
G – No new action item because “we already have a rule for that”<\/strong><\/p>\n\n\n\n
Sometimes,\n teams deal with a problem early and then never again, although the \nproblem persists. To their minds, they’ve addressed the issue. A \nsentence like the following rings alarm bells in my head: “We have a \nrule for that. If everyone just complies there’s no problem.”<\/p>\n\n\n\n
Hate\n to break it to you: Obviously that first action item is not working. \nThat’s precisely why we’re talking about the problem. Again. You need to\n try something different! Examine:<\/p>\n\n\n\n
- Is it easy to break the rule? Is there an incentive to do so? Make it easy to compl<\/a>y<\/a><\/li>
- Does the first approach really make sense? Do you need to try something completely different?<\/li>
- Maybe all that’s missing is a trigger? (See section C)<\/li><\/ul>\n\n\n\n
<\/p>\n\n\n\n
H – We tried to change issue X – no luck yet<\/strong><\/p>\n\n\n\n
Did\n you try it in several different ways or just the same way several \ntimes? If it’s the latter, try a different way (see previous point G). \nIf it’s the former… There comes a time when you have to accept defeat.<\/p>\n\n\n\n
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<\/a><\/em>
<\/p><\/blockquote>\n\n\n\nThe\n “distinguishing”-part is very hard. How do you know you’ve tried \neverything? A way that’s often overlooked is whether you can gather data\n to convince someone. Data gathering is a great intermediate action \nitem.<\/p>\n\n\n\n
If you’ve tried several different ways and there’s group consensus that you can’t change that outside<\/em>\n factor X, it’s better to accept defeat and explicitly bury the issue. \nIf participants keep bringing it up, it just sucks everyone’s time and \nenergy.<\/p>\n\n\n\n
<\/p>\n\n\n\n
I – Too many action items<\/strong><\/p>\n\n\n\n
In my \nexperience only about 60% of action items are acted on. This seems low \nand can lead to frustration. Also, the neglected action items are often \nthe more important ones as they are usually harder to do.<\/p>\n\n\n\n
A \ncontributing factor to the low rate seems to be that “my” retros often \nend with many action items (3 – 8). In the future I’d like follow Steve \nJobs’ example and put an upper limit on the number of action items to \nenforce focus:<\/p>\n\n\n\n
[Steve] Jobs began taking his \u201ctop 100\u201d\n people on a retreat each year. On the last day, he would stand in front\n of a whiteboard (he loved whiteboards, because they gave him complete \ncontrol of a situation and they engendered focus) and ask, \u201cWhat are the\n 10 things we should be doing next?\u201d People would fight to get their \nsuggestions on the list. Jobs would write them down\u2014and then cross off \nthe ones he decreed dumb. After much jockeying, the group would come up \nwith a list of 10. Then Jobs would slash the bottom seven and announce, \n\u201cWe can only do three.\u201d<\/p><\/blockquote>\n\n\n\n
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<\/a>:<\/p>\n\n\n\n
Identify\n the single most important impediment at the Sprint Retrospective and \nremove it before the end of the next sprint. To remove the top priority \nimpediment, put it in the Sprint Backlog as a task with acceptance tests\n that will determine when it is Done. Then evaluate the state of the \nstory in the Sprint Review like any other task.<\/p><\/blockquote>\n\n\n\n
<\/p>\n\n\n\n
J – Um, we’ve got no idea if there’s follow-through<\/strong><\/p>\n\n\n\n
Well, are you happy with your progress? Or is there a “waste of time”-feeling in the air?
\n If so, start writing down the action items and review them daily or in \nthe next retrospective. A Try-Keep-Board (see image in section C) is a \ngood place to start.<\/p>\n\n\n\nPhew, that was a long one! Thanks for sticking with it \ud83d\ude42<\/p>\n\n\n\n
There’s probably a number of problems still missing. What have you come across? And what did you try in response?<\/p>\n\n\n
PS: Did you know there's a Retromat eBook Bundle? Ready-made retrospective plans for beginners and all activities from Retromat for experienced facilitators. Check out the Retromat books<\/a><\/strong><\/h3>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … <\/p>\n
- Is it easy to break the rule? Is there an incentive to do so? Make it easy to compl<\/a>y<\/a><\/li>
- I stress the “you” more in such teams: “What are you<\/em> going to do about it?”<\/li><\/ul>\n\n\n\n
- A PO and I once did something intervention-like, basically conveying the contents of this blog post<\/a> and it worked.<\/li>
- Talk about SMART goals<\/a> and explicitly check off the different letters for each action item.<\/li>
- Premium solution: Have a company-wide training in communication<\/li><\/ul>\n\n\n\n