No matter what industry you're working on, if you do retrospectives or any kind of post-project evaluation exercise with the purpose of uncovering knowledge and finding out what can be done better next time, this article may be helpful for you.

Quick note: During the rest of this article you'll find the word "Retrospective" being used as a synonym for any kind of inspect & adapt exercise that aims to feedback into your continuous improvement initiatives. You might be using Scrum Retrospectives, Toyota Katas, Improvement Boards, Lean A3, etc. For the sake of simplification I'll put everything into the same bag. I hope you don't mind.

Things we know a lot about

There are several approaches we can use to run effective retrospectives. There are books like the "Agile Retrospectives - Making good teams great" by Esther Derby and Diana Larsen, offering great advice on this matter. All you have to do is to read it and put it in practice within your team. In fact, the method described in the book can be found replicated in hundreds of articles on the internet related to how to run retrospectives. You might have seen them already.

  1. Setting the stage
  2. Gather data
  3. Generate insights
  4. Decide what to do
  5. Close the retrospective

For each of the five steps above you can choose a different activity from a very rich menu of options. There are plenty of resources offering you an easy way to plan each of the 5 steps and pick the most suitable activity for each of them. The resources below I used a lot while preparing for the retrospectives I've facilitated so far:

Recently I published here on my website an article sharing 46 different activities I used during my recent past retrospectives.

As you can see, there's really lots of good resources out there that will help you to get better at running retrospectives. Therefore, I'll not write about that. What I'm sharing on this article is something different.

I believe there's one crucial step missing on this whole process. And this missing step is exactly what will make sure you and your organization get the value you're expecting from retrospectives.

The 6th step - Actively Manage Actions

I'd like to propose a 6th step that from my experience is fundamental to get the real value promised by retrospectives. No matter how well you executed the first five initial steps, that alone won't be enough to really get results.

I believe, both from my experience and from what I've learned from others, that one of the biggest issues with retrospectives is not what we usually focus or write the most about, the execution of it. But, the management of the actions that come out of retrospectives is for me the decisive factor for increasing the results you'll get and create the perception that retrospectives work.

Continuous Improvement or Continuous Retrospectives?

I've heard a lot statements like "Yes, we do continuous improvement here. We do retrospectives". Alright. But what evidence do you have that you're continuously improving? If you can't answer that, all you're doing is "Continuous Retrospectives".

The lack of active management generate negative side-effects

The absence of proper action management will most likely create negative side-effects on your teams. I can offer six very real examples of such negative side-effects to you:

  1. The team lose the belief in retrospectives. You'll start hearing things such as "This is waste of time." or "I hate this meeting", or "It's useless".
  2. Management doesn't see any value from retrospectives. You'll start hearing things such as "I'm surprised, I was expecting that this kind of issue was being solved by your retrospectives".
  3. No idea if the team is improving or not. Just a gut feeling, but no concrete evidence of results. You'll start hearing things such as "I have no clue if teams are improving or not".
  4. Waste of people's time with a meaningless meeting.
  5. Recurrent issues (same or different teams). This may be not noticeable by team members, but as a facilitator, and I can say that from my own experience, it's very common to hear the same issue multiple times on multiple teams even if these teams are only separated by a few meters of distance.
  6. Poor transparency. That's a natural consequence of lack of knowledge sharing, poor usage or lack of a supporting tool to enable transparency.

Retrospective actions must be managed

Continuous improvement actions, like the ones we get out of retrospectives, must be actively managed and included as part of the team's main scope of work, backlog, or whatever approach you use to map the work the team has to accomplish.

Keeping a separate "improvement plan" from the business as usual team's plan is a mistake. In the article "Eight Reasons Retrospectives Fail", Esther Derby wrote the following as the 8th reason.

‌‌8. Keeping a Separate "Improvement Plan"‌‌The most common reason I see for "do nothing" retrospectives is that the team keeps one plan for "real work" and another plan for improvements. Guess what happens to the improvement plan? When the improvement work is considered separately from "real work," it doesn't get done. Improving the team's capability is real work, so put it in the real plan. That way it will be considered when the team makes commitments to working on features and will be in front of the team throughout the iteration. Write a story card for the chosen improvement, and take it into the next iteration planning meeting.

The fact that you or your team consider retrospective actions as second-class type of work, will naturally create a sense of irrelevance. You'll take a look if you have time, or in the great majority of cases, you'll only remember about them a few hours before your next retrospective. This creates frustration everywhere and the impression that this whole retrospective thing doesn't work at all.

Common Ways To Manage Retrospective Actions

There are some approaches we can use to manage retrospective actions. Below I'll discuss some of the most common ones, their pros and cons.

Using Visual Management (Physical Boards)

Visual management is really great and I like it, but it isn't perfect and it doesn't solve all the problems. I initially learned about it while I was getting my introduction to Kanban and later studying the Lean approach. Physical boards are also referred as "Big Visible Information Radiators" which means their key job is to radiate information to the organization, supporting and improving communication and transparency.

