The Retrospective: Working Together to Improve

The Retrospective: Working Together to Improve

This topic contains the following sections.

Insanity: Doing the same thing over and over again and expecting different results.

—Albert Einstein

All Agile methods, whether Scrum, Extreme Programming (XP), or custom, support stopping to reflect on the process on a regular basis. A project retrospective normalizes the team on the issues encountered and provides an opportunity for improvement, which everyone desires.

The inherent flaw with retrospectives and postmortems is they often turn into complaint sessions, and participants leave without a clear plan of attack. This chapter provides a process to eliminate these problems.

First, you’ll give participants time to reflect on the project before the retrospective meeting. Second, you’ll collect opinions from the team before the meeting, aggregate the information, and publish the results back to the team to review before the meeting. Finally, you’ll prioritize the issues identified during the retrospective and post them prominently in the team work area.

In this chapter, we’ll follow the Acme Media pilot team as they perform a project retrospective for the first time. This retrospective will be the last step the pilot team performs in testing the new process. When the retrospective is complete, the core team will review all steps of the new process and then decide how to scale the methodology across the rest of the organization.

You’ve probably participated in a project postmortem or retrospective. We’ve participated in dozens of these meetings, and we’ve rarely seen them obtain optimum results. We believe these meetings don’t go as well as possible for four reasons:

  • The retrospective happens too late, and participants forget the issues encountered.

  • The participants don’t separate personal/performance issues from process issues.

  • Participants aren’t provided enough time to gather their thoughts and observations.

  • The output of the meeting isn’t documented or followed up on.

Over the years, several people have given us advice about how to address these issues; we’ll share them in this chapter.

You can prepare your team for the retrospective by providing guidelines in advance. We use the guidelines outlined in the sample below; they set expectations before you perform the retrospective and get the team thinking about the process and not personal issues.

Your retrospective will have two main objectives, and the guide encourages your participants to start thinking about them:

  • Identify what went poorly so you can address it.

  • Identify what went well so you can repeat it.

Acme Media’s development team will stay together for subsequent projects. When they get a good feel for the behavior expected, they won’t need to review the guidelines before every retrospective.

Conversely, you’ll probably have folks from other departments or teams attend your retrospectives on an ad hoc basis, depending on their level of involvement in the project. Make sure you send the retrospective guidelines to newcomers every time.

NoteNote

You may wonder what is unique about retrospective behavior in an Agile environment versus a traditional environment. In our opinion, there is no difference. No matter how you develop software, you should always strive to be professional in the workplace, avoid blaming individuals, and instead focus on enhancing the development process as a team.

Another critical item during the retrospective is to make it clear that you’re meeting to review the process, not to measure whether the project was successful. You want to know if you have an effective process when you review the project. You aren’t evaluating whether the project is making money, whether your marketing assumptions were correct, or whether you captured your target market. There is a time for such a review, but the retrospective is focused on the methodology.

Sample Project Retrospective Meeting Guidelines

Purpose

  • Define what went well on the project so we can repeat on future projects.

  • Define what didn't work or could have gone better so we can learn from our mistakes and improve on future projects.

  • Document the surprises we encountered so that we watch for these risks on future projects.

  • Improve our development process.

Meeting Preparation

A questionnaire should be filled out by each participant prior to the meeting and sent to the facilitator. It lists specific areas of discussion and asks people to describe what went well and what did not go well on the project. The facilitator should summarize the results and present them to the group to focus the discussion on key areas of success or concern.

Optimal Outcome

Generate a prioritized list of process-specific lessons learned and root causes. Convert highest priority items into action items and delegate for action.

Ground Rules for Meeting

  • When identifying what worked and didn't work, give some thought to the root causes and potential solutions for what didn't work.

  • If you are representing others in this meeting, please get input from them.

  • Respect other people's perspectives-everyone's opinion is valid, even if you may not agree with it.

  • Avoid blaming people for past events. The goal is to learn from mistakes, not to lay blame or find fault. It's easier to look back and identify issues with a project than it is while a team is engaged in the project. Everyone is trying to do their best job under the circumstances.

  • Focus on understanding, learning and looking ahead.

  • Feel free to ask for clarification on what is communicated.

General Topics of Discussion

  • Discuss the questions on the pre-meeting survey, focusing on highest and lowest scores.

  • What was the single most frustrating part of our project? How would you do things differently next time to avoid this frustration?

  • What was the most gratifying or professionally satisfying part of the project?

  • Which of our methods or processes worked particularly well?

  • Which of our methods or processes were difficult or frustrating to use?

  • If you could wave a magic wand and change one aspect about the project, what would it be? What would you like to remain the same?

  • How clearly defined were the objectives for your work?

  • Did you feel adequately involved in the project planning and decisions?

  • Was the project significantly delayed/hampered by outside dependencies?

