Effective Retrospectives

Promoting Continuous Improvement of Agile Teams

by Kendrick Burson

One of our readers asked a very intelligent question:

How to get Optimal Value of a Retrospective ?

 

Is there a set of best practices that we can adopt when conducting team retrospectives?

I am used to facilitating a retrospectives, focusing on what went well, what went less well, what improved and what can we improve.

Is there better facilitating method in getting teams to open out more ?

 

I wish more scrum masters and servant leaders would ask these very same questions. All too often I see teams going thru the motions of team retrospectives while completely missing the point. The retrospective is not a free meeting where the team simply bitch and gripe, or pat themselves on the back. Although these are elements of every retrospective they are definitely not the focus or purpose.

If you want a complete understanding of Team Retrospectives with plenty of examples of different patterns for facilitating this meeting read the book by Esther Derby and Diana Larsen titled “Agile Retrospectives: Making Good Teams Great”. This book, along with many other resources, are listed at the end of this article.

How to get Optimal Value of a Retrospective – Part I

The idea of the retrospective, defined in both eXtreme Programming principles and the Scrum Framework, is that it is a window for teams to inspect and adapt, to learn about what works and what does not work, and to find better ways of working together and with their product owner, ever striving towards the lean principle of kaizen (continuous improvement). For this to occur the team must keep these primary goals in mind:

1.Open and Honest Communication

2.Group Understanding

3.Executable Action Items

The last of which is the defined deliverable for the retrospective, the Executable Action Items. Without this you are simply clearing the air, either griping or congratulating without point or purpose. This artifact is the ultimate output of the retrospective meeting, a ratified plan on what elements of a teams working environment or practices to change in order to improve performance over past iterations.

The Executable Action Items are a very short check list or todo list of suggested ideas, also known as experiments, for improving the performance of the team. This list is derived from a subset of all the issues discovered in the retrospective meeting. The list of open issues are scoped down to a short list of high priority items, less than 3, that the team wants to address in the next iteration.

I call these Executable Action Items because each item should require some action by the team, should be executable, measurable and demonstrable. Sometimes this is as simple as modifying the existing team agreements. Sometimes this requires a change in practices. Sometimes this requires new patterns of collaboration with external sources such as the Product Owner, or external teams like IT, or Release Management.

Every retrospective should produce one or more clear Executable Action Items that are sourced from the team, agreed upon by the team, and most of all committed to execution by the team. This artifact should be recorded for historical reference on a wiki or other shared resource, as well as on a Big Visible Chart in the team room or work area.

This BVC should be referenced every day during team standups to verify the team is consistently working towards improving their processes and working habits.

So, to answer the first part of our readers question, the answer is to make sure you generate a short list of Executable Action Items as your retrospective artifact, post it as a BVC in the team area for all to see and record it on a team wiki for historical reference.

Successful Retrospective Facilitation – Part II

The second part of the question posed by our reader is more difficult to explain briefly as it involves how to plan and facilitate the retrospective meeting.

There are literally thousands of blog posts and publications on Agile Retrospectives. When I did a search on google I found 165,000 hits; a staggering number to sift through. Fortunately there are a few clear winners in this field. As mentioned above, the primary resource for learning about effective retrospectives is the book by Esther Derby and Diana Larsen, with additional information on each of their blogs. These authors are known in project management circles as the “Retrospective Queens”. For every manager, scrum master or otherwise servant leader of Agile Delivery Teams, this book is a must read. Although this is not the first book written on Retrospectives, nor is it the last, it has become a standard that many refer to.

Today my favorite resource for all things on Retrospectives is the Agile Retrospective Wiki. This site is full of collections of ideas from the best in the industry. Many of the entries on this site also appear in Esther & Diana’s book. This site is a growing collection of patterns, tools and ideas for giving powerful, fun and successful retrospectives.

Esther & Diana’s book outlines a 5 step plan for organizing and facilitiating successful retrospectives. Most of the industry is in agreement and has adopted this strategy. The 5 steps are:

1. Set the Stage

2. Gather Data

3. Generate Insights

4. Decide What to Do

5. Close the Retrospective

Some facilitators try to take a shorthand approach to their retrospectives, skipping step 1: Set the Stage, heading straight into a round robin style inquiry of the team to gather data. While this might work with very small teams that have been working well together for a very long time, it has a number of drawbacks.

It is important to remember that the 5 step plan given above was honed after many years of both failed and successful retrospectives, and post mortem meetings, by professionals throughout the industry. From their collective wisdom we learn that the most successful retrospectives all follow a similar pattern. Unless you are a seasoned facilitator and have lead many successful retrospectives then it is not recommended to stray from this guideline. On the other hand if you find something that works well for your team then I encourage you to share that pattern with others, post a note to Esther or Diana, or on the Agile Retrospective Wiki.

Step 1: Set the Stage

The first step, Set the Stage helps to focus the team on the task at hand, group learning, open and honest communication. As a developer, having participated in many retrospectives, I remember attending more than one as a “prisoner”. My mind was focused on the bug or technical challenge that prevented us from delivering a story for the sprint. I did not want to sit and talk about feelings, I wanted to get something done.

