Blog

I sometimes hear of teams that have stopped doing retrospectives because they didn’t see any improvements. When I talk with them it often turns out that they didn’t have good actions coming out of the retrospectives, or that the actions weren’t done and kept coming back in the retrospective.

No actions leads to no improvement. Here are some suggestions on what you can do to assure that you will have actions from retrospectives that are doable and for getting retrospective actions done.

Agile retrospectives help teams to improve continuously. In the retrospective meeting, the team reflects and decides which actions they will do in the next iteration. During the iteration doing those actions helps the team to improve their way of working and increase their performance.

You can do retrospectives in Scrum or when using Kanban to track and plan the work that the team has to do. Remember to do them frequently so that you will get value out of your agile retrospectives.

Doable actions

Real continuous improvement from retrospectives starts with making the results of the retrospective meeting actionable. If I’m facilitating a retrospective I will make sure that the team leaves the room with actions that they can and will do in the next iteration. Preferable those actions are added to the status board and/or to the backlog, so that they are visible and will not be forgotten.

Doable actions are:

• Small but powerful
• Clear and understandable for all involved
• Formulated so that the benefit is clear

In your actions you should also mention the “why”: the reason that you are doing the action, the problem you expect it to solve, the benefit that team will get from doing it, etc. This will motivate team members to do the action.

Varying the retrospective exercise, although helpful, alone doesn’t solve problems in most cases. It can help you to get better actions, since using different retrospective exercises will give you other insights. Designing your retrospective matters. But you have to make teams aware that being a self organized teams comes with a responsibility to define their way way of working and improve it where needed.

Doing actions

When coaching teams I help them by reminding them and pulling in actions during the iteration. E.g. at the stand-up, when I’m talking with team members, when they are reviewing things, or whatever occasion. I also coach Scrum masters on becoming aware of the actions that they agreed to do, and looking for opportunities during the iteration to do them.

Here’s an example from a team that I worked with. They did a retrospective, and found out that since their were a multi disciplinary team the skills and knowledge where spread out. As Jerry Weinberg’s Law of Raspberry Jam from his book The Secrets of Consulting says: “The wider you spread it, the thinner it gets”. In some cases there was only one person who was capable of doing certain work, which was undesirable to them.

The defined an actions to “do more pairing”. The action itself is still somewhat vague, but we agreed to use any opportunity for people to work together and develop new skills. In this way, the action was doable.

During the iteration the team found a task that was stuck. A piece of software needed to be tested, but the testers were busy testing other modules. A developer mentioned during the stand up that he wants to do it, but has little testing experience. The Scrum master asked the testers if one of them could pair with the developer to help him get started and learn how to do testing. He referred to the action on the task board, reminding the team that this was something that they decided to do in this iteration. One of the testers stepped in, and the two person paired for just a couple of hours.

It turned out that this was more than enough for the developer to do the testing. With some additional questions he was able to finish the task. In next iterations he picked up testing tasks and became better in testing. The team was able to do more testing this way, which helped them to get user stories finished as testing was often a bottleneck.

Always make sure that your improvement actions are visible. This helps to get actions done whenever there is a chance for it.

Follow up

I usually start a retrospective meeting by looking at the actions from the previous meeting, to see if they are finished. If they are not (and I urge teams to define actions that can be done in one iteration) I will ask them what is causing them to be unfinished.

Sometimes there are simply to much actions (where I suggest to do an exercise to come to the vital few actions), or there might be deeper reasons why teams are not able to improve (in which case I suggest to do a Root Cause Analysis to deal with that).

Teams should leave the retrospective with a set of actions that they can do in the next iteration. Taking small steps ensure continuous and sustainable improvement.

Improve continuously

The retrospective is much more than just a meeting at the end of the iteration. It’s about establishing a culture where teams can continuously improve their way of working.

I hope this provides some ideas on how to get actions that are doable, and to get them done. I would like to hear from you! How do you do retrospectives? Do the actions get done? Are you seeing the benefits? Please share your experiences!