When team members understand what is expected in the retrospective, a project manager or other team member should survey the team before the retrospective meeting. Surveying the team in advance gives them time to reflect on the project and consider what went well and what can be improved. The survey can also be completed at the convenience of the team member. As a rule of thumb, we like to send the survey out 3 days before the retrospective meeting and give participants 2 days to respond.

Here are some items that make the survey a good tool for project analysis:

  • Scoring. Team members must say whether they agree or disagree. Many surveys allow a neutral answer, and many people choose the neutral answer to be safe. This weakens your ability to determine whether you’re doing well or poorly in a given area. Do allow N/A if a team member didn’t personally participate in a given area.

  • Tailored questions. The questions are tailored to your environment. Acme Media cares about project management, development, and delivery. Other companies may want to focus on cost, speed, or efficiency.

  • Allow supporting comments. The survey lets participants enter supporting comments on each question. These comments will help start the dialogue during the retrospective meeting.

  • Anonymity. Acme Media uses an online questionnaire tool that lets team members respond anonymously. As time goes on, the team will become more comfortable about revealing their thoughts to each other, and anonymity will become less of a need. Figure 22.2 shows Acme Media’s survey.

After the survey results are in, the facilitator can aggregate all the information into a results page and email the results to the team before the retrospective meeting. Team members enjoy reviewing the survey results before going in; the information puts them in the right frame of mind for the meeting.

This is a good time to point out why you do all of this prep work before the retrospective meeting. You’ve probably attended such meetings and witnessed scenes like the following. The facilitator gets everyone together and reorients the team on the project. The facilitator asks people to list things that went well and things that went poorly. One or two people speak up, and the facilitator writes their thoughts on a whiteboard and asks other team members for their thoughts. Eventually, other team members start to chip in as they recall events that happened during the project. With 10 minutes left in the meeting, you start to get good commentary, and the facilitator rushes to get the thoughts on the whiteboard and discuss root causes and potential solutions for the issues. The most important part of the meeting is hurried, and the result is a marginal list of items that went well or poorly. The team will rush to document corrective actions when they should be thoughtful about identifying and resolving the root issues.

The preparatory work we outline in this chapter should get your team engaged in relevant conversation the minute the meeting starts so you don’t have to hurry documenting the main issues and what you’ll do to improve them on the subsequent project.

Figure 22.2 The project retrospective survey covers the main areas of the project. Acme Media chose areas that meant the most to its environment. Your retrospective survey should cover the areas that are important to your team, company, and customer.

Referenced Screen

When the team has reviewed the survey, you can get them together for the retrospective meeting. If you have a team room or shared area, you can conduct the survey there, but sometimes it helps to find a conference room or other venue to prevent distractions.

Most teams have limited time for the retrospective meeting and usually complete it in 60 to 90 minutes. Because time is limited, you should discuss the most important areas first. The most important items to focus on are things you’re doing well and things you’re doing poorly. You can highlight these items in the survey so the team knows you’ll begin with them (see Figures 22.3 and 22.4).

Figure 22.3 The retrospective survey results. A facilitator highlights the areas the team should spend the most time on during the meeting, focusing on areas where the team agrees they’re doing well, where they have issues, and areas where they’re split. The Auctionator retrospective has 10 attendees, so each row totals 10. Each vote equals one attendee.

Referenced Screen

Figure 22.4 Team members can add comments to their survey responses to support their evaluation of a given area. The facilitator can use the comments to jumpstart the retrospective meeting if team members don’t contribute initially.

Referenced Screen

NoteNote

How Frequently Should You Do a Retrospective?

Acme Media chose to do a retrospective at the end of each project, but you may alter the frequency to best support your needs. For example, the Scrum process suggests a retrospective at the end of each sprint, which typically runs 30 days. The end of a sprint may correlate to the end of a project, or it may only tie to one iteration of development work that will eventually support a completed project. Some teams choose to do both: they have a small, quick retrospective after each iteration and then a more detailed review at the end of the project.

You should also consider the size of your project when determining how often to do the retrospective. If your project runs for 4 days and involves two people, a formal retrospective may not be needed. Conversely, if you’re working on a project estimated to run 6 to 12 months, you should identify logical times to stop and review the process.

It’s also good to analyze areas where the team is split. If half the team thinks you did well understanding the customer’s needs and the other half doesn’t, you need to find out where the difference in perception is coming from.

