Project Retrospectives are useful when a project spans multiple teams and multiple sprints. During the project I would expect that each team would hold a Sprint Retrospective every Sprint. The Project Retrospective is an additional ceremony that occurs after the project is completed. This could also apply to Release Retrospectives, i.e. a Retrospective for all of the agile teams involved in a multiple sprint release.
What follows are my top tips for running a successful Project Retrospective. i.e. A Retrospective that allows the real issues to be identified and action taken to resolve them.
Tip: Choose the attendees wiselyThe attendees that you invite will have a significant bearing on the issues that are identified and importantly on how successfully those issues will be addressed. I recommend you invite:
• Representatives from all teams involved in the project.
• Representatives from all disciplines involved in the project (e.g. product owner, leaders, project managers, business analysts, developers, testers, designers, architects, support).
• People who will speak honestly in front of management.
• Stakeholders/Management that will hear the issues first hand; then be available to own and resolve those issues. This is crucial to a Retrospective leading to real change.
• As few people as possible, certainly less then 15. To help with this mix up the discipline you invite from the separate agile teams. e.g. Developer from one team, tester from another, business analyst from a third.
Tip: Get all attendees to prepare ahead of the meetingAbout a week ahead of the Retrospective, hand out post it notes to all attendees and ask them to pre-write their thoughts: what went well, what went poorly, what can we improve? This will save a lot of time in the meeting.
You can also get prepared yourself. I recommend researching a timeline of important events from the life of the project (e.g. Customer signs contract, First Release, huge technical issue first identified, original targeted delivery date that was missed, Final Release). Just prior to the start of the meeting you can draw up this timeline on the whiteboard.
Also just prior to the start of the meeting you can write the objective of the meeting up on the whiteboard. Such as ‘Objective: Assign Owners to the Key Issues we identify.’ This will prove useful when discussions in the meeting start to get off track. You can point to the written objective and ask if the current discussion is helping us to achieve our goal?
Tip: Schedule it promptly after the Project endsTiming is crucial. It should not be immediately after the project ends, because some peoples feelings will be raw. It should definitely be within one month of the project end, so that it is still fresh enough in everyone’s memory.
Tip: Use a structured yet simple agendaThe agenda that I recommend is:
• Facilitator provide an introduction [1 minute]
• Gain shared acceptance of the meeting objective [2 minutes]
• Attendees to post their ideas on the timeline & cluster them as appropriate [5 minutes]
• Facilitator lead discussion of the clusters in priority order (large clusters first) [75 minutes]
• Facilitator summarise the issues and owners [5 minutes]
Tip: Focus the meeting on assigning owners to the key issuesWhile facilitating the meeting you should try to focus the discussions on
• Bringing out the issues; and moving towards the root cause.
• Agreeing which issues are the priority issues to be addressed.
• Getting agreement on who in the room should own each issue and hence resolve it.
Tip: Follow up after the meetingSend the list of agreed issues & agreed owners to all of the attendees. You may want to consider posting this in a public location such as a Wiki.
The real key is regularly following up the owner of each issue. You need to ensure that they are working on resolving the issues. Otherwise the whole exercise will have been an expensive whinge-fest.
Retrospectives are meant to lead to Real Change, you can make it happen.
Interested in more tips?
Photo by: Rafael Anderson Gonzales Mendoza