After a Retrospective

Retrospectives are meetings that have outcomes and, as with any well-run meeting, some form of notes has to be taken. Unless you have a scribe available, it will fall to you, as facilitator, to capture the retrospective in some way and distribute the output to the participants and possibly key stakeholders.

Before creating a report, determine who is going to read the report and what they want to do with it. Customize the report to suit the audience. 

For instance some teams are motivated by only bulleted actions items, In this scenario I would recommend including the outputs from previous and current activities so the report tells the whole story.

A report for every retrospective may seem too frequent at first, but each report is a chapter of a bigger story. Each report provides invaluable insights for a retrospective focused on a longer time span, such as a release or an end-of-project retrospective. 

Use the reports to celebrate the team’s progress, overcoming obstacles and embracing continuous improvement.

Wiki’s and Document Applications such as Google Docs, DropBox, Box, and so forth are perfect space to store your notes. This will allow team members to go through previous retrospective reports. 

Teams can compare results and find trends, everyone will also have the ability to  add their own personal take to the retrospective report that you initiate.

Always start your retrospective with a Prime Directive. The Prime Directive in this context prevents people potentially misinterpreting statements. It might be as simple as:

“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”

Everyone always leaves a retrospective with their own view of things. Always take this into account when writing your report. Highlight this distinction to future readers by explaining the context around the notes you record. Be clear that the report reflects your own personal interpretation and offer people a way to correct it if needed.

An example of a disclaimer could be: “This retrospective report reflects my interpretation of the discussions held during the meeting on [insert Date]. If you would like to correct an error or make an addition please contact [insert your Name] on [insert appropriate Contact Details]”

Writing a report is just one step to ensuring that everyone is on a leveling plane. However, If you want your team to take actions you should not only distribute it electronically but find ways to radiate the information where the team can see it daily. 

Some teams track action items on the board as part of their normal work backlog, with a section for outstanding actions. This will include the name of who is currently assigned to each action item, and a due date clearly marked. 

As long as your team has healthy habits in keeping the team wall up to date, putting actions on to the wall will make actions more likely to occur.

This can also be done by pinning these action Items to your team's Slack channel with a regular reminder using a slack bot to list the action items and owners.

Many agile teams run a stand-up every day as a way of synchronizing and distributing information. The most classic format is asking each participant to share, ‘What I did yesterday’, ‘What I will do today’, and ‘Any blockers and who I might need help from.’ 

These brief meetings also provide a useful opportunity to check with all action owners for progress, or for those action owners to share progress with the rest of the team. On a larger team (eg. greater than six) I have seen the stand-up work like this:

• - Normal stand-up runs
• - All owners with actions called together post stand-up
• - Any incomplete action is reviewed with the owner to check if the action is still possible and an expected update.
  

Running a second, shorter stand-up is more effective than running one as a larger group. A second shorter stand-up often provides more focus, this format only works if all actions are distributed across all team members.

Agile methods often give the impression of an ideal, self-empowered team - one where everyone uses their initiative and people take actions without reminders. 

From my perspective most teams are usually very busy with project deliveries and having one-off activities like retrospective actions can be a distraction. 

Ideally Technical Lead, a Project Manager, or some sort of Iteration Manager/Scrum Master should be responsible for ensuring that these action items are completed. These roles are often already tasked with making sure that certain activities are carried out, so it naturally falls to them to remind action owners to complete their commitment.

Leaders should not complete the actions themselves. Reminding action owners of their actions already provides tremendous value. More often than not, a simple reminder well before the due date (and the next retrospective) is the best way to ensure actions are completed. 

Taking time out to chase up actions also offers a good opportunity to discover if there are issues making actions difficult to complete. Team leaders usually have the authority to overcome such issues and to take the steps necessary to progress the action.

When a team has a lot of issues to deal with, a one-off retrospective may not be able to dive deep enough into the problem. 

Ask participants if they would like the next retrospective to have a theme focus so that they can explore issues in greater depth.

In certain cases some issues are better addressed by the people closest to them in a one-to-one, before they are addressed by a larger group. 

After the retrospective, approach the team leaders, point out your observations, and perhaps work with the leaders to book a follow-up session.

Retrospectives generally match the cadence of the team’s iteration around the agile sprint process, so scheduling the next retrospective should be fairly easy. However, scheduling the next retrospective may not be feasible if the team is doing kanban and have not agreed on a regular schedule, or if the team is running out of things to discuss. 

In this case, I would encourage booking in a tentative slot for a retrospective anyway; you can always cancel the booking if it later seems unnecessary. Some teams feel they don’t need retrospective if they don’t have any issues; the magic of retrospectives is that they give insights into things you may not have noticed before. 

If you don’t at least create the opportunity for a retrospective, your team could be missing something special.

Retrospectives generate lots of great ideas and enthusiasm for change. The team that just left your retrospective will benefit significantly from that meeting. Imagine if other teams in your organization benefited from the same lessons and tried some of those improvements in other areas. Encourage the team to share their retrospective lessons with other people through whatever internal forums, mailing lists or slack channels.

Encourage people to do lunchtime or user-group presentations about the changes the team is making and how well they are working out. What is simple or obvious to one group may not be so obvious to another group. 

part of the agile mindset involves continuous learning and helping others to learn. There is nothing more powerful than people talking about their own experiences first hand.