Retrospective meetings tend to take on a mind of their own. Similar to a weathervane in a storm, when several team members are participating, the conversation can go anywhere.

NoteNote

What about the Facilitator?

Picking the correct person as facilitator helps the retrospective immensely. Good characteristics for a facilitator are as follows:

  • Has good communication skills.

  • Has background in analysis or process control.

  • Knows something about the project and its history.

  • Doesn’t intimidate the team. For example, executives frequently have the skills required, but they influence how the team responds.

  • Has the team’s respect.

Facilitators are frequently ScrumMasters, project managers, Agile coaches, or development managers. If the facilitator also worked on the project, they should wait until the team has contributed to the discussion before sharing their own thoughts. This helps the facilitator focus on facilitating and also ensures that the whole team contributes during the meeting.

Many teams try to find someone outside of the project to be the facilitator. This helps maintain a neutral perspective on the issues as they’re discussed, but you may also waste a lot of time orienting the facilitator.

A project retrospective provides insight into the team’s maturity level. A mature team jumps into dialogue immediately and begins to constructively analyze the issues that occurred. The majority of the team participates in the discussions, and analysis of issues doesn’t turn into attacks on individual performance.

Conversely, an immature team is quiet and requires prodding from the facilitator. Long periods of silence may occur until one person speaks up. Others may be uncomfortable sharing their thoughts with the team at large. If your culture isn’t open, and team members aren’t solicited for their opinion, it will take time for them to gain confidence that their thoughts won’t be shot down.

Most teams fall somewhere in the middle. These teams have one or two members who usually do all the talking, a handful of people who speak their mind on occasion, and a few people who almost never speak. Acme Media falls into this category. To provide contrast for your own team, you can see how the pilot team folks behave in Acme’s retrospective in Table 22.1.

Although you have feedback from the team in advance of the meeting, you can expect additional issues to come up when the group discusses the project together.

Table 22.1 A retrospective includes a variety of perspectives and personality types. A good facilitator obtains constructive feedback from all participants and helps the team gel around improvements that should be implemented.

Project role

Name

Retrospective behavior

Project manager

Wendy Johnson

Used to leading process improvements with the team. Wants to contribute to every discussion during the retrospective. Wendy thinks about process issues every day and looks forward to the chance to review them in detail at the retrospective. Wendy is careful to limit her contribution during Acme Media’s first retrospective so that other team members can learn to contribute.

Developer

Roy Williams

Roy was a lead developer at Acme Media for a while and is part of the core team. Roy has always been outspoken and doesn’t like his ideas to be challenged. He contributes freely during the meeting, but the facilitator asks other team members for their thoughts after Roy speaks. Some team members do speak up, and a few have different perspectives than Roy. Over time, Roy will have to learn how to collaborate with the team versus having them acquiesce to his ideas.

Developer

Matt Lee

Matt has a history of being the junior programmer. He’s been quiet in the past but shares his thoughts when the facilitator queries him directly during the retrospective.

User experience

Ryan Getty

Ryan is used to speaking in front of the team and has great skills for being an agile team member. Ryan frequently leads discussions with the team and uses a whiteboard to illustrate designs with the team. He leaves his ego at the door and does a great job of collaborating with the team and aggregating ideas. Ryan speaks up during the meeting but provides space for others to contribute. He also focuses on issues and avoids personal attacks on others.

Quality assurance

Gina Wallace

Testers have been second-class citizens at Acme Media for a while, and Gina had given up on suggesting ideas that were always disregarded. The new agile process gives her hope, though, especially because testing isn’t delayed until the end of the project. Gina contributes in depth during the retrospective and finds that her previous suggestions are in line with the new agile process they’re pursuing.

Operations

Tom Klein

Tom works in a department that doesn’t have plans for using an agile process. As a pilot-team member, he was trained on the new process, but he doesn’t quite get agile yet. Tom is comfortable making suggestions, though, and points out some areas for improvement in the deployment process.

Requirements

Rich Jenkins

Rich is a by-the-book analyst and feels that everything should be documented. During a discussion of missing requirements, Rich blames the new agile process, saying that everything should be documented to prevent misunderstandings in the future. Rich believes the Sunday paper shouldn’t go out until Monday if the quality isn’t perfect.

Architecture

Keith Gastaneau

Keith is a seasoned architect and has learned that agile methods are the best way to deliver software. He takes a Socratic approach to the retrospective and asks the team insightful questions.

Customer

Jay Fosberg

Jay acted as the customer advocate during the project and enjoyed the respect that the customer title received with the new process. But Jay discusses the fact that he may be too involved in the process, in that he was invited to all team meetings and lost time for some of the other work he needed to accomplish on his own.