A good facilitator will always have a retrospective plan in mind and come to the meeting prepared. Setting the stage helps to break us out of our mental thought patterns and re-focus our energies on the purpose of having a retrospective, ‘kaizen’ . Don’t skip step one, it is there to help you get the most out of your retrospectives.

To set the stage the facilitator wants to thank all the participants for showing up, having an open mind and willingness to work together to help improve the teams overall performance. They will need to introduce their plan for the retrospective meeting giving the agenda and a rough outline of the timeline. Next they should elicit some form of verbal response from every team member, whether it is simply stating their name, or a word game where each member defines their current state, or their perception of the sprint events in a word or two. Getting this verbal exercise out of each and every team member is a way of changing their state and informing their body that actual physical participation will be required.

The facilitator should then review the teams working agreements to remind the team and to establish a safety zone for the retrospective meeting. Remember, little value will come from a hostile environment. Every member of the team should be safe and empowered to speak honestly about every aspect of working with the team, the scrum master and the product owner for the past sprint. No judegement shall ocurr for anything said within the meeting: Everything discussed within the retrospective boundaries is with the spirit of open and honest communication for enhanced collaboration.

Finally the facilitator will want to lead the participants in a trip down memory lane eliciting brief synopsis of the events over the past sprint from the team’s memory. This frames the meeting scope and reminds all participants of what happened during their sprint, good, bad and ugly.

Opening the meeting and setting the stage in this way helps the participants to refocus on the task at hand, remember what happened and what was important, and more importantly be present and available for participation in the group exercises.

The resources listed below define many patterns and games you can use for each step, mix it up, try them all, have fun.

Step 2: Gather Data

The next step in the 5 step plan is to gather data. This is a tricky step to have successful participation by all members of the team. Over time many different patterns have emerged from leaders in the industry on how to best encourage full participation, some are in the book by Derby & Larsen, and many more are found on websites such as the Agile Retrospective Wiki.

Again, you should try them all; as a retrospective facilitator you need to work hard to keep the process fresh and interesting thereby generating the greatest participation and quality results. In each of these patterns the focus is looking for both positive events (things the team wants to continue) and negative events (things that the team feels they need to improve or manage in order to perform better.)

Previously we mentioned the “Round Robin” pattern of inquiry for generating data. What might the drawbacks of this pattern be?

Let us consider a relatively new team who has been working together for only a few sprints. In round robin you gather them around a table and ask each in turn for input, what went wrong, what went well. One at a time you put them on the spot. If you were on this team how would this make you feel?

People have different behaviors, some are very vocal, others less so, some are brash and speak their minds, others are concerned about offending someone… This round robin style has the least chance of success with a new team. With a well seasoned team that has built considerable trust and confidence the round robin style may work, but even then, I have not seen it be effective; not to mention that this serial method of data collection takes too much time to get all the data.

Furthermore, during this round robin style, while one person is giving their answers the other members are not truly listening. They are thinking about what they are going to say when they are under the heat of the spotlight. Also, consider that while that person is speaking about how terrible the network problems were the other team members may drop that item off their list as it has already been voiced. This action causes you to lose a valuable piece of data — consensus.

For these reasons most of the successful patterns for data collection involve some form of silent brainstorming. Regardless of the patterns used the retrospective needs a strong facilitator to help control the dominant personalities.

In silent brainstorming each team member is given a stack of 3×5 sticky notes and a medium felt tip pen like a sharpie (this forces the notes to be written large enough to be read from a distance while limiting the details on each note.) The team is given a timebox for generating ideas, sometimes a goal is placed before them like “generate 10 sticky notes each”. Each team member writes down their ideas that answer the questions posted on the board during the “Set the stage” step. Each retrospective pattern has slight variations on the questions posed.

As the team members work independently to generate ideas there will be a flow, maybe slow to start then gaining more momentum as their brains focus more deeply on the past sprint activities. If you have set the stage appropriately their minds will already be focused on the past sprint and will have been reminded of major events that occurred.

Eventually the flow will slow to a trickle or even stop. Even though the facilitator is time-boxing this activity, if the flow is strong they should hold off on closing the time box, and if the flow trickles to a halt simply ask if the team wants more time or if the time-box should be closed early.

Now what are the psychological forces at play here? First of all the silent brainstorming method makes all members equal, both the loudly dominant and passive members are given equal voice. The quiet members are given courage to voice their opinions and ideas, and the loud members are forced to constrain their ideas to what fits on the sticky notes. Frequently team members will post their notes on the board as they generate them, sometimes the facilitator will canvas the group and offer to post any completed notes on the board while the team continues to generate data points. Team members who begin to slow down can read the notes already posted and be prompted for new ideas. Usually they will see duplications which emboldens their spirit with the knowledge that other teammates are thinking similarly.

Step 3: Generate Insights

