Article: Retrospectives 4 - The Perfect Project Retrospective
A Straightforward Outline of Activities and Approaches for a Successful Retrospective
Bill Hoberecht -
While the concept of a project retrospective is easy to grasp, it is all too easy to fail when trying to implement the concept. Esther Derby and Diana Larsen have literally written the book on retrospectives - here is their five-step approach with some specific tips to get your project teams effectively conducting project retrospectives.
Introducing A Series of Articles on the Perfect Retrospective
Frequent Cycle Execution Opens Opportunities for Improvement
Scrum teams have an advantage that doesn't exist on long term, traditionally managed projects: the benefit of rapid cycle execution. By having short cycles that are frequently executed, the team can develop a fundamental skill and competency that comes from repetition, learning, and adaptation. Teams who are content with their performance miss out entirely on this benefit, while those who want to improve are only a few days away from the next opportunity to improve.
The most important practice used by Scrum teams to improve is the retrospective. This reflection of the team's activity and performance creates an opportunity to have a shared, common view of the just-completed project along with a shared view of some changes that can benefit subsequent projects.
What are Retrospectives All About?
Think of the retrospective activities as being centered around this question:
"How can we work together to improve now, so our next project is demonstrably better?"
The retrospective is a constructive glance at the recent past to enable a better future.
Team members come together, each with their own perspective and insights, to understand one another's view of the project and identify improvement actions. It's not a session to create an explanation for management about a project failure - that would be a typical project post mortem. Nor is a retrospective merely completing a questionnaire so some project manager can figure out how to run the next project - that would be a typical lessons learned activity. It's not a complaint or blaming session either.
The goal of a retrospective is to improve team performance on the project.
Three Important Reminders for a Perfect Retrospective
Here are a few reminders that can make your retrospective exceptionally effective:
- Apply good meeting practices. The basic elements of a meeting can make or break your team gathering. Handle these well and you've started the retrospective on a positive note. Your checklist should probably include these items: provide adequate advance notice of the meeting, create and publish an agenda with suggested preparation tips, secure a good meeting location and room layout, provide an ample supply of materials needed for the activities (white boards, sticky notes, markers), and promote a team norm that each participant will prompt in their arrival.
- Use project data. An early step of the retrospective is coming to a common, shared view of the project performance - project data is one of your most important inputs for this activity. Give ample consideration to the data that are most meaningful to the project team in accurately portraying project performance, from the perspectives of the team members, your customer, other stakeholders and management. Choose an effective way to represent the data for easy consumption and use during the retrospective.
- Select improvement actions that will have real impact. A crucial step in the retrospective is selecting the improvement actions that the team will pursue, and key desired outcomes are to have a sustained and widespread use of retrospective results. Naturally, you'll want to have SMART definitions for your actions. Try these two tests, applied to each proposed improvement action:
- Evaluate the viability (Can this action really be accomplished?) and impact (If we complete this action, will it really improve our project performance? Will it improve the performance of any other project teams?) of each proposed improvement. You can visually represent this evaluation by drawing this grid on a white board and using sticky notes to place each proposed improvement to reflect its score:
- Ask "How will this improvement action be introduced to other projects?" The best improvement actions will be updates to project or organization assets (e.g., training materials, process descriptions, job aids, job descriptions) because these have a better chance of becoming embedded into the core operation of the entire organization. Another very good category of improvement actions is the identification and launch of a new project/sprint/user story that ultimately results in an improved product.
Conducting the Perfect Retrospective
Your project or sprint is nearing its completion and you're looking forward to your first retrospective. Prior to this retrospective, you've ensured that everyone understands the method, you've created a standard agenda (resulting from discussions with team members) and published it in advance, and your team has been trained in the soft skills needed for such an activity.
Retrospectives might appear to be simple, even trivial, to understand, allowing project teams to easily under-estimate the participation and discipline that is required in conducting a successful retrospective. Too many teams that I've encountered have merely gone through the motions and mechanics of a retrospective with little value resulting from that activity.
Below is an outline/checklist of activities for a project retrospective based upon Esther Derby's and Diana Larsen's excellent work in Agile Retrospectives: Making Good Teams Great. While I've added some tips of my own, this is Esther and Diana's five-step model. (Here are a few similar articles by others - these are definitely worth reading as well: Refactoring Your Development Process with Retrospectives, SCRUM Retrospective why is it so important, How we do a retrospective, Effective Retrospectives and Anatomy of a Retrospective)
FIRST: Preparing for the Meeting
- Who: Who should be attending? It generally to comes down to: Should we invite the product owner? How about our management? Make choices based upon whether their attendance will further or hinder achieving the goals of the retrospective. One of the attendees is designated as the facilitator - usually this is the Scrum Master.
- Duration: While some give a guide of one hour (of retrospective meeting time) per week of the iteration, I tend to advocate retrospectives that are much shorter. Learn and adapt from your team's experiences (e.g., if 30 minutes for the previous retrospective wasn't sufficient, try 45 minutes for the upcoming meeting).
- Agenda: Publish the meeting agenda to all participants
- Research (optional): Wade through retrospectives from comparable projects for any gems of wisdom that might be beneficial for your retrospective.
- Pre-meeting input: If you have a project Wiki or discussion board, mine that source for any information that would benefit the retrospective. This is one of your data sources for the meeting.
- Project Performance Data: Assemble data and prepare materials for presentation; this will be the basis for evaluating project performance
- Prior Retrospectives: Locate output from previous retrospectives for this project team - you'll be using this to check on the effectiveness of the chosen improvements and to remind everyone of previously discovered improvement needs.
SECOND: Conducting the Meeting - Examining Performance, Exploring Opinions, Learning
- Set the Stage
- Introduce the goal of the meeting, review the agenda (5 steps) and format (highly interactive!)
- Create new or review existing meeting norms
- If there happens to be an important need to focus on a specific topic, identify that topic and ensure agreement on this limited scope of key focus area (this probably would have already been identified in the published agenda)
- Establish a safe environment for open dialog. You might open with this Safety Exercise; low scores suggest a need to address that issue before moving forward with the next agenda item (possible actions: if management is present, ask them to leave and rerun the exercise, perhaps asking for additional information that would help the team understand the situation).
- Get everyone talking at least once through an introductory question to which everyone is invited to respond. You are in the room so everyone can collaborate, and breaking the ice early in the meeting will enable more involvement by all.
- Gather Data
- Identify the data that will be used, agreeing that these are sufficient, accurate and readily available in this meeting
- Present the project performance data that was assembled prior to the meeting
- Present an evaluation of the effectiveness of previously selected improvement actions.
- Collect additional data. Share and record opinions and observations through a directed exercise (e.g., creating a Timeline). Opinions and feelings are an important consideration in understanding and evaluating project performance.
- Generate Insights
- Discuss and come to a common understanding of the project's performance. Use the data that you have just created and reviewed. Say on this point until you've come to a consensus view - without this basis of agreement, you could have difficulty proceeding.
- What do the data tell us? Now it's time to analyze. Look for indicators of big issues, trends over time if you have historical data for your analysis, confusing or inconsistent information (e.g., product quality and delivery velocity is up but customer satisfaction is down) and significant highlights (e.g., product quality was greatly improved).
- Record your insights. These might be significant observations or proposed improvement actions. My favorite method is writing these on large sticky notes.
- Consolidate your insights. Group the insights into affinity groups - experiment with Mute Mapping (Step 3 on The Art of Agile Development: Retrospectives; watch this one minute video of Mute Mapping) to create groups of similar insights; here's the method: randomly place your sticky notes of insights on the board, then, as individuals, silently move sticky notes into groups. Talk about each group, coming to a common view of the key insights for each group and a name for the group.
- Decide What to Do Now
- Evaluate each group. Utilize a structured method of identifying the significance of the identified problems. Here's one possibility: position each group on the Impact/Viability grid (described and pictured above) to help you decide as a group where to focus your improvement energies.
- Select exactly one improvement area for immediate action and commit to completing this action, using an agreed method (e.g., voting, consensus). This improvement action might come from the evaluation of this currently concluded sprint, or you may elect to choose from your improvement backlog. Ideally, this action would be fully addressed within one sprint. For large actions, identify the series of smaller actions to complete across multiple sprints - these go into your improvement backlog.
- Close the Retrospective
- Recap the collective view of the project performance, top insights and the identified improvement actions - give an opportunity for clarifications or questions if agreement is lacking on any of these items. A successful retrospective will conclude with agreement on these points.
- Consider occasionally running a brief team building exercise as part of emphasizing the importance of team cohesiveness.
- Save the results of the retrospective meeting. This could be as straightforward as taking a digital picture of the sticky notes on the board, or it might involve saving notes taking during the meeting.
- Collect feedback on the retrospective. Offer each participant an opportunity to express their degree of satisfaction or perhaps a suggestion for the next retrospective - this information will occasionally result in the discovery of surprises that can strengthen the retrospective activities.
THIRD: Immediately Following the Meeting
- Add the selected improvement action to the next iteration's sprint backlog.
- Publish the retrospective results to the team and others with an interest. Here's a possible list of information to publish the retrospective to the project Wiki or discussion board:
- The data and analysis information that was created prior to and presented during the meeting
- The data generated during the meeting (This and other information created during the meeting could be published either as pictures taken during the retrospective or as transcribed from notes taken during the meeting)
- The grouping of insights
- The selected improvement actions and expected benefits
- Any updates made to the improvement action backlog.
A popular advertising slogan from long ago was "Try it, you'll like it." Unlike that advertising (which, at its core, was about trying something that wasn't so good and the subsequent remedy), those of us who advocate the widespread use of retrospectives really do believe it is a technique worth understanding, trying and incorporating into all projects. Our support of retrospectives is based upon the observation that having team members directly owning improvement efforts is perhaps the most effective means of improving project performance.
The outline above is a pretty good starting point for structuring your retrospectives. (You'll undoubtedly make some changes and add some detail to suit your needs.) Give retrospectives a try. You'll like them.