The physical board is one of the 3 components of the Visual Workspace explained more in details in the book "Lean Software Development" by Mary Poppendieck.

Visual Workspace. There are  three aspects to a visual workspace – the Kanban card (index card) which  tells people what needs to be done, the Andon, or signal that something  is wrong (eg. lighting up a red light when the build breaks), and big  visible charts which tell everyone how things are going. We also have a  section on this in our book.

Source: https://www.leanblog.org/2006/08/shmula-lean-software-interview-with/

Physical boards are supposed to tell a story, so you can also tell the story of your continuous improvement using them. All you have to do is to separate some space on it for this chapter. Something similar to what's on the picture below.


Source: https://waynedgrant.wordpress.com/2013/03/24/managing-retrospective-actions/

In theory, you can just come by a team area, look at their physical board and get a grasp of the current situation. You won't get details or context, but you'll be able to see the current state. In most of the cases, that's enough to provide a sense of progress and what's going on in the team.

In reality, this proved to not be an easy thing to do as designing the board to tell a story will required some extra effort from the team. Not everyone likes having one extra task: To keep the physical board up to date and tidy. I've seen people totally engaged, disciplined, and committed in keeping the board as a real communication tool for the team but I've seen the opposite extreme as well, people that simply don't care about the board at all.

So, yes, using a physical board can be a good idea and may work, but certainly will required discipline, buy-in, and effort to make it really efficient.

Using Digital Tools

Digital tools are the way to go for some teams. Either because they're working mostly remote or they don't have appropriate space in the office for creating the visual charts and then having the digital version may become more efficient for them.

There are a few tools I know that we can use for this purpose. I'll discuss some of them below.

JIRA


Source: https://scrum-master-toolbox.org/2019/03/tools-for-scrum-masters/making-agile-retrospectives-impactful-a-visualization-tool-by-jeff-campbell/

I've have been using JIRA for more than 3 years now both as a user and as an administrator and I can say that it's not so bad but it lacks on many aspects as well. On JIRA, it's easy to create boards and tickets for everything. What's not easy is to get an aggregated perspective on all these boards and tickets. They may belong to different projects, which will create some trouble to you. Each team may have a different workflow. The fields on the tickets might not be the best ones to properly document retrospective actions and you might not have the knowledge or support to create a custom issue type and custom fields to map your actions.

In summary, it may work but it's very cumbersome. Another issue with JIRA is its notification system. You'll receive lots of e-mails from everywhere and will have to make an extra effort to make sense of everything. From the point of view of communication, it's not the best in class product in my opinion for managing retrospective actions. I still think that something more specifically created for the purpose of managing actions and not tasks will be more suitable in this case.

Trello

It's general purpose tool that offers you projects, lists, cards, etc. It'll have the same issues of providing metrics and a high level perspective on everything. Setup is easier than JIRA, but still will required some effort.

Tip: Trello recently announced an app that reads a picture with post-its and creates one card for each post-it. Definitely a handy tool if you use Trello to document your retrospective actions.

You can read more here: https://blog.trello.com/post-it-notes-app-trello-integration

Retrium

It's a tool designed to support remote retrospectives and it has an action plan feature that allows you to keep track of action created during your retrospectives. It's very limited in terms of what you can do with the actions though, which for me is the negative aspect of this feature. There's a lot of support in the tool for the moment before and during retrospectives but not so much support when it comes to following through the actions. It's not possible to assign an owner for instance to the action or to add more details describing why those actions are relevant for the team so others can understand the context that led to such actions.

There are certainly some challenges when it comes to effectively using this tool on remote sessions as pointed by participants of a survey who shared that:

Brainstorms are the most challenging meetings to follow and participate in when working remotely.
Source: https://usefyi.com/remote-work-statistics/#631

Something new?

There are for sure some digital tools you can use to capture the outcomes of your retrospectives, create an action plan and do some level of management on actions there. I personally don't think they are great mainly because they were not designed for this particular purpose.

Let's take the remote work scenario for instance. Remote work is becoming stronger every year, and that will make the challenge of retrospectives even more complex, not only executing it will be a challenge but also following through the actions and communicating progress will be a challenging problem to solve. The need for a digital tool tailored for supporting managing retrospective actions will be in high demand.

In Conclusion

Takeaways

  • Just doing retrospectives is not enough to succeed with our continuous improvement. Continuous Retrospectives is different from Continuous Improvement.
  • Documenting retrospective's information is time consuming and inefficient in most of the cases.
  • Not including retrospective actions as part of the team's main work is a mistake that will hinder your continuous improvement results.
  • Retrospective actions must be actively managed as any other piece of work.
  • The real value of retrospectives lies on the ability to successfully implement the actions that comes out of it.