Retrospectives without concrete action items are pretty much a complete waste of time (and this coming from a guy who thinks the Retrospective is the MOST important discussion in Scrum!!).  Over-and-over again, when I encounter teams and organizations struggling to adopt Scrum and Agile, I often find lame, uninspiring Action Items as one of the contributing factors to poor Agile adoption.  As I review the various exercises in CSP Fast Pass, I have been observing some sad Action Items, so I think it is time to clarify what Jason and I are expecting from you.

The biggest issue I have is that most Action Items do not describe specific, observable and repeatable actions.  IMO, most Action Items fall into the category of what I call “vague, nice sounding ideas” that are impossible to validate or confirm they have addressed the original issue(s) that initiated the Action Item.  Here are some examples that I have collected over the years.

“Take time to analyze the problem as a whole.”

“Try to see how pair programming works for 3 weeks, but not high in priority.”

“Work more closely as team.”

“Shift left – test much earlier in the process.”

“Find balance between the business needs and team.”

“Respect difference of opinions.”

“Focus on the customer.”

“Challenges need to be discussed.”

What does “work more closely as a team”, “take time to analyze the problem as a whole” or “challenges need to be discussed” even mean?  Without clarity and specificity on what actions people are expected to take in order to “shift left”, how can one expect a Scrum Team to make progress on this issue?  If I wanted to make the Action Item “shift left” more specific and concrete, I might write, “Both developers and testers participate in all design reviews” or “Testers work with the Product Owner at the beginning of the Sprint to define acceptance criteria”.  Specificity in this situation includes identifying the time, place and context where the Action Item applies.  IME, the more specific the Action Items, the greater the likelihood they will be implemented.

For me, the best Action Items describe something that is observable.  For instance, “respect differences of opinions” is a great idea for all Scrum Teams but there is no possible way to observe this in action.  It is just an idea or a feeling.  If I wanted to make this Action Item both specific and observable, I might write, “During design reviews, confirm if others want to share their opinion before I respond to comments about my opinion on the topic” or “During Sprint Planning, explain the reasons that support your estimate instead of telling other people why their estimate is wrong”.  If the new behavior in the Action Item cannot be observed, then there is no evidence that the new behavior ever happened.

Additionally, if the new behavior is not a repeatable action, then we cannot say the issue which originated the Action Item has been resolved.  Returning to the Action Item of “work more closely as team”, just because one afternoon, three weeks ago a Scrum Team had one really great Product Backlog refinement meeting, does not mean they are now “working more closely as a team”.  It means that once, they all got along well-enough in order to create shared understanding for, maybe, two hours.  If I wanted to make this Action Item more specific, observable and repeatable I might write, “Everyone will pair [program] two hours each day for the first week of the Sprint and then make adjustments for the second week” or “During the Daily Scrum in the next two Sprints, we will answer the Three Questions for someone else’s work instead of our own”.  For an Action Item to be repeatable it must be a habit, not a one-off event or occurrence.

Additionally, an Action Item must represent something that is important to the people doing the work, otherwise no one will make time to work on the Action Item.  If we look at our examples above, why is “try to see how pair programming works for 3 weeks but not high in priority” if pair programming is not high priority for the Scrum Team?  Did this Scrum Team identify an Action Item about pair programming in order to make themselves feel good by saying they are “doing something” about code quality or did they write this Action Item to appease some other person outside the Scrum Team?  I don’t remember any more, but if the Action Item is not a high priority, there is ABSOLUTELY NO point in writing it down.  That is just Retrospective theater.

Finally, most Action Items I see suffer from a lack of owners.  Owners are the members of the Scrum Team who commit to working on the issue in addition to all the other tasks they need to do in a Sprint.  Given that most Action Items are vague, nice sounding ideas, it is not surprising that most Action Items lack owners.  Who on a Scrum Team would accept responsibility for this Action Item, “find balance between the business needs and team”?  Or if you strengths do not lie in looking at problems holistically, why would you put your name next to an Action Item that says this, “take time to analyze the problem as a whole”?  IME, when Action Items are specific and clear, people will either accept ownership of them or not.  If Scrum Team members do not accept ownership of an Action Item, then do not expect any action to be taken on the issue.

 

 

 

 

 

 

So why spend seven paragraphs and nearly a thousand words on this topic?  Because the only authority a ScrumMaster has in Scrum is to remind people of the commitments they made to one another.  How can a ScrumMaster hold a Scrum Team accountable to an Action Item like “respect difference of opinions”?  Or how can a ScrumMaster give feedback on how well the Scrum Team is doing on an Action Item like “focus on the customer”?  Both of these actions items are so vague, subjective and unclear on what success looks like, that it is impossible to hold anyone accountable for the lack of results or forward progress on these issues.  Well…you could hold someone accountable for these Action Items, but it would be profoundly unfair.

IME, the Action Item is the best tool the ScrumMaster can use to remind people that their participation is needed if they want things to change.   As Chip & Dan Heath say in their book, Switch: How to Change Things When Change is Hard, “For things to change, somebody somewhere has to start acting differently.”  If one is truly interested in continuous improvement, then we must insist upon Action Items that are specific, observable and repeatable actions with clear owners.  Anything less just reinforces the dreary status quo.

Hmmm…it seems that I already wrote about this topic in 2015.  Oh well, I guess it deserved an update based on what I have seen in CSP Fast Pass.