NoteNote

What about Personal Performance Issues?

We’ve participated in retrospectives where the project was affected by an individual’s poor performance. In these instances, the team could use the meeting to humiliate the employee and discuss how their performance hurt the team, but the retrospective isn’t the place to criticize personal performance.

Employee performance should be addressed by management away from the team. The whole team may realize where a person failed, and they can give the person feedback during the project, but the retrospective isn’t meant to address personal performance issues.

A manager can dig deeper into the performance issue and may also know that the issue relates to a personal issue the employee is experiencing. The manager can create performance plans if needed and also provide a level of tolerance if the individual is experiencing personal problems related to their health, family issues, or substance issues.

After all the issues are documented, the facilitator works with the team to prioritize the issues. It may sound corny and a little like 1980s business philosophy, but the facilitator works with the team to find the root cause of each issue. Similar to identifying a customer’s root need, you must look at each issue and ask “Why?” several times.

During the retrospective, Rich discusses the fact that he had a hard time testing the bidding functionality. The facilitator and the team ask Rich if he didn’t look at the feature card or if he didn’t listen when the customer discussed the feature. Rich said he did listen, but the bidding functionality was complex and he couldn’t keep track of all the permutations.

After digging deeper into the issue, the team identifies two root issues. First, the team isn’t creating feature cards at the correct level of detail. There are several flavors of bidding, such as “buy now” and “expiring bids.” The team should have gone more granular on the feature and created separate cards for the unique functionality of each type of bid.

Second, everyone assumed that feature cards were all you create in an Agile environment. Because face-to-face is the most effective means of communication, the team ran with feature cards and customer discussions. This model didn’t work well for the bidding functionality when Jay, the customer, forgot some of the many business rules involved. It also made it hard for Rich to envision an encompassing test plan.

The team forgot one of their own rules: deciding the level of documentation needed throughout the project. In retrospect, they should have created additional documentation to support the bidding feature and its complexity so that it could be tested thoroughly and to keep everyone in synch with the feature’s details.

Acme Media identifies several additional issues from the project and then sets about documenting action items for improving the process on the next project. Figure 22.5 summarizes the findings and action items. Acme Media will review this list at the end of the next project to see if the team has successfully addressed the key issues.

This list will be reviewed at a subsequent retrospective to validate if the changes were effective.

Figure 22.5 A retrospective ends with a prioritized summary of the key issues and action items to address them. Prioritization helps the team identify the changes that need to happen immediately versus changes that will make a marginal difference in performance.

Referenced Screen

The key points from this chapter are as follows:

  • You should review your development process on a frequent basis to look for areas to improve and as an act of preventive maintenance.

  • You can perform retrospectives after every iteration or at the conclusion of each project, with a goal of reviewing the process at least every 2 months.

  • You need to do pre-work before the retrospective meeting to ensure success.

  • This pre-work includes setting expectations for participants and surveying participants before the retrospective meeting. The pre-work provides the foundation needed to ensure a successful meeting and the early exposure of any issues you may have encountered.

  • Use the pre-work to focus the meeting on the top areas to discuss. You’ll focus on areas where the team is in consensus that there is an issue, where they agree you’re doing well, and where the team is divided about how you’re doing.

  • The retrospective meeting requires a strong facilitator who works well with the various personality types of the team. The facilitator makes sure that no one person dominates and that introverts also express their opinions.

  • The retrospective concludes with a list of prioritized improvements. The improvements are put on display in a visible place: a team-room wall, a project wiki site, or both. You’ll review the output at the subsequent retrospective to see how well you addressed the issues identified.

We’ve put the breadth of our experience into this book, and we hope that what we’ve learned will help you, too. We also hope that you use this book as a reference after reading it. We’ve made the chapter as granular as possible so you can use them as a quick reference.

We’d like to conclude with two of our key thoughts and beliefs.

First, we aren’t agilists for the sake of being Agile. We do embrace Agile principles, and we believe a process focused around Agile principles is the best way to develop software today. But what we mainly care about is developing software by the most effective means possible. Today, the most effective way is Agile; tomorrow, 17 other individuals like the Agile Alliance may meet in Snowbird, Utah, and identify an even better process. If they do, we’ll listen. We’re dedicated to learning and improving every day.

Second, keep your eye on the big picture: making money. The Agile principles tie directly to lowering costs and increasing revenues, but we rarely hear people mention this critical point. You should always be able to explain how your process ties to the bottom line.

Previous article: Release: Final Testing and Support

Return to the top of this topic: Becoming Agile

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.

Show:
© 2016 Microsoft