Agile Retrospectives.pdf

What readers are saying about Agile Retrospectives Esther Derby and Diana Larsen have written the deﬁnitive book on agile retrospectives. You don’t have to be an agile team to take advan- tage of their book; you only have to want to improve. Follow their advice and your teams will be more successful. Johanna Rothman Author, speaker and consultant, Rothman Consulting Group, Inc. Two of the software industry’s leading facilitators have taken their many years of retrospective experience and distilled them into an approachable reference for agile team leaders. For all of the self-made facilitators out there who have been winging it, this book will pro- vide a solid foundation to improve the effectiveness of your iteration, release, and project retrospectives. Dave Hoover Lead Consultant, Agile Practices, Obtiva Corp. This book is a wonderful compendium of ways to keep retrospectives fresh and teams learning. Mike Cohn Author of Agile Estimating and Planning This book is a must-read for all team leads, facilitators and everyone interested in driving improvements in the ways teams reﬂect, learn and function. Sheila O’Connor, Ph.D. Six Sigma Software Black Belt, LSI Logic, Engenio Storage Group Whatever you call it: retrospective, post-mortem, post-partum, post- project review. Your work can be better by stopping at regular inter- vals and asking, “What worked well that we don’t want to forget? What should be done differently?” It’s almost like free consulting with two of the best: Esther Derby and Diana Larsen. I facilitate retrospec- tives for a living and, believe me, I’m going to read my copy cover to cover—more than once! Linda Rising Co-author of Fearless Change: Patterns for Introducing New Ideas Agile Retrospectives Making Good Teams Great Esther Derby Diana Larsen The Pragmatic Bookshelf Raleigh, North Carolina Dallas, Texas Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and The Pragmatic Programmers, LLC was aware of a trademark claim, the designations have been printed in initial capital letters or in all capitals. The Pragmatic Starter Kit, The Pragmatic Programmer, Pragmatic Programming, Pragmatic Bookshelf and the linking g device are trademarks of The Pragmatic Programmers, LLC. Every precaution was taken in the preparation of this book. However, the publisher assumes no responsibility for errors or omissions, or for damages that may result from the use of information (including program listings) contained herein. Our Pragmatic courses, workshops, and other products can help you and your team create better software and have more fun. For more information, as well as the latest Pragmatic titles, please visit us at http://www.pragmaticprogrammer.com Copyright © 2006 Esther Derby and Diana Larsen. All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmit- ted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. ISBN 0-9776166-4-9 Printed on acid-free paper with 85% recycled, 30% post-consumer content. First printing, July 2006 Version: 2006-7-14 Esther: For my husband, Jeff Lee, who has demonstrated his support in many ways through two books now. Let’s go for three. And for all my friends who help me with a retrospective each year around my birthday. Diana: To Marny, Patty Jo and Marilyn Morningstar; three goddesses who continue to teach me, believe in me, and encourage me to reach for the possible, To Abby, Andy and Willem, who bring me new ideas from the next generation, To Alex, who introduced me to a new way of sharing in family and relationships, With Love and Appreciation. Contents Foreword xi Preface xiii Introduction xvi 1 Helping Your Team Inspect and Adapt 1 1.1 Set the Stage......................... 5 1.2 Gather Data.......................... 8 1.3 Generate Insights...................... 11 1.4 Decide What to Do...................... 11 1.5 Close the Retrospective................... 13 2 A Retrospective Custom-Fit to Your Team 15 2.1 Learning About the History and Environment...... 15 2.2 Shaping the Goal for the Retrospective.......... 16 2.3 Determining Duration.................... 17 2.4 Structuring a Retrospective................. 19 2.5 Selecting Activities...................... 22 3 Leading Retrospectives 28 3.1 Managing Activities..................... 29 3.2 Managing Group Dynamics................. 31 3.3 Managing Time........................ 36 3.4 Managing You......................... 37 3.5 Taking Your Skills to the Next Level............ 38 4 Activities to Set the Stage 40 4.1 Check-In............................ 41 4.2 Focus On/Focus Off..................... 43 4.3 ESVP.............................. 45 4.4 Working Agreements..................... 48 CONTENTS ix 5 Activities to Gather Data 50 5.1 Timeline............................ 51 5.2 Triple Nickels......................... 56 5.3 Color Code Dots....................... 59 5.4 Mad Sad Glad......................... 61 5.5 Locate Strengths....................... 63 5.6 Satisfaction Histogram................... 66 5.7 Team Radar.......................... 71 5.8 Like to Like.......................... 74 6 Activities to Generate Insights 77 6.1 Brainstorming/Filtering................... 78 6.2 Force Field Analysis..................... 81 6.3 Five Whys........................... 85 6.4 Fishbone............................ 87 6.5 Patterns and Shifts..................... 90 6.6 Prioritize with Dots...................... 92 6.7 Report Out with Synthesis................. 95 6.8 Identify Themes........................ 97 6.9 Learning Matrix....................... 99 7 Activities to Decide What to Do 102 7.1 Retrospective Planning Game................ 103 7.2 SMART Goals........................ 107 7.3 Circle of Questions...................... 109 7.4 Short Subjects........................ 111 8 Activities to Close the Retrospective 113 8.1 +/Delta............................ 114 8.2 Appreciations......................... 117 8.3 Temperature Reading.................... 119 8.4 Helped, Hindered, Hypothesis............... 122 8.5 Return on Time Invested (ROTI).............. 124 9 Releases and Project Retrospectives 127 9.1 Preparing for Release and Project Retrospectives.... 128 9.2 Including Cross-Organizational Perspectives....... 133 9.3 Leading Release and Project Retrospectives....... 135 9.4 A Retrospective at Every Ending.............. 141 CONTENTS x 10 Make It So 142 10.1 Provide Support....................... 143 10.2 Share Responsibility for Making Changes........ 145 10.3 Supporting Larger Changes................. 145 A Facilitation Supplies 149 B Debrieﬁng Activities 152 C Activities Quick Reference Matrix 154 D Resources for Learning Facilitation Skills 156 E Bibliography 157 Foreword On my birthdays, I look back and reﬂect on my life. How have things gone? Where did I think I would be thirty years ago, ten years ago, one year ago? Where am I now? How could I do things better, and what things that I rue should I just resolve so I can get past them? Am I the type of person I hoped to be, and is the impact I have on others what I would hope for? If not, what might I do differently in the upcoming year(s)? Have I used the strength and intelligence that I have wisely? This is my retrospective. I look back and assess. I consider. Taking everything into account, I try to set a better course for the upcoming year. I’m really glad that nobody is keeping score, even me, because I don’t know how well I’m doing overall. I guess it depends on philoso- phies that keep changing and on circumstances that bring more vari- ability than I ever expected. Who could have predicted what my chil- dren would be like? Maybe if I had clearer goals and more frequent birthdays, the retro- spectives would work better. I’ll bet that if I had Esther and Diana at my more frequent birthdays, things would work out better. An outside facilitator with techniques like they spell out in this book would provide new insights and help formulate more concrete next steps. I’ve been using iterative, incremental (a.k.a. Agile) processes formally for eleven years; my drink of choice is called Scrum. The goals are very clear in Scrum. They are established for a project and then reset for every iteration. Since these iterations are every thirty days, there isn’t a lot of wandering. Since the domain is building software, not just life in general, it is also easier to tell whether progress is in the right direction or needs adjusting. Because Scrum is a team activity, the group reﬂection is particularly helpful. Everyone chips in, and the surprises are manifold. F OREWORD xii Edward Yourdon described the long, terrible progress through a project in Death March (Prentice Hall, 1997). A problem with these projects is that there are no birthdays and no regular points for reﬂection and readjustment. The natural rhythm of the iterative delivery of software in Agile projects provides such a break point. These are chances for the team to improve what it is doing and how they feel about what they are doing. What an opportunity. Read Esther and Diana’s book and see how it works. Ken Schwaber Scrum Author and Evangelist Scrum Alliance Preface When we say retrospective, here’s what we have in mind: a special meeting where the team gathers after completing an increment of work to inspect and adapt their methods and teamwork. Retrospectives enable whole-team learning, act as catalysts for change, and gener- ate action. Retrospectives go beyond checklist project audits or per- functory project closeouts. And, in contrast to traditional postmortems or project reviews, retrospectives focus not only on the development process, but on the team and team issues. And team issues are as challenging as technical issues—if not more so. We have been leading retrospectives and teaching others to lead ret- rospectives for a combined twenty years. In fact, in 2003, we were bestowed with the title Retrospective Goddesses at the annual Retro- spective Facilitators Gathering in Baden, Austria. It’s not every day you get to read a book written by a pair of goddesses! Although we don’t really claim divinity, we do know lots about helping teams learn together in retrospectives. We’ve talked to people who claim that retrospectives are a waste of time. When we probe for details, the process they describe doesn’t resemble what we would call a retrospective. However, when people follow a process similar to what we describe in this book, we’ve seen solid, bottom-line results. Our clients and colleagues tell us that they see beneﬁts from retrospec- tives, too. Here’s some of what we’ve seen and heard. In each case the team identiﬁed improvements during their retrospective and applied new practices in the next iteration. Improved Productivity A team in California reduced rework at the end of their next release by improving their unit testing. They added more tests and tested more frequently. Because they were ﬁnding errors earlier, they didn’t have to scramble at the end of the release. P REFACE xiv Improved Capability A team in Florida used their retrospective to devise a solution to a long-standing problem. Only one person on the team knew how to integrate client data with the corporate database. The team established a pairing schedule that enabled other team mem- bers to learn about the database and eliminated the bottleneck. Improved Quality A team in Minnesota observed a clear connection between lack of customer contact during their iterations and missed requirements. They increased customer involvement during subse- quent iterations to reduce misunderstandings and rework on features. As collaboration with the customer increased, the team spent less time re-hashing and more time preventing defects and refactoring. Increased Capacity A team in New York examined how they priori- tized features and moved from yearly to quarterly releases by focusing on delivering smaller high-value feature sets. Along with bottom line beneﬁts, retrospectives have a way of increasing empowerment and enjoyment for teams. After performing iteration retrospectives for a year, a team in Lon- don reported that retrospectives had changed their lives for the better. Another team called in a social worker when they faced an especially tough problem. After observing the team, the social worker pointed out that the team had better skills for navigating conﬂict than most of the professional social workers he knew [Mac03]. The team knew how to have the uncomfortable—but necessary—conversations to resolve dis- agreements before they escalated into conﬂict or resentment. We can’t predict the results you’ll achieve, but the evidence shows that retrospectives can improve teamwork, methods, work satisfaction, and results. We want to thank our reviewers for their invaluable help. This book wouldn’t be what it is without them: Tim Bacon, Raj Balasubramanian, Nicole Belilos, Johannes Brodwall, Brandon Campbell, Mike Cohn, Ra- chel Davies, Dale Emery, Marc Evers, Pat Eyler, Caton Gates, David Greenﬁeld, Daniel Grenner, Elisabeth Hendrickson, Darcy Hitchcock, Dave Hoover, Stephen Jenkins, Bil Kleb, Willem Larsen, Anthony Lau- der, Sunil Menda, Sheila O’Connor, David Pickett, Wes Reisz, Linda Rising, Johanna Rothman, Matt Secoske, Guerry Semones, Dave W. Smith, Michael Stok, and Bas Vodde. P REFACE xv We would be remiss if we didn’t thank Norm Kerth. Norm is the elder statesman of retrospectives and has worked to make retrospectives common practice. We’ve both known Norm for years, and in fact, he’s the one who introduced us to each other. We found common ground with Norm in work that each of us was doing independently and, out of that common ground, started the Retrospective Facilitators Gathering in 2001. We want to thank the members of the Retrospective Facilitators Gath- ering. Each year we meet with people who are doing amazing work with retrospectives. At the ﬁrst gathering in Oregon, four countries were represented (Austria, Denmark, the Netherlands and the USA). The 2006 gathering, held in Germany, brought together people from eleven countries. The people of the gathering are generous with their insights, experiences, and activities. Finally, we want to thank Andy Hunt, Dave Thomas, and Steve Peter at the Pragmatic Bookshelf. We couldn’t have done it without you. Introduction Suppose you are a member of a software development team. You’re doing good work, but not great work. You’re starting to see signs of interpersonal friction on the team, and some people you would like to retain on the team are dusting off their résumés. You know you need to adapt your practices and ease the interpersonal tension before things get worse. You want to introduce retrospectives to your team. Maybe you are a team lead, and you’ve heard about retrospectives but have never tried one. You’ve heard retrospectives can help teams per- form better, but you’re not sure where to start. Maybe you’ve been holding retrospectives for months, and your team isn’t coming up with any new ideas. You need a way revitalize your retrospectives so the team doesn’t lose the gains they’ve made. Whatever the reason you’ve picked up this book, we assume you think retrospectives might help your team. Whether you’re a coach, a team member, or a project manager and whether you’re expected to lead retrospectives after every iteration or are initiating retrospectives for the ﬁrst time, you’ll ﬁnd ideas and techniques that you can apply to your situation. Our main focus in this book is short retrospectives—retrospectives that occur after one week to one month of work. Whether you are using Agile methods or more traditional incremental or iterative development, your team has an opportunity to reﬂect at the end of every increment and identify changes and improvements that will increase the quality of the product and the work life of team members. Retrospectives are a natural ﬁt in an Agile work environment—Scrum and Crystal explicitly include “inspect and adapt” cycles for the meth- ods and teamwork along with mechanisms to examine and improve the product. While continuous builds, automated unit tests, and frequent I NTRODUCTION xvii demonstrations of working code are all ways to focus attention on the product and allow the team to make adjustments, retrospectives focus attention on how the team does their work and interacts. Retrospectives are also a natural ﬁt in a team environment—where membership in the team is less than ten and the work is interdepen- dent. Retrospectives help people improve practices, handle issues, and surface obstacles on a regular basis. Iteration retrospectives focus on real problems that affect teams. Dur- ing retrospectives, teams discover real solutions that they can imple- ment without waiting for management’s permission. Since experiments and changes are chosen, not imposed from above, people are more invested in their success. When we started leading retrospectives more than a decade ago, most retrospectives looked at whole projects that had run for a year or more. In the past ten years, there has been a shift. More and more teams are working in shorter iterations and releasing software more frequently. These teams no longer wait until the end of a long project to inspect and adapt. They look for ways to improve at the end of every iteration. Team coaches, team leads, and team members now lead their own ret- rospectives. Even if your team isn’t using Agile methods, you can adapt the advice in this book to inspect and adapt your processes and teamwork before the end of a project: hold a retrospective every month or so or at project milestones. You may need to convince your managers that this is a good use of your time and company dollars. A growing body of data—both ﬁnancial and empirical—shows that consistent retrospectives result in real savings and improvements. In this book, we’ll introduce a structure for retrospectives and walk through the process of planning, designing, and leading a retrospective. We’ll supply activities and guidance on how to use them, and we’ll share stories from real retrospectives. We’ve also included a chapter on the role of the retrospective leader. We believe that most people can lead retrospectives with conﬁdence and competence—and help the team achieve results—with a good structure and the right tools. I NTRODUCTION xviii And, we’ve included examples of how you can adjust the basic retro- spective structure for a three-month release or a yearlong project—and anything in between. Even if the team disbands after the release or project, the organization can learn from a retrospective, and individu- als will take the learning with them. Chapter 1 Helping Your Team Inspect and Adapt Retrospectives help teams—even great ones—keep improving. In this chapter, we’ll start with an example of an hour-long iteration retro- spective. We’ll watch what the retrospective leader does, and then we’ll analyze the example so you can apply the process to your retrospec- tives. Let’s peek in on a team who writes ﬁnancial software as they hold their retrospective at the end of a two-week iteration. This team rotates lead- ership of the retrospective, and this week, it’s Dana’s turn to lead. After all the team members are seated in a semicircle facing a large white board with several posters at one end, Dana starts the retrospec- tive. “Here we are again, taking time to examine our work in the last itera- tion. We have an hour blocked to focus on our teamwork and methods. It’s 4 PM now; we should be ﬁnished by 5. This time, we’re going to focus on our development processes, because we’ve noticed the num- ber of defects is increasing.” “Before we look at the data, let’s do a quick check-in: in a word or two, what’s going on for you as we start this retrospective?” Each of the six team members gave a short response. “I’m puzzled,” said the ﬁrst. C HAPTER 1. H ELPING Y OUR T EAM I NSPECT AND A DAPT 2 “Curious,” said the second. “Bummed about the defects,” answered the third. “Hey, that’s more than a word or two!” said the ﬁrst team member and gave the wordy team member a poke in the arm. “OK. Bummed,” he corrected. The last two gave their responses, and Dana moved on. “Do we need any amendments to our usual working agreements for this meeting?” Dana asked, gesturing to the working agreements posted on the wall. After all agreed the working agreements were sufﬁcient, Dana outlined the process for the meeting. “First we’ll look at our data and then brainstorm and cluster possible causes. After that, we’ll generate some ideas to approach the problem in our next iteration, choose one, and design an experiment. Sound OK?” When all agreed, Dana moved to the next step. “Let’s look at our defect data,” Dana said, pointing to a large chart that showed each feature they’d worked on and the number of defects they’d found in their own testing. “What was going on here?” she asked. “Give me a read on what was going on as you worked on each of these features.” She handed out small, colored sticky notes. “Let’s look at what was going on during the iteration—post the events you remember. Then put an orange sticky note where there was frustration.” “Hmm,” a team member mused as she put the last orange sticky note on the wall. “I’m surprised that the frustration isn’t clustered with the defects. I wonder what that’s about.” “Let’s see whether we can answer that. Take ﬁve minutes to write down everything we know and then see what patterns we can discern.” Dana handed out larger sticky notes and markers. One team member wrote furiously. Another stared at the chart for a minute and then started jotting down notes. Two others talked quietly and compared ideas as they started writing. At the end of ﬁve minutes, team members walked to the white board and stuck their sticky notes on it. “Which of these seem like they might have a similar cause?” Dana asked. Team members moved the sticky notes around, putting two or C HAPTER 1. H ELPING Y OUR T EAM I NSPECT AND A DAPT 3 three close together and then moving them apart as they talked about what was written on each sticky note. At the end of ten minutes, there were four distinct clusters, which the team labeled as follows: inconsistent pairing, too rushed to do test- driven development, code smells, and legacy code. “What do you see here?” Dana asked, starting a discussion of the con- tributing factors. “Which one of these causes is causing most of the defects?” Dana asked. The answer was unanimous: legacy code. “Let’s take a minute to brain- storm experiments we can do in the next iteration to bring the defect rates down.” The team quickly identiﬁed ﬁve different approaches. “Dot vote,” Dana commanded. “Two dots per person; use them any way you want.” In two minutes they had a top choice. “Now let’s design our experiment,” Dana prompted. The team worked for ﬁfteen minutes identifying the action steps requi- red for the experiment: Schedule a walk-through with Sally from the Support group (she worked with this code for years). Write unit tests for the area of legacy code we’re touching. Enlist Sally to pair with us one or two mornings a week. Dana looked at her watch. They had ﬁve minutes left. “What about the pairing? We agreed we’d pair four hours a day.” “That’s right, Dana,” a team member responded. “We need to do better on that. I’ll put up a pairing dashboard so we remind ourselves.” “OK, time to wrap up. How will we know we’re succeeding with our legacy code experiment?” Dana asked. “We’ll see fewer defects in this area of the code base,” one team member offered, and the others agreed. “Yep, that’s the acid test.” C HAPTER 1. H ELPING Y OUR T EAM I NSPECT AND A DAPT 4 “We’ll check that at our next retrospective,” Dana said. “Whose turn is it to lead next time?” A hand went up. “You’ll bring the new data, right?” “Thanks for your hard work,” Dana said. “We’ll take these action steps into our planning meeting—which is tomorrow morning at 9 AM.” Let’s review what Dana did in this retrospective. Dana let the group know the purpose, focus, and time allowed for the retrospective. She told them how they would spend their time. She used a brief check-in to allow everyone to speak and reviewed the team’s already established working agreements. Dana reviewed the team’s defect data and then asked about events and areas of frustration. She did this so everyone was considering the same data, rather than only the data each individual knew about. She asked the team to examine facts—the defect data—and feelings—the areas of frustration. Dana led the group to interpret the data and discern patterns. Dana helped the group identify approaches, choose an approach, and plan to achieve a goal related to the focus of the retrospective. Dana ended the session decisively. She conﬁrmed with the group how they would assess progress, and thanked them for their participation. Dana followed a speciﬁc structure: 1. Set the stage. 2. Gather data. 3. Generate insights. 4. Decide what to do. 5. Close the retrospective. Every year at the Retrospective Facilitators Gathering, we learn about new ways and new twists on old ways to lead retrospectives. And we return to this structure because it works for us—and it can work for you. This structure can ﬁt into an hour or expand to three days. You can add variety by adding new activities, but stick to this basic outline—this structure does what a retrospective needs to do. S ET THE S TAGE 5 Figure 1.1: Retrospective steps as part of an iterative life cycle. In this chapter, we’ll look at each phase in the structure. 1.1 Set the Stage Setting the stage helps people focus on the work at hand. It reiterates the goal for the time the team has together in the retrospective. And, it contributes to creating an atmosphere where people feel comfortable discussing issues. Start with a simple welcome and appreciation for people’s investment of time. Restate the purpose of the retrospective and the goal for the session. Remind people of how long you’ll meet. Then ask everyone in the room to speak. When someone doesn’t speak at the beginning of the retrospective, that person has tacit permission to remain silent for the rest of the session. Since the point of the retro- spective is to help the group think and learn together, you need every- one’s participation. This isn’t the time for a long dissertation—or even a short one. (Do the math. If each person on a ten-person team spoke for three minutes, you’d spend thirty minutes just on introductions. Even with a ﬁve-person team, the time adds up.) Ask for a word or two describing a hope for the retrospective. Next, outline the approach for the session. Time is precious, and people want to know that their time will be well spent. Knowing the approach helps establish that this won’t be another aimless meeting. S ET THE S TAGE 6 Every Voice At the end of one retrospective, Brenda piped up. “I’m sur- prised I talked so much.” Others nodded in agreement. “Yeah, Brenda usually keeps quiet. I’m really glad she talked so much this time. She had a lot to say.” “How did you persuade me to talk?” Brenda asked. The answer was simple: the retrospective leader asked her to say her name within the ﬁrst ﬁve minutes. This sounds too simple to be true, yet it works. After you’ve established the timebox, goal, and approach, work to estab- lish an environment where people can bring up difﬁcult topics and have challenging conversations. Team values and working agreements are both types of social contracts that describe acceptable behavior and interactions. We’re not talking about abstract, high-falutin’ statements such as “We value all people equally” (even though you might). We’re talking about working agreements that do real work to help people talk about tough issues, bring up emotional topics, or deliver unwelcome news. If your team has a set of values, use them. Remind them that their values also hold for the retrospective. The team may need to adapt some values so they ﬁt the retrospective. An XP team had named quality, simplicity, teamwork, and courage as their values. A team member asked how the value of simplicity applied to a retrospective. Their coach suggested that simplicity might mean ﬁnding the simplest improvement actions that could possibly work. Others supplied ideas on what quality, teamwork, and courage would look like in the retrospective. Likewise, if your team has working agreements, post them and review them. Adjust the working agreements as needed to apply in the retro- spective. A game development team’s ﬁrst working agreement was “The job of every programming pair is to make sure the code is ready for the next pair.” For the retrospective, the team reinterpreted this as “The job of S ET THE S TAGE 7 every subteam is to have their work ready for the entire retrospective group.” If your team doesn’t have working agreements, develop them now— before proceeding. It’s impossible to anticipate every situation; most groups can address the majority of situations with ﬁve working agree- ments. If you need more than the ﬁngers on both hands to count your working agreements, you have too many. Here’s an example of why you need working agreements at the start of the retrospective: Fran’s cell phone starts ringing just as the group broaches a sensitive topic. At this point, it’s awkward to say, “Don’t answer that phone!” And it feels capricious to people when they learn what the rules are only after they’ve been broken. If your team has a working agreement that says “Mobile phones on silent during meet- ings,” it’s less disruptive to point to the agreement and end the inter- ruption. It also feels more fair to the people in the retrospective. The last thing you want is to look like a petty tyrant when you are leading a retrospective. You get another beneﬁt: working agreements make everyone responsi- ble for civil behavior and collaboration, not just the retrospective leader [Der05]. The ﬁrst time your team develops working agreements in a retrospec- tive, they might spend ten to ﬁfteen minutes on them—but the agree- ments are reusable in future retrospectives and in daily work. TIP: Working Agreements Belong to the Team Ask your team to monitor their working agreements during the retrospective. When your team takes responsibility for their interactions, you can focus on facilitating. As the team develops or adjusts their working agreements, notice what comes up. Working agreements are often a clue to what people are worried about. Here’s a story: as Chris, a tech lead from outside the team, helped establish working agreements with a team who wrote chemical analy- sis software, the group identiﬁed “Everyone participates” as a working agreement. G ATHER D ATA 8 As they started the ﬁrst activity, Chris realized that the group had been worried about Dave, their “star” performer. In the ﬁrst group discus- sion, Dave went on and on giving his perspective. When other team members attempted to join the conversation, Dave dismissed them with a wave and kept talking. Chris supported the team in holding their agreement by recording Dave’s comments and saying “Thank you, Dave; now let’s hear from someone else.” After that, team members were more assertive with Dave. Dave still had a great deal to say, but he didn’t dominate the discussion. The ﬁrst welcome through reviewing working agreements can take as little as ﬁve minutes. Inexperienced retrospective leaders like to skip setting the stage and plow ahead into the “meat” of a retrospective. We never regret spending time setting the stage—and neither should you. “Saving” time by skipping this part costs time later. When people don’t speak early, they may not contribute at all—and may not buy into the team’s insights and decisions. When they don’t know the approach, people have trouble focusing and may take the group on a tangent. Team values and working agreements help keep the conversations and interactions productive. So, don’t skip setting the stage, and don’t skimp on it either. 1.2 Gather Data It may seem silly to gather data for an iteration that lasted a week or two. But when someone misses one day in a weeklong iteration, they’ve missed 20% of the events and interactions. Even when people are present, they don’t see everything, and different people have differ- ent perspectives on the same event. Gathering data creates a shared picture of what happened. Without a common picture, individuals tend to verify their own opinions and beliefs. Gathering data expands every- one’s perspective. Start with the hard data: events, metrics, features or stories com- pleted, and so forth. Events can include meetings, decision points, changes in team membership, milestones, celebrations, adopting new technologies—any event that had meaning to someone on the team. Metrics include burndown charts, velocity, defect counts, number of stories completed, amount of code refactored, effort data, and so forth. Encourage people to refer to team calendars and other artifacts—docu- ments, emails, charts—to add to the picture. G ATHER D ATA 9 Figure 1.2: Carly’s event card with nine green dots, indicating this event was a high point, and one blue dot, showing it as a low point. For an hour-long retrospective, you can ask people to report verbally on data and events or use the team’s task board and big visible charts. When your team looks back more than a week or two, create a visual record using a timeline or data charts. A visual depiction of data and events makes it easier for people to see patterns and make connections. Hard facts are only part of the data. Feelings are at least half the story. Feelings tell what’s important to people about the facts and about the team. Here’s a story about a time when looking at feelings helped a team understand the consequence of keeping their concerns to themselves: Pat’s team created a timeline by posting cards to represent what hap- pened during their thirty-day iteration. They put green dots on events that were high points and blue dots on low points. When all the dots were in place, one card stood out as shown in Figure 1.2. The card had nine green dots and one blue dot. G ATHER D ATA 10 The F Word OK, we’re working with engineers here. They may not want to talk about their feelings. So in retrospectives, we usually don’t ask people how they feel. But we have our ways. Rather than ask directly how people feel, try asking the ques- tion a different way: When were you excited to come to work? When was coming to work “just a job”? When did you dread coming to work? What were the high points? What were the low points? How was it to be on this iteration? When were you [ﬁll in an emotion word—mad, sad, sur- prised...]? Questions like these let people talk about how they experi- enced the iteration without using the F word (“feelings”). Carly confessed that the card and the blue dot were hers. “I felt like I had hijacked the planning session. I can’t believe anybody thought that was good.” “Carly, we knew you were upset, but it wasn’t until you spoke up that we were able to ﬁx the problem.” Several team members revealed they had concerns similar to Carly’s. But because no one was talking about it, no one could solve the issue. Carly’s “outburst” was the key to solving an ongoing problem. Without consciously looking for feelings, this conversation wouldn’t have happened. Creating a structured way for people to talk about feelings makes it more comfortable to raise topics that have an emotional charge. When people avoid emotional content, it doesn’t go away; it goes underground and saps energy and motivation. Or the emotion may come out in a ﬂare of anger, and a ﬂame war won’t help your retrospective. G ENERATE I NSIGHTS 11 Before proceeding to the next phase, do a quick review of the data with the entire team. Ask the team to scan the data you’ve gathered and comment on patterns, shifts, and surprises. Thorough data gathering, and including both facts and feelings, leads to better thinking and action in the rest of the retrospective. Without a shared picture, people are working from a narrow set of data—their own. When people look only at their own data, the team is less likely to commit to changes and experiments. Without feelings data, the team may not address the topics that are most important to them. 1.3 Generate Insights Now is the time to ask “Why?” and begin thinking about what to do differently. When generating insights, the team considers the data to identify strengths and issues from the previous iteration. Lead the team to examine the conditions, interactions, and patterns that contributed to their success. Investigate breakdowns and deﬁ- ciencies. Look for risks and unexpected events or outcomes. It’s easy for people to jump to solutions once problems emerge. First solutions may be correct, but often they’re not. The work of this phase is to consider additional possibilities, look at causes and effects, and think about them analytically. It’s also a time for the team to think together. These insights help the team see how to work more effectively—which is the ultimate goal of any retrospective. Generating insights allows the team to step back, see the big picture, and delve into root causes. When you skip generating insights, your team may not understand how events, behaviors, and circumstances affect their ability to develop soft- ware. Time spent generating insights helps ensure that when your team plans an improvement, it’s one that will make a positive difference. 1.4 Decide What to Do At this point, the team has a list of potential experiments and improve- ments. Now is the time to pick the top items (usually no more than one or two for an iteration) and plan what to do. Your primary job is to D ECIDE W HAT TO DO 12 Reusable Skills The activities and skills teams use to generate insights and ana- lyze the problems in a retrospective apply outside the retro- spective, too. Teams can use these analytical tools to understand technical problems, prioritize stories or requirements, plan a strategy, or drive innovation. For example, a web development team learned a mind- mapping technique during a retrospective. Later, when they experienced friction with their customer, mind mapping helped the team explore options to approach the problem. provide structure and guidance for your team to plan experiments and actions. Sometimes teams come up with long lists of candidate improvements; but too many initiatives can overwhelm you ability to change. Pick one or two experiments for the next iteration. Help your team choose items that they can commit to and that will have a positive effect. If your team is recovering from a change that was stressful, help them choose something less complex this time. Taking action during the retrospective builds momentum. Mike’s team created a new working agreement, “Everyone will pair at least four hours a day,” to address inconsistent pair programming. Jan’s team redesigned their lab and created new check-in procedures. One way to plan for experiments and changes is to create story cards or backlog items. This makes it easier to incorporate improvement plans into the work plan for the next iteration. Holding your retrospective right before iteration planning is ideal. Plan a break—even if it’s only lunch—between the retrospective and the planning session. Whether you ﬁnish planning in the retrospective or incorporate actions into iteration plans, be sure that people sign up and commit to tasks. Without individual commitment, people assume that “the team” will do the task, and no one does it. C LOSE THE R ETROSPECTIVE 13 Avoiding the Do-Nothing Retrospective Teams who identify external groups as the source of their ills and want those people to change end up frustrated. Waiting for other people to change is an exercise in futility. The most pow- erful place to start change is within the team. Even when your team doesn’t have direct control, your team can take action to inﬂuence or change their own response. Change happens in the course of normal work. Teams who believe their retrospectives are a waste of time often keep their improvement plans completely separate from their daily work plans. When the plans are separate, no one ﬁnds time to do the “extra” work. 1.5 Close the Retrospective All good things come to an end, even retrospectives. End the retrospec- tive decisively: don’t let people (and their energy) dribble away. Decide how to document the experience and plan for follow-up. Help your team decide how they’ll retain what they’ve learned from the retrospective. Track new practices with posters or big visible charts. Use a digital camera or hit the Print button on that printing white board to create a visual record. The learnings belong to the team, and team members: not the coach, not the team lead, and not you as the retro- spective leader. The team needs to own them. Close the retrospective with an appreciation for the hard work everyone did both during the iteration and during the retrospective. Before you end, take a few minutes to perform a retrospective on the retrospective. Look at what went well and what you could do differently in the next retrospective. “Inspect and adapt” applies to retrospectives, too. Using this structure—Set the Stage, Gather Data, Generate Insights, Decide What to Do and Close the Retrospective—will help your team do the following: C LOSE THE R ETROSPECTIVE 14 Understand different points of view. Follow a natural order of thinking. Take a comprehensive view of the team’s current methods and practices. Allow the discussion to go where it needs to go, rather than pre- determining the outcome. Leave the retrospective with concrete action and experiments for the next iteration. The structure gives you, as the retrospective leader, a tried-and-true process to help your team inspect and adapt. In the next chapter, we’ll proceed step-by-step through using this structure to create a retrospec- tive that will work for your team. Chapter 2 A Retrospective Custom-Fit to Your Team When we ﬁrst started leading retrospectives, outside facilitators con- ferred with the project sponsor and project manager to determine the goal and approach for an end-of-project retrospective. But if you’re a coach or team lead doing iterative development, you’re probably leading your own retrospectives after each iteration. You may even be rotating the role among team members. In any case, if you are planning and leading a retrospective, you’ll make a series of decisions about the goal, the logistics, and the ﬂow of the session. But before you make deci- sions, investigate. 2.1 Learning About the History and Environment If you’re leading retrospectives for your own team, you probably already know the history and context. Even so, take a second look. Check your assumptions about the team’s history and morale and about the state of the project. If you’re working with a team other than your own, study their context. Scan the team’s work space. Look at the cartoons, white boards, and other artifacts. Notice what artifacts are available and which are miss- ing. Talk to formal and informal team leaders. The information you gather will help you work with the team to choose an appropriate goal. What you observe will give you clues about what questions to ask and what problems the team may be facing. S HAPING THE G OAL FOR THE R ETROSPECTIVE 16 When you talk to people on the team, ﬁnd out about topics such as these: What did this iteration produce? What was the team aiming for? How did the result meet (or not meet) expectations? What’s going on elsewhere in the organization that affects the team as they go into the retrospective? For example, are there rumors of layoffs? Has there been a recent merger? A canceled product? What is the history of previous project reviews? What happened, and what was the follow-up? What are the relationships between team members—how is their work interdependent? What are their personal connections and working relationships? What are team members feeling? What are their concerns or anx- ieties? What are they excited about? What kind of outcome will achieve value for the time invested— both for the retrospective sponsor and the team? How has the team worked with facilitators before? The information you glean by exploring these topics will help you for- mulate a possible goal for the retrospective. It will also help you under- stand the dynamics of the team, and help you establish relationships if you don’t already know people. 2.2 Shaping the Goal for the Retrospective A useful goal helps answer the question, what will achieve value for the time invested? A useful goal provides a sense of why people are investing their time, without predetermining what actions or direction the team will take after the retrospective. A restrictive goal acts as a blinder. Choose a broad goal that leaves open possibilities for your team to think cre- atively about their experiences and discover the insights that are impor- tant to them. Unlike more general goals, here you want to avoid goals that deﬁne a speciﬁc measurable outcome. A goal such as “Determine how to persuade HR to eliminate performance appraisals” blocks con- sideration of other channels for action or other big issues facing your team. D ETERMINING D URATION 17 Here’s a goal that’s broader but still inappropriate: “Determine what went wrong with testing.” A goal like this may send your team in the wrong direction or may open the door for blame. Useful goals for retrospectives include the following: Find ways to improve our practices. Discover what we were doing well. Understand reasons behind missed targets. Find ways to improve our responsiveness to customers. Rebuild damaged relationships. These are just examples. Consider your context, and work with your team to discover a goal that will help your team. “Continuous process improvement” may work for a couple of iterations. After that, it’s stale. Switch to a different goal. After you’ve considered the context, propose a goal to the team. If the team doesn’t buy into the goal, ask the team to describe a goal. 2.3 Determining Duration How long should your retrospective be? It depends. Fifteen minutes can be enough—or not. There’s no set formula. Base the length of the retrospective on four factors: Length of the iteration Complexity (of the technology, relationships with external depart- ments, organization of the team) Size of the team Level of conﬂict or controversy An hour-long retrospective can be enough for a one-week iteration; a half day may be enough for thirty days worth of work. Shortcutting time means cheating results. (Release and end-of-project retrospectives last longer: at least one day and up to four days in some cases.) D ETERMINING D URATION 18 How Long Does it Take to Prepare for a Retrospective? The ﬁrst time you attempt a retrospective that goes beyond ask- ing “What went well?” and “What should we do differently?” it will take time to prepare. How much time? The ﬁrst time, it may take as much time as the planned duration of the retrospective. You’ll need time to determine the goal, decide on logistics, select activities, and prepare to lead the retrospective. For an hour-long retrospec- tive, you may spend one hour preparing. Each time after that, you’ll need less time to prepare. You’ll never get to zero preparation time—that would mean you’re not thinking about it at all. But with practice and a collection of activities you feel comfortable with, you’ll be able to prepare quickly. Likewise, preparing for the ﬁrst full-day retrospective after a release or at the end of the project will need a substantial time investment. This makes sense. If you’re going to ask ﬁve to twenty people to spend a day learning together, you want to make sure you have a session that will make good use of their time and achieve the desired result. Complexity can be about the technical environment, or it can be about relationships. Add more time when there’s bound to be lots of discus- sion. Add more time for more people. When more than 15 people are in the room everything takes longer. Projects that fail and projects beset by politics generate controversy on the team and outside the team. Plan on more time for venting by team members. You can always end the retrospective early if people identify mean- ingful improvements and ﬁnish their plans before the planned end time. There’s no point prolonging the retrospective once the team has achieved the goal. But too much time usually isn’t the problem. If your team produces only superﬁcial insights and shallow plans, it may be that they need more time. S TRUCTURING A R ETROSPECTIVE 19 2.4 Structuring a Retrospective In Chapter 1, Helping Your Team Inspect and Adapt, on page 1, we laid out a structure: Set the Stage, Gather Data, Generate Insights, Decide What to Do and Close the Retrospective. This structure brings in per- spectives from all team members, follows a natural order for processing information, and moves the group toward committed action. You’ve decided how much time you need to achieve the retrospective goal; now what do you do with that time? Here’s how it might work for a two-hour retrospective: Set the stage 5% 6 minutes Gather data 30–50% 40 minutes Generate insights 20–30% 25 minutes Decide what to do 15–20% 20 minutes Close the retrospective 10% 12 minutes Shufﬂe time 10–15% 17 minutes Total 100% 120 minutes You’ll need time to cover all the phases. Plus, people need time to move from one activity to another, so build in “shufﬂe time.” TIP: Time for a Break Take breaks when there is a logical stopping point, when energy drops, or when people express a need. For retrospec- tives longer than two hours, build time for breaks into the schedule. Count on a ten-minute (minimum) break every ninety minutes or so. If you’re doing an iteration retrospective, you may be using your team room. The advantages of using your team room are that the artifacts are all there and it feels like business as usual. This is good, except when it isn’t. Change rooms when you need a fresh perspective—for an abnormal iteration termination, for missing an iteration goal, or for an unproduc- tive conﬂict within the team. Events like these aren’t business as usual (at least we hope not), and moving to a different setting makes that clear symbolically. Changing rooms can even help when your retrospectives have gone stale. Most of us have had the experience of driving or walk- ing a familiar route and arriving at our destination without noticing S TRUCTURING A R ETROSPECTIVE 20 anything along the way. The same process can happen when teams always meet in the same room. Moving to a different room can help people notice different things. Find a room large enough to accommodate your team without crowding. One way to judge the room size is to look at the occupancy rating. Most conference rooms in corporate buildings (and hotel meeting facilities) have one. Ask the facilities person, and choose a room rated for three to four times the number of people you expect to attend if you are in the United States. (Room ratings are different in other parts of the world.) You want enough space so people can move comfortably—they won’t be seated in rows the whole time (we hope they won’t be in rows at all). A circle or semicircle of chairs encourages participation because people can see each other. Classroom or theater-style arrangements stiﬂe par- ticipation. Staring at the back of someone else’s head isn’t conducive to conversation. Tables can be a physical barrier that becomes a psycho- logical barrier. Avoid rooms with an immovable conference table in the middle. That big ol’ table will inhibit creative collaboration. This isn’t a board meeting, after all. Tables arranged in a U-shape with a big gulf in the middle create dis- tance and make it hard to move around. If you have to have tables, make sure you can move them. The key is to move people closer together rather than farther apart and to make it easy for people to see data charts, ﬂip charts, and other information posted during the retrospective. In addition, facilities folks twitch when you start taping over expensive artwork. Whatever furniture arrangement you choose, ﬁnd a room that has one long blank wall to post timelines, charts, and ﬂip chart pages. If you can’t ﬁnd a room with a blank wall, look for alternate ways to hang ﬂip charts: two options are to turn tables [Dav05] on their sides or hang a clothesline [Hin05]. You can also use the open ﬂoor spaces to spread out ﬂip pages so people can walk by and view them. When there’s nowhere else to hang paper, tape it to the windows (but don’t use invisible plastic tape; it’s really hard to remove). Portable white boards are great for capturing small amounts of infor- mation. The downside is that once the white board is full, it’s erased. That’s ﬁne for transient information, but if the team needs the infor- mation for the remainder of the retrospective, use a ﬂip chart. S TRUCTURING A R ETROSPECTIVE 21 Here’s how one retrospective leader thought about a retrospective for his team. The scenario: The team is using some XP practices, though they haven’t been pair programming or holding regular retrospectives. The team is in their sixth two-week iteration. This iteration, they met the iteration goal but only by working overtime—violating their agree- ment to work at a sustainable pace. On top of that, their build system broke during the second week of the iteration. Given how the iteration went, one of the team members suggested that they’d beneﬁt from examining what happened and making changes in the next iteration. The rest of the team agreed. They want to use their ﬁrst retrospective to learn from the mishaps and mistakes of the iteration. Decision: What is the goal? Learn from mishaps on the previous iteration, uncover root causes of those problems. Decision: Who will attend? The team. Decision: How long? Two-and-a-half hours. The ﬁrst retrospective may take longer because we’re unfamiliar with this style of discussion. Also, we’ve been working for twelve weeks and for these issues, we’ll need to look back further than the our previous two-week iteration. Decision: Where do we hold the retrospective? A conference room that can comfortably hold twenty people. People need to be able to move around for small group work. Decision: How will we set up the room? Move the tables to the side of the room. Start seated in a semicircle facing the long wall and then move to the corners of the room for small group work. We don’t want people seated around a conference table. The semicircle will allow everyone to see each other for the initial dis- cussion. We’ll need variety and space for people to move around. S ELECTING A CTIVITIES 22 By now, you should have answers to these questions: What is the context surrounding the retrospective? What is the goal for this retrospective? How long will the retrospective be? Where will we hold the retrospective? What’s the basic structure? 2.5 Selecting Activities After you have the bare bones of the retrospective—the goal, duration, attendees, room, and setup—it’s time to think about activities. Activ- ities are timeboxed processes that help the team move through the phases of the retrospective. Activities provide structure to help your team think together and have several advantages over freewheeling dis- cussion. Activities do the following: Encourage Equal Participation With more than ﬁve people it’s hard for everyone to participate in a conversation. Working in smaller groups makes it more likely that people will hear and be heard. Focus the Conversation Activities have a particular goal that frames the conversation. That reduces (but does not eliminate) the chance of tangential drift. Encourage New Perspectives Activities bring people outside their day-to-day modes of thinking and can encourage new ideas. Activities don’t have to be elaborate or involved to be effective. Examples of activi- ties that are useful in retrospectives include Brainstorming, Voting with Dots, doing Check-Ins, and performing Pair Interviews. Choose activities that support the goal of the retrospective. If there’s no way to discuss the activity that makes a connection between the activ- ity and the work, omit it. We’re not against games and simulations—in fact we use them often—when they serve a purpose and move the retro- spective forward. Icebreakers, energizers, and games that don’t relate to the work don’t ﬁt in retrospectives. There’s only so much time, so don’t waste it with activities that are “just for fun.” Have fun, but have a purpose. S ELECTING A CTIVITIES 23 J. M. Keller, an expert in motivation and learning, developed criteria for evaluating instructional designs. The criteria are Attention, Relevance, Conﬁdence/Competence, Satisfaction—ARCS for short [Kel87]. While you aren’t developing instructional material, you are creating an envi- ronment for learning. The same criteria apply. If you did interviews as up-front work, you may have some clues about which will be relevant to your team. Choose activities that help people stay engaged so they don’t drift off (Attention) and that are relevant to the goal (Relevance). You want activ- ities that people can accomplish successfully (Conﬁdent/Competence). Avoid activities that are designed to make people feel stupid, inept, or set up. People usually become angry when they feel set up and become defensive if they feel they’re looking or acting like dummies. That’s not what you want in a retrospective. Finally, make sure activities ﬁt into the overall design so people think the retrospective is a good use of their time (Satisfaction). Vary activities to keep your team engaged. Follow a pair activity with one that involves a small group or the whole group. Alternate sedentary activities with ones where people move. After a while, the same old activities lose their zest. If you’re bored with an activity, chances are your team is, too. Find new activities to keep your team (and yourself) interested. When people are interested, they’re less likely to fall into habitual thinking—and you don’t want habitual thinking. You want creative thinking. After you’ve been leading retro- spectives for a while, you’ll start making up your own activities. Many activities for generating ideas, analyzing problems, or identifying novel solutions can be adapted for retrospectives. In the meanwhile, we’ve included activities for each phase of the retrospective with step-by-step guidelines (see the “Activities” chapters). TIP: Have a Backup Choose two activities for each stage—one short and one long. Substitute the shorter activity if time is tight. Now, we’ll look at selecting activities for each phase. We’ll pick up the scenario of the XP team who has been working over time to meet goals and whose build system broke down. (Each of these activities is described in detail in the “Activities” chapters that follow.) S ELECTING A CTIVITIES 24 Phase: Set the Stage Activity: Focus On/Focus Off Why? After the opening (review goal, schedule, and working agree- ments), this activity will help establish a mind-set of looking at the issues without assigning blame. We want to foster open discussion. Phase: Gather the Data Activity: Timeline with Color Code Dots Why? The team is looking at a fairly long period of time and this will help them remember what happened in earlier iterations. It will help people see connections between events. Color coding will help us see facts and feeling and will be an efﬁcient use of time. Phase: Generate Insights Activity: Patterns and Shifts Why? I’ll guide the group to recognize and name patterns and signiﬁ- cant events contributing to our current problems. Activity: Fishbone Why? After looking at the patterns, we need to determine root causes. We’ll analyze signiﬁcant events and factors behind the problems. Activity: Report Out and Synthesis Why? We need to share the work from small groups and look for com- mon treads and common causes. Phase: Decide What to Do Activity: Prioritize with Dots Why? We need to identify the top two to three root causes to work on starting in the next iteration. We can’t absorb a long list of changes; we need to work on the things that will make the biggest difference. The next step depends on what the team identiﬁes as the most impor- tant thing to work on. Option 1: Write story cards (Retrospective Planning Game). Why? We can take the story card items into our next iteration planning meeting and incorporate them into the rest of our work. S ELECTING A CTIVITIES 25 Figure 2.1: The retrospective leader’s notes. Option 2: Add working agreements. Why? The team may need some more relevant working agreements (since they’ve been violating the ones they have now), and we can do that right in the session. Option 3: Write a proposal. Why? If the underlying issues can’t be solved in the team, we need to create an inﬂuence strategy to show our manager why it’s important to ﬁx the problem. S ELECTING A CTIVITIES 26 Figure 2.2: Retrospective agenda. The items cover all ﬁve phases of a retrospective. Phase: Close the Retrospective Activity: +/Delta Why? Improve the retrospective. Activity: Appreciations Why? Provide an opportunity for people to acknowledge contributions. We need a lift after a tough iteration and hard work in the retrospective. Note to self: remember to thank the team for their hard work. Figure 2.1, on the preceding page shows the retrospective leader’s notes for the session. Figure 2.2 shows the agenda poster for the retrospec- tive. S ELECTING A CTIVITIES 27 Suppose this design was for your retrospective. You know the goal for the retrospective, how long it will be, where the session will be, who will attend, and the activities you’ll use to help the group think and solve problems together. Now all you have to do is stand up and lead the group. Chapter 3 Leading Retrospectives This chapter is about the role and skills of a retrospective leader. You don’t need to be a professional facilitator to lead an iteration retrospec- tive, but you do need basic facilitation skills. To learn the skills, you need to understand the role, practice, and seek feedback. As a retrospective facilitator you may follow the content, but your pri- mary responsibility is the process. When facilitators talk about pro- cess, they aren’t talking about a heavyweight methodology. Process means managing activities, managing group dynamics, and managing time [Sch94]. Retrospective leaders focus on the process and struc- ture of the retrospective. They attend to the needs and dynamics of the group and help the group reach a goal. Retrospective leaders remain neutral in discussions, even when they have strong opinions. When the content involves your own team, it’s easy to get caught up in the discussion. It’s tempting to jump into an engaging conversation, especially when you care about the topic. But, if you’re immersed in the content, you can’t pay full attention to the process. Wait a beat to determine whether your thoughts are necessary. Most often, your team will do nicely without your input. The risk of giving input is that when the leader jumps in too often, it quashes group discussion. Participants, on the other hand, focus on the content, discuss, some- times disagree (though not disagreeably), and make decisions. Par- ticipants aim toward a goal and manage their own thoughts, feelings, and responses so they contribute positively to the conversations and outcome. M ANAGING A CTIVITIES 29 TIP: When to Offer Content Expertise You may have important content to offer that no one else in the group has. When that happens, tell the team you are leaving the retrospective leader role temporarily to contribute to the discussion. Hand your marker to another team mem- ber to symbolize that you are not in the facilitator role while you participate. (Just make sure you get the marker—and your role—back.) 3.1 Managing Activities Every retrospective design includes activities—such as creating work- ing agreements, building a timeline, brainstorming, and prioritizing— to help the team think together. You’ll need to introduce each activity, monitor the room during the activity, and debrief the activity when it’s done. Most people want to know something about the purpose of an activity before they begin. Give a broad sense of the territory the team will explore without revealing the details of what will happen or specifying what the team will learn. TIP: Introducing Activities The ﬁrst time you use an activity, write a script so that you remember what to say and don’t garble the instructions or leave something out. Once you have your script, practice saying it aloud. Saying the words is different reading them or thinking them. As you hear yourself give the instruction, you’ll notice where you stumble and where even you can’t follow the instructions. Then you can reﬁne your script and practice again. You may not follow the script in the end, but preparing and practicing will help you describe the activity clearly and con- cisely. Here’s an introduction for an activity to re-create the timeline of a release: “To understand our iteration we need to tell the whole story from everyone’s perspective. We’ll create a timeline that shows events M ANAGING A CTIVITIES 30 that happened during the project. After we have a timeline as com- plete as it can be for now, we’ll look for interesting patterns and explore puzzles.” This tells you about the territory of “understand our iteration,” and lists the steps at a high level: “create the timeline,” “look for interesting patterns,” and “explore puzzles.” It doesn’t tell your team exactly what the outcome will be. That’s for the team to create. Most people (even really smart people) can’t absorb detailed instruc- tions for a multipart activity. Give the details for each part, just in time. For the timeline the details of the ﬁrst steps are as follows: “Let’s get into groups of two or three. In your group, brainstorm all the events that took place during the release. An event doesn’t have to be a milestone—it can be anything that happened on the project.” After giving the instructions, ask for questions about the task. Pause. Count to ten. Someone will have a question—wait for it. As the retrospective leader, you have two tasks during an activity: be available to answer questions about the activity, and monitor the room. While the group is working on an activity, listen to the noise level. Lots of conversation is an indication of good energy. It’s also a clue that people are done with a quiet activity or need more time for a discussion activity. For an activity that involves writing or individual work, conver- sational buzz indicates that people are done and have started talking to their neighbor. If it sounds like there’s still lively conversation at the end of a discussion activity, check to see whether people need more time. Of course, the sound of lively conversation may mean that people have ﬁnished the task and are talking about the latest movie. Debrief every activity. A debrief helps your team examine their expe- rience and extract insights. They’ll make conscious connections and form new ideas. Debrieﬁng each activity builds toward the insights and decisions of the retrospective. So, it’s important to debrief. Now how do you do it? Here’s a simple, four-step method to debrief almost any activity [Sta97]: 1. Start by asking for observable events and sensory input. “What did you see and hear?” 2. Ask how people responded to those events and inputs. “What surprised you? Where were you challenged?” M ANAGING G ROUP D YNAMICS 31 3. Ask for insights and analysis with questions, like “What insight do you have about this?” followed by “What does this tell you about our project?” These questions help people formulate their ideas and connect the activity to the project. 4. After you’ve established the link between the activity and the pro- ject, complete the learning cycle by asking group members how they will apply their insights: “What’s one thing you might do differently?” Notice anything familiar about this? If follows the same ﬂow as the retrospective structure (gather data, both facts and feelings; generate insights; and decide what to do). There are lots of other ways to debrief (see Appendix B, on page 152 for additional ideas). This is a good place to start. For a ﬁve- to twenty-minute activity, spend 50–100% as much time on debrieﬁng as on the activity. So for a ten-minute activity, allow ﬁve to ten minutes for debrieﬁng. 3.2 Managing Group Dynamics Most of the time managing group dynamics in a retrospective means managing participation: making sure people who have something to say have the chance and making sure people who have a lot to say don’t dominate. Watch out for people who are talking more (or much less) than others. Make an opening for the quieter team members by asking to hear other opinions. Notice when someone looks as though he or she was about to speak but was cut off. Ask whether he or she has something to say. Create an opportunity without putting people on the spot or demanding an answer [Der03a]. To draw out quieter people, try saying something like “We haven’t heard Leigh and Venkat yet. What would you add?” Be willing to accept a pass. If someone just won’t shut up, be direct (in private). If you’ve observed the pattern, talk to the person before the retrospective. Describe your observations, and describe the impact on the team—other people have stopped participating. Ask him or her to hold back. If the private conversation doesn’t work, be direct in the retrospective. When one team member is ﬁrst to speak on every question, hold up a hand and say, “We’ve heard from you on every question; let’s hear from some M ANAGING G ROUP D YNAMICS 32 other people.” Keep your tone neutral. An emphatic delivery—“We’ve HEARD from YOU on EVERY question”—conveys blame and won’t help the retrospective. Managers won’t be in every retrospective, but when they are, they are particularly prone to dominating the conversation. It’s not always their fault—if team members hold back when a manager is in the room (for whatever reason), the manager tends to ﬁll the dead air. Meet with managers before the retrospective. Coach them on appropriate partici- pation. Ask them to let others talk ﬁrst, acknowledge the contributions others make, and be careful how they disagree. “I see it differently” preserves participation. Statements like “You’re wrong,” “You just don’t understand,” “You’re not listening to me,” and “I disagree” quash par- ticipation or lead to confrontation. Neither one is good. Here’s how one retrospective leader handled a talkative manager: Rajiv, a project manager was a high-energy, verbal guy. And he was excited about the project. Jess met with him before the retrospective to discuss participation. Rajiv worried he’d forget to wait for others to speak ﬁrst. Jess and Rajiv agreed on a signal: if he spoke out of turn, Jess would walk over and stand next to him. They never used the signal. Just knowing it was there was enough to help Rajiv wait. TIP: Strategies for Helping Your Team Move Forward Sometimes teams become stuck. When that happens, you have options as a retrospective leader. You can help restore their creative juices by asking questions such as these: What have we tried before? What happened? What would you like to happen differently? If we had that, what would we gain? Have you ever tried this a different way? What hap- pened? You can ask for more opinions, especially from people who have been thinking more than talking. You can suggest additional research before committing to a solution. M ANAGING G ROUP D YNAMICS 33 You can take off the retrospective leader hat and offer content knowledge from personal experience. You could tell the team what to do, but only if you want to cheat their learning. After managing participation, the next most common issues are violat- ing working agreements and blaming. Both have negative effects, so you don’t want to let them pass unnoticed. Sooner or later, a team member will violate a working agreement. Hu- mans have good intentions but fall back into old patterns. When they do, remind your team of their working agreements. If you allow vio- lations to continue without comment, team members get the message that working agreements are optional. Optional working agreements have no value. It’s everyone’s job to monitor working agreements. Blame starts a downward spiral of defensiveness and counterblame that will torpedo a retrospective. Listen for “you” language (“You broke the build!”) and labeling statements (“You’re immature!”). Both signal blame. Blame hurts the retrospective by distracting attention from real problems. Encourage “I” language. “I” language centers on the speaker’s observa- tion and experience, rather than labeling the other person. When you hear blame or personal criticism, intervene and redirect the discussion to the content. Here’s how one retrospective leader handled a blame: during the plat- form expansion retrospective, one team member blamed another for breaking the build. “We’d have met our target if it weren’t for you!” “Hold on!” the retrospective leader said, “can you say that using ‘I’? language?” The team member thought for a while and then said, “I am angry that we missed our target because we had so much trouble ﬁxing the build.” Then the team was able to look at bigger issues with the build without blaming one individual. Describe what you’ve seen and heard: “I’m hearing labels and ‘you’ lan- guage.” Describing the behavior causes people to pause and consider what they’re doing. Group dynamics include team member interactions and emotions. You aren’t responsible for other people’s emotions, but as retrospective lea- der, you are responsible for keeping the session productive. And that M ANAGING G ROUP D YNAMICS 34 means you need to be prepared to handle emotional interactions and situations. Most interactions and emotions help the group move forward. Some don’t. Here are some challenging group dynamics and interactions to watch out for—and what to do about them. With any luck you won’t encounter all of these in one retrospective ;-). If outbursts are the rule on your team, something else is happening. Retrospectives can’t solve every problem; if the issue is deeper than normal team friction, contact your HR representative for resources and guidance. When people have been bottling up their emotions, they come out in funny ways: people cry, shout, stomp out of the room, laugh hysteri- cally, or clown when the topic is serious. Before you jump in to ﬁx things, notice your own response. It’s easy to focus on comforting one person and lose track of the goal and the needs of the team. In a retrospective, your primary responsibility is to the interactions of the team as a whole, not to individuals. That doesn’t mean ignoring what’s going on with individual emotions; it means deal- ing with emotions in a way that is helpful and respectful to the team and the individual. Here are some strategies that have worked for us and can work for you. Having a mental picture of how you’ll respond gives you more options in the moment. So, think of the outburst that scares you the most, and mentally rehearse using one of these strategies. Outbursts are unset- tling, but they don’t have to derail the process. If you think you could never do something like this, remember that one of the Retrospective Goddesses started out as a programmer. Tears Offer a box of tissues. When the person is able to speak, ask, “What is happening for you? Can you share it with the group?” Pause. Given time, the person often shares something heartfelt (and usually relevant) about the topic under discussion. Shouting In most places, when someone starts shouting, the rest of the people in the room stop participating. And that makes it unproduc- tive for everyone. Intervene immediately. Hold up one hand as a stop sign, and say calmly but forcefully, “Hold it.” Then say, “I want to hear what you have to say, and I can’t when you’re shouting. Can you tell us why without shouting?” Don’t be surprised if the person responds, “I’m not shouting!” When someone is upset or excited, he or she may M ANAGING G ROUP D YNAMICS 35 not be aware of the rising vocal volume. There’s no need to say “Yes, you are.” Calling attention to the yelling is usually enough to stop it. If your team member continues to blame or yell, call a break, and talk to the person privately. Let him or her know how the behavior is affecting the group. Ask for agreement to express emotion in a nonthreatening way. If the person is unwilling, ask (don’t tell) him or her to leave and return when he or she has more self-control. Stomping Out When a team member stomps out, let him or her go. Ask the team, “What just happened?” They will have an idea. Ask whether it is possible to continue without the person who left. Most of the time, they’ll say they can continue, though they may need to talk about the departure. If this happens more than once, another issue is at play. Talk to the individual outside the retrospective. Inappropriate Laughter and Clowning It is great to have fun in a retrospective. And people may use laughter and humor to deﬂect from a sensitive topic. When the laughter has an edge or your team repeatedly avoids a topic, it’s time to step in. Make an observation, and ask a question: “I’ve noticed that every time we get near this topic, someone tells a joke. What’s happening?” They’ll tell you and engage the topic. Also watch for two other types of situations. They aren’t outbursts, but they are worth noticing. Uncharacteristic Silence When a team that has been voluble goes quiet, something is going on. Again, step in with an observation and a question: “It seems to me that the group is being awfully quiet. There was a lot of energy and conversation earlier. What’s going on now?” Your team may just be tired and need a break. Or they may be unsure how to approach a topic. Once you ask the question, someone will ﬁgure out how to broach the topic, and the proverbial dam will burst. Of course, the fact that a team goes quiet may not mean anything. They may be thinking, tired, or simply a quiet group. When the silence is sudden or out of character, it’s a clue worth following. Currents Beneath the Surface Fidgeting and intense side conversa- tions may indicate something going on just beneath the surface. Again, ask the group what is going on. They will tell you. Here’s how one retrospective leader handled a sudden disturbance in a retrospective: During an off-site release retrospective for a team build- M ANAGING T IME 36 ing network infrastructure, Lindsey noticed the manager take a call on his cell phone, even though the working agreements prohibited calls. He left. When he came back in the room, he had a quiet side con- versation with one person, then another. Laptops opened. Everyone was still trying to track the discussion in the room, but something was distracting them. Lindsey stopped the discussion and asked, “What’s happening?” A team member explained that there was a crisis back at the ofﬁce and the sales manager wanted them to come back and ﬁx it. They wanted to stay in the session but were distracted by his request and perceived urgency for the customer. Lindsey and the team dis- cussed their options: stop the retrospective and reschedule it, ignore the request, or try to do something from where they were. The team set a timebox for immediate problem solving in the room and then resumed the retrospective. Lindsey didn’t blame anyone for not following the agreements. In most cases, naming the behavior, commenting on it, and asking the group what’s happening will diffuse the situation and shift the dynamic. Whew! After all that, managing time will be easy! 3.3 Managing Time Here’s the rub: when you’re leading a retrospective, you should respond to the needs of the group, and you need to pay attention to time and stay within the timebox all at once. It’s a dilemma. Bring a timepiece that will allow you to time activities. We sometimes lose track of time, so we’ll often jot down the start time so we know when to end an activity. Or you can use a stopwatch to time activities. If you’re working with a group much larger than eight people, you’ll need a way to cue people that it’s time to move to another step. Use a bell, chime, or some other not-too-obnoxious sound when it’s time to come together as a group, debrief, or provide additional instructions for an activity. Yelling over the group isn’t effective and sends the wrong message. Whistling works to gain attention, but not always with the desired effect. Duck calls, cow sounds, and other animal sounds work in groups of less than ten (the sound doesn’t carry in larger groups), but well... they don’t add to your dignity (if you care about such things). When the discussion still has energy yet the time you’ve planned has run out, ask the group what they want to do: “I’m concerned that if M ANAGING Y OU 37 we continue this discussion we won’t meet our end goal. What do you want to do?” The group will refocus and move ahead, or they will tell you this conversation is more important than the original goal. Put the decision in the hands of the group. Usually it’s pretty clear. When it’s not, look for a compromise such as timeboxing the discussion or agreeing to revisit the topic later (in the retrospective or afterward). Be prepared to swap to a shorter activity if time is running short. You still have the responsibility to meet the goal of the retrospective— identify and plan for experiments and improvements. 3.4 Managing You In addition to managing activities, group dynamics, and time, you need to manage you. Staying aware of all these team and interpersonal dynamics may seem overwhelming. The key to managing group dynamics is not technique (although it helps to have strategies) but in understanding and man- aging your own emotional state and responses. If you aren’t managing your own state, no technique or strategy will help. When emotions are high, your team needs someone to stay outside the turmoil. That someone is you, the retrospective leader. If you feel your anxiety or tension rising, take a deep breath. Call a break if you need to do so. Your anxiety is a clue that you need to sort out what to do next to serve the group. Remember, you didn’t cause the emotions in the room, and you don’t have responsibility to make everything and everyone happy and nice. During the break, take a moment to shake out your hands and feet to release tension and get your blood ﬂowing again. Take three deep breaths. This may seem like superﬂuous advice; but when people are tense and anxious, it reduces blood ﬂow to the brain... which reduces the ability to think clearly, which contributes to anxiety and tension. You see the picture. Oxygen to the brain is a good thing. It helps you think. Once your brain is oxygenated, ask yourself these questions: “What just happened?” “How much was inside me, and how much was outside me?” “How did the group get here?” T AKING Y OUR S KILLS TO THE N EXT L EVEL 38 “Where does the group need to go next?” “What are three options I have for next steps?” “What will I offer the group?” These questions will help you re-center. And then you can use one of the strategies for managing group dynamics. As long as you have a strategy, you won’t have to stand there frozen, not knowing what to do. Over time, your comfort in dealing with charged emotional situations will grow. Find a mentor whom you have seen manage emotions in groups. Work with your mentor to gain conﬁdence and learn more options for handling emotional situations. And remember to breathe. 3.5 Taking Your Skills to the Next Level If you enjoy helping groups think together, increase your skills as a facilitator and augment your toolbox. Consider deepening your skills in these areas: Working with activities. There’s an art to developing, introducing, and debrieﬁng activities and simulations to help people think and learn together. In addition to using activities in retrospectives, using activities and simulations is helpful if coaching, teaching, or training is part of your job. Helping groups reach decisions. There’s a huge body of knowledge related to how people really make decisions (it’s not entirely by logic, by the way). You can improve the quality of decision making in your group by knowing what decision process ﬁts the situation and how to help the group converge on a decision. Understanding and managing group dynamics. Learning about people and people in groups is a lifelong study. Your skills in this area will help you build and nurture high-performing groups as well as run a darn good retrospective. Increasing self-awareness. Self-awareness is the foundation of personal effectiveness. You can’t go wrong learning more about yourself and learning how you respond under stress. Gaining awareness of habitual patterns is the ﬁrst step to being able to choose an appropriate response rather than simply reacting. Creating and using ﬂip charts. Don’t use any more of those scrib- bled ﬂip charts that no one can read from more than a foot away! T AKING Y OUR S KILLS TO THE N EXT L EVEL 39 If you work with groups, learning how to present information visu- ally helps the group process information quickly and efﬁciently. These skills apply in many situations, not just retrospectives. Your understanding of group process and your ability to help groups succeed will help you succeed, too. Practice facilitating other kinds of meetings. If you belong to a volun- teer group or some other organization outside of work, offer to facilitate a meeting or subcommittee. It’s low risk and will give you experience. Practice in managing the dynamics of any meeting will pay off in man- aging the dynamics in a retrospective. Observe other people who are effective at leading meetings and work- ing with groups. Watch how they interact with people and how they respond when a session isn’t going smoothly. You may not want to use someone else’s exact words, but you can analyze what you see and adapt it to ﬁt your own style. Practice with feedback is the best way to learn facilitation skills [Der02]. Ask someone you trust (and who has some facilitation awareness) to observe as you facilitate. If you have a speciﬁc area you want to learn about, ask your observer to pay special attention to that aspect of your facilitation. Or you may ask your trusted observer to look for areas where he or she senses you have habits you aren’t aware of. For resources on increasing your facilitation skills, see Appendix D, on page 156. You are probably an expert at what you do now. Facilitation draws on different skills than most of us develop working in software. Facilitation also requires a different perspective. It takes time and practice to feel comfortable with new skills. Give yourself time, manage your expec- tations, and ﬁnd mentors. You’ll inspect and adapt your facilitation, too. Chapter 4 Activities to Set the Stage Setting the stage prepares the team for the work they’ll do in the ret- rospective. Setting the stage can be as simple as reviewing the goal, reviewing the agenda, checking in, and reviewing working agreements. When the group needs to do more work to be ready to work, use these activities. Also see the Temperature Reading activity on page 119 and Figure 8.2, on page 120. C HECK -I N 41 4.1 Activity: Check-In Use this to set the stage in an iteration retrospective. Purpose Help people put aside other concerns and focus on the retrospective. Help people articulate what they want from the retrospective. Time needed Five to ten minutes, depending on the size of the group. Description After welcoming the participants and reviewing the goal and agenda, the retrospective leader asks one brief question. Each person answers in round-robin fashion. Steps 1. Ask one question that each person can answer with a word or short phrase. Here are possible questions: What is one word that describes what you need for yourself from this session? In one or two words, what is happening for you right now? In a word or two, what are your hopes for the retrospective? What is one thing that’s on your mind? Note: If you use this question, also ask what each person needs to do to set the concern aside. Sometimes writing the concern down and putting it in a book or pocket—literally setting it aside—helps people set the concern aside mentally. Coming into this retrospective, if you were a car, what kind of car would you be? Note: you can use many different metaphors with this question— type of animal, hardware, ﬂavor. But be careful not to use a metaphor that will seem frivolous or silly to your team. It’s OK for people to say “I pass” on any question. Even saying “I pass” will make sure their voice is heard in the room. C HECK -I N 42 2. Go around the room listening to each person’s answer. You may thank each person (be sure to thank every person if you do). Refrain from offering evaluative comments such as “good” or “won- derful.” Materials and preparation Prepare and choose a question ahead of time. Examples Some teams identify four to ﬁve emotions words, for example happy, angry, apprehensive, sad, and hopeful. Each team member checks in by reporting his or her emotional state using one of these words. Using this type of check-in is helpful when there has been been conﬂict or failure—because it makes it OK to have strong feelings related to the events of the iteration. F OCUS O N /F OCUS O FF 43 4.2 Activity: Focus On/Focus Off Use this to set the stage in an iteration retrospective. Purpose Help establish a mind-set for productive communication. Help par- ticipants set aside blaming and judgment—and fear of blaming and judgment. Time needed Eight to twelve minutes, depending on the size of the group. Description After welcoming the participants and reviewing the goal and agenda, the retrospective leader describes productive and unproductive com- munication patterns. After describing those patterns, the participants discuss what they mean for the retrospective. Steps 1. Draw attention to the Focus On/Focus Off poster (see Figure 4.1, on the following page) and brieﬂy read through it. 2. Form small groups, with no more than four people per group. Ask each group to take one pair of words to deﬁne and describe. If there are more than four pairs/groups, it’s OK if more than one group has the same pair of words. 3. Ask each group to discuss what their two words mean and what behaviors they represent. Have them describe the impact each would have on the team and the retrospective. 4. Each group reports on their discussion to the whole team. 5. Ask people whether the

Agile Retrospectives.pdf

Related

Transcript

Tags

Upgrade to continue