A conversation about retrospectives

Brian Hicks:

Every agile coach and agile book worth its salt will preach the benefits of holding regular retrospectives. Most teams I work with do their best to hold them, but many claim they just don’t work. They say this important agile ceremony often turns into a finger-pointing session, or perhaps worse, a meeting where everyone celebrates a job well done while ignoring issues that are holding the team back from being even better.

Probably the single biggest cause that I see of ineffective retrospectives is the lack of clear action items to come out of the meeting. The point of a retrospective is not just to complain about things we don’t like or to congratulate ourselves on the end of a sprint. The goal is to identify opportunities to improve. Sometimes that is stopping bad practices and other times that is doing more of a good practice. Either way, in order to improve you need to make changes. In order to make changes someone has to actually do something. Action items are things for people to do.

At the end of every retrospective, make sure that there are clear activities that individuals are going to do to change the way the team operates. Sometimes these will be individual actions. Other times they may be team actions. Regardless, they need to be clearly captured as a part of the meeting.

I’ve worked with teams that despite doing a great job of creating action items nothing changed. This was usually because they wrote the action items on a white board or a set of sticky notes, agreed to them, congratulated themselves on a successful retro, and then promptly left the items in the room never to be seen again. Make sure you record the action items and store them in a place that is visible and where the team can hold themselves accountable to completing them.

A few tips for managing action items:

• Co-located teams can post the retrospective action items in a visible place within the team room. This way everyone sees them when they are in the room. If you track work on a physical Kanban board, create an action item story and put it in the backlog for the following sprint.
• Use your project management tool (e.g., Jira) to manage the action items. Just like a physical board, create a story for each action item and add it to the team backlog. In Jira, you could even create a custom issue type and track how many action items the team is working on to get a sense of how much time they are spending on improvement activities.
• If you don’t want to create stories, a Wiki that the team uses regularly can be a good alternative. There is a feature that I like in Confluence where you can create individual retrospective pages and add action items to those pages. You can then create a summary page for all the retrospectives that can show all the open action items with either the date or the sprint in which they were opened. That way it is easy to see if the team is letting items linger over time without resolving them.
• However you track the action items, the first thing a scrum master should do at a retrospective is review the open action items from previous retrospectives and discuss why they haven’t been closed.
• One final note is that you can have too much of a good thing. Recently I was asked to facilitate a retrospective for a team who’s previous retrospective had resulted in over 100 action items. They even recorded them and knew where they were. Guess how many had gotten done when I came in about a month later? Basically zero. That many action items was just overwhelming.

Keep your action item list to a manageable number—no more than a handful. Even if you do identify 100 potential items, commit to only the top five or so. You don’t even need to save the others; if they remain important they will come up again at the next retrospective.

When I held that retrospective we had a very healthy discussion but I limited the team to four high-priority action items. Within a week they had tackled at least some piece of each of them, a vast improvement over zero in a month.

Remember, retrospectives give a team the opportunity to change and improve. Clear, visible, and manageable action items identify what needs to be done to change. Retrospectives without action items mean nothing will change.

Byron Katz:

I disagree with the premise of my esteemed colleague’s thoughtful essay about renewing the focus on creating and handling action items from retrospectives.

Let me be clear about my specific disagreement. While I do agree with him on the value of action items, I believe that the lack of action items, and the lack of execution on them, is a symptom, rather than a cause, of a deeper and crucial problem. We should refocus our time and energy on solving that.

Most people are good at determining when they’re doing something potentially dangerous—like writing a retort of a colleague’s essay on the company blog. In most cases, the retrospective is a dangerous activity; the outcome of suggesting improvements is often a net negative. If we make a suggestion without considering the political ramifications, or try taking on more than we can do in the already stressful circumstances, it might be too much for us or the team.

People are rational enough to either stop suggesting things in the first place or else carry out the actions in a way that minimizes the risk. Approaches may include putting items on an action list no one will carry out (pretty safe: “shows we’re team players”) or not creating an action item list at all. These behaviors are subtle, and thus we commonly focus on the immediately apparent problems, such as a lack of action items, or trying to make the meeting more entertaining.

To be clear, this is not just about psychological safety. Most teams lack control over their choices—neither timing nor budget nor tools nor process. They are expected to deliver too much with insufficient time, commonly operating at a frantic pace, cutting corners and adding technical debt. There are real concerns with committing to action items for which there is no time, or no empowerment to change.

