Retrospectives

While most of this section concerns the improvement of team member’s performance, another area, tied strongly to our values of working in the open and inviting discussion, and learning continuously is inspecting, adapting and improving our processes. One of the core ways we do this is through retrospective meetings.

What are they?

In agile parlance, a retrospective is a meeting or workshop in which a recent project is debriefed with a goal of learning for the next iteration.

Projects may have regular retros throughout the development cycle, but there may also be a larger scale retrospective at the conclusion of the process (commonly called a post mortem). At their core they are an inquiry to uncover lessons for the future.

What are they not?

A place for assigning blame.

When do we use them?

Retros can be beneficial in many scenarios, not just client projects. We can use them to evaluate processes, experiences, or systems as well.

Scrum teams use retros at the end of a sprint to help facilitate improvements to the delivery process, improving each iteration. They also occur at the end of a project to evaluate learning from end to end (sales to launch, or conception to delivery) of the project process .

Project retrospectives may be useful for client projects, internal ones (we do a retro for the company retreat) and they may be helpful to evaluate a process.

Basically, any situation from which we would like to improve can benefit from inspection, so we can adapt and improve for the future.

Who attends?

Any team who are responsible for the smooth running and continual improvement of the process being used to deliver work.

In the case of the project retrospective, it includes not only the project team but in order to provide perspective on all the parts of the project that HM has touched would include the Sales/Account Manager, and the cloud team (if the project is on our hosting).

Effectively anyone who has an interest in improving sales, delivery, support or processes going forward for that client, future clients, team members, and the company.

Is there a best format?

There are numerous different formats out there for those interested in running retrospectives and the choice of which you use will depend largely on the outcomes you’re looking for.

Examples are:

1. What went Well? | What didn’t go Well? | What did we Learn? | What Actions do we Need to Take?
2. Start | Stop | Continue
3. Liked | Learned | Lacked | Longed For (Known as 4Ls)
4. Mad | Sad | Glad
5. Keep | Add | More | Less (KALM)
6. Sailboat : a visual aid to identify what held us back, what propels us
7. Speedcar : like the above but with more Vroom

In practical terms:

1. The team gathers around a board (or virtual board)
2. Brain dump their thoughts under the headings specified,
3. Group the issues to account for duplication and focus discussion,
4. Vote to prioritise (if there are more issues than you have time allotted for),
5. Discuss as a group to work through the issues with the intent to use what was learned in the project to improve.
6. Document what was learned – priority being action items for learning/growth
7. Assign ownership of actions to ensure that they are moved forward.
8. Facilitator diarises to follow up with the team to ensure actions are, well… actioned.

Given our distributed nature, it’s helpful that much of the information gathering and the adding of items to the board can be done asynchronously allowing for more time available for the actual debriefing and conversation to happen in a synchronous call.

Any Helpful Tips?

1. Schedule the project retrospective from the beginning of the project so the team knows that it will happen.
2. Have it as soon as possible after project completion so momentum and knowledge isn’t lost.
3. It can be helpful to send out a questionnaire before the meeting so people know what to prepare for – e.g.
   • What do you think went well on the project?
   • What was the single most frustrating part of the project?
   • What changes/issues in our process would you like to talk about during the meeting?
   • Were the goals of the project clear to you?
   • Were you given adequate resources to achieve the goals you set?
   • On a scale of 1-5 how complete do you think the project planning was before we kicked everything off?
   • Was the schedule realistic for the deliverables?
   • Anything else this questionnaire didn’t ask?
4. Assign a facilitator/moderator – it’s valuable to have a neutral person who was not involved in the project facilitate it.

The facilitator is responsible for:

• Setting expectations at the top of the meeting
• In discussions, using tools (like 5 why’s) to get to the core of problems rather than just identifying them
• listening more than talking
• Asking quantitative, qualitative, and subjective questions (here are some examples)

Quantitative

• Were deadlines met or missed?
• Did we provide all deliverables outlined in the project scope?
• Were pre-defined success metrics achieved?
• Were outline workflows and processes followed?
• Which of our methods or processes worked particularly well?
• Which of our methods or processes were difficult or frustrating to use?
• Was there a budget overrun?

This is to say, was the plan good? Did we follow the plan? Was the plan bad? If so, why?

Qualitative

• Did we deliver work at the high standards we and our client expected?
• Are you proud of our finished deliverables? If yes, what made them great? If no, what was wrong or missing?
• Does the client agree?
• Did people feel like they had the resources, information, and support they needed to get their own tasks done?
• Were criteria or task expectations poorly defined or communicated?
• Be specific about what worked and what didn’t

Subjective

• How is the team feeling?
• What did people enjoy most and least about this project?
• How was working with the stakeholders?
• What changes would they make to this type of project in the future?
• How could the work run more smoothly with this client or among these departments in the future?
• Do you want to work on a similar type project again? If not, why not?

1. Identify action points and prioritise them
   • What do we absolutely need to do?
   • What do we need to do now?
   • What should we do soon?
   • Who’s going to own this action item?
2. Close the Loop

Follow up, post the results of the questionnaire and the meeting – focus on what changes this brings to the future and the plans being made to bring those changes to pass, don’t just take ownership of the actions, but make a plan for how to implement them? Could they be raised in an agency call for your region? Would what was learned be valuable to the wider team? Would it be better as an H2 post? What’s the plan for getting it posted?

Essentially, what needs to change? Who needs to know it? How do they get that information? What are you going to do about getting that information into the right hands?

Conclusion

Running a retrospective and using what is learned in that process is a key element of implementing our value of learning continuously and growing together, it is a tool we can use to capture our experience and make the experience of working together an increasingly effective and enjoyable one.