When the time box is closed the facilitator will ask the group to join him at the board to help organize the sticky notes into groups to uncover the themes represented by the generated data, like Network Troubles, Story Content or Acceptance Criteria, Interruptions, Product Owner availability, etc. Usually there will be some amount of duplication, this is consensus, a valuable data point that helps build team cohesion.

When more than one person produces a note with an identical or closely related topic this demonstrates how prevalent or important that topic is. When doing the round robin style the only way to collect this data is to acknowledge the nodding heads around the table when one person is first broaching the topic. I think that when 2 or more people are affected strongly enough by the idea to synthesize and record it on a sticky note it shows a much higher degree of consensus.

Once all the notes are affinity grouped the facilitator can read through each note or group of notes, leaving an opening for each author to add details thru discussion, or possibly requesting volunteers to explicate complex topics. This is a tricky situation here where the facilitator needs to be careful not to attack or put anyone on the spot. They need to help each team member feel supported, protected and safe so that they can share their ideas without retribution. The ground rule of any brainstorming session is that no judgement is applied when ideas are expressed. The facilitor should make this clear in step 1 Set the Stage.

Once all the idea groups have been discussed the team will proceed to prioritizing the themed groups by vote and discover the top 2 or 3 items where improvement is desired. I like to use multi-voting for this stage. In multi-voting, otherwise known as dot voting, each participant is given 3 votes (sometimes more if the number of affinity groups is large). They may place those votes any where they choose. Each vote signifies a topic that is important to someone. After the voting is complete the facilitor tallies the votes and identifies the top 1 or 2 topics for discussion.

Step 4: Decide what to do.

The top topics are given themes (subject names) for easy reference. From these themes the facilitor leads a discussion with the team on how to improve these topic areas. This is once again a form of data collection and it is up to the facilitor on how best to do this, but generally once the dirty laundry has been aired and agreed upon the team begins to feel emboldened. Soliciting ideas on how to improve the agreed upon subjects become less hazardous. Some patterns have the team break into small groups to generate ideas on how to improve a specific topic. Some teams simply hold an open forum. Choose what works best considering the emotional state of the team, the current sprint and the nature of the topics.

Eventually each topic will have 1 or more Executable Action Items attached that address the described issue. The team discusses each of these items and makes a vote on their ability and desire to commit to execution of each action item. Sometimes a person is assigned to an item with the responsibility to make sure that item is completed, occasionally an expected due date is assigned as well. Other times it is simply the attempt to adopt a new practice across the team.

Step 5: Close the Retrospective

Finally the facilitator will close the retrospective. Closing the retrospective helps the team leave the meeting with a positive feeling that something good will come from all their work. This helps to encourage them to participate more in future retrospectives. For more information refer to the book or provided resources below.

The final aspect of the retrospective is to generate a BVC of the Executable Action Items and post it in the team area for reference and discussion during team standups, and throughout the day as well.

Conclusion:

For a successful retrospective the facilitator must be organized and come to the meeting with a plan. They must be strong enough to control the louder participants while generating an atmosphere of trust and safety so that all team members may participate equally. The results of your efforts should create the following:

1. Safety zone for open and honest communication

2. Group understanding thru discovery

3. Team committed Executable Action Items

The final artifact of the meeting is the Executable Action Items, which should be recorded in a team wiki and posted on a BVC in the team work area. There are vast resources available to help you plan and keep these sessions interesting, fun and productive. And remember, always have fun.

Resources:

 

Blogs & Wikis

XP123 Patterns for Iteration Retrospectives

Retrospectives.com

Refactoring Your Development Process with Retrospectives

Introspection And Retrospectives and Restrospective Techniques

Video: Retrospectives Presentation at San Francisco Agile User Group

Video: Agile Retrospectives – Making Good Teams Great!

Esther Derby’s Blog on Retrospectives

Delicious tags for Agile Retrospectives

SlideShare Presentations:

Effective Retrospectives

This is the best slide presentation I have seen on retrospectives. If you have never held a retrospective this slide deck shows examples of and discusses a real retrospective producing qualitative results. A great place to start if you do not know what an effective retrospective looks or feels like:

Retrospective CookBook

Books:

Agile Retrospectives: Making Good Teams Great

Esther Derby (Author), Diana Larsen (Author), Ken Schwaber (Foreword)

Download the Free Extracted Excerpt from the Book

Download Agile 2007 Paper by Diana Larsen and Esther Derby

Read Esther Derby’s Blog:

Cockburn, Alistair. Agile Software Development. Addison-Wesley, 2001. “Reflection workshops” are a top-level practice in Crystal Clear.

Kerievsky, Joshua. “How to Run an Iteration Retrospective.” 2002.

Kerth, Norm. Project Retrospectives: A Handbook for Team Reviews. Dorset House, 2001.

McCarthy, Jim and Michele McCarthy. Software for Your Head: Core Protocols for Creating and Maintaining Shared Vision. Addison-Wesley, 2001.

Kaner, Sam, et al. Facilitator’s Guide to Participatory Decision-Making. New Society Publishers, 1996.

Thiagi. www.thiagi.com – Training and games.