I agree with my colleague’s assessment about seeking out easy improvements. However, the continuous improvement / retrospective space is some of the toughest ground to tread in the agile concept, depending on a combination of empowerment, psychological safety, sufficient time to work, and so on. If we want to improve a retrospective, we must be fearless about focusing on the root problem.

I believe that the lack of action from retrospectives is an intentional and considered choice. From the participants’ perspective, the benefits of doing nothing are clear and paramount. The deep fix would seek to cause that calculus to change. It’s a hard job, but I do suggest that we focus on those opportunities that change the underlying risk-assessment calculus of the team.

If you are the coach or Scrum master, muster up your courage and be seen as going out on a risky limb for the team by taking the list to management and making a clear and forceful case. Make it clear to the team that you are going to argue hard, even to your own detriment. Don’t back down, be a major fighter for change.

Provide a way for the team to anonymously brainstorm ideas in advance. A common problem is that after several years many people are invested in safety, are reluctant to try dangerous things for only a possibility of success, or are even so jaded that they will actively work to halt initiatives.

That said, it behooves us to be mindful of our environment, and when suggesting changes, to be cognizant of any negative impacts from the ripples. Careful timing and scoping of changes can provide a ramp-up to deeper beneficial changes. Here, I am merely saying that we should seek out the all-around win, which considers the effects to parties such as middle management. Wild changes tend to cause harm, but agile embraces making many small and mild changes that can be accommodated over time. Drinking a glass of water is a lot easier than a barrel.

Potentially, the team will start to recognize a visionary leader in their midst and begin to wake up. Unless that leader was fired for insubordination. (Ha ha. ha…)

“And it ought to be remembered that there is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things. Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new.” —Niccolò Machiavelli

The team members have carried out a thoughtful and long-running risk-analysis, and the results are in. A change agent must do something to cause that calculation to change. Insisting they write out action items does not start to touch that.

Brian's retort:

I recently wrote a blog post suggesting that one way to ensure nothing happens as the result of a retrospective is to neglect to capture action items. My colleague and friend Byron Katz offered up a response that suggested a lack of retrospective action is not the problem to be solved, rather it is a symptom of larger problems that won’t be fixed in a retrospective.

I certainly recognize Byron’s concern that teams lacking the discipline to do something as simple as record and track action items in a retrospective are sometimes responding to much deeper organizational problems that leave them unwilling to even try to change. However, I find this position to be overly cynical.

If an organization is as dysfunctional as the one Byron describes in his post, he is certainly correct: no amount of action items are going to save the team or save the change agent’s job. Everyone may as well just move on, agile coaches included.

In my experience, however, the situation is not usually that dire. Teams tend to live somewhere in between nirvana and the absolute clown show that Byron describes. More often than not, they are supported by the organization and are trying to do the right thing, but they aren’t having the success they want.

I have worked with many teams that have the psychological safety and positive morale necessary to affect real change and watched them conduct productive retrospectives with great discussions and ideas for improvement. And yet, nothing changed. The reason, more often than not? No one actually took the time to write down the actions required to implement the improvements, prioritize them, and put them on the backlog to achieve.

It seems so simple on its face that one may conclude that the lack of action items must be due to something more nefarious. I find that in most cases, though, the reason isn’t a team is so beaten down by a toxic organization that they have given up all hope. It’s often one of less dire causes, such as:

• Personalities that like to talk but lack the discipline to take notes
• The team itself has some sort of internal dysfunction unrelated to the organization—a personality conflict between key team members, for example
• Agile teams are busy, and everyone thinks someone else is going to handle it
• The items seemed like such great and obvious ideas it just never occurred to anyone to write them down

Whatever it is, when I start having teams define concrete and executable action items, more of them get done and more visible improvements are made.

All that being said, even in Byron’s example where the organization is so broken that the scrum master must go out on a limb and risk his or her job to fight for the team’s ability to make even incremental improvements, without clear action items coming out of a retrospective, how will the scrum master know what is important to fight for? And how will the team know what the scrum master is doing to fight for them?

I appreciate Byron’s concern, as should we all, for the most dysfunctional of organizations, but I stand by the premise that no matter the level of dysfunction on a team or within an organization, action items are a simple, necessary, and effective way to give the team a fighting chance to make change happen. Are they the end-all and be-all? Certainly not. But I do know that one way to ensure that nothing changes is to have retrospectives that are all talk and no action.