Hindsight is said to be 20-20, but is it really? Isn't there a bias to hindsight? Psychologists tell us that using our hindsight we all tend to see events that have occurred as more predictable than they really were. So when we want our agile teams to reflect on the past, just employing the teams' collective hindsight is not what we want.
In an agile world, retrospectives are about an open and honest examination of the past in order to shape the future. We want to understand past events both good and bad, and also how our emotions influenced those events. It is a learning experience. It is learning from experience. How can the team get better, accomplish more, collaborate more closely, solve issues more quickly, and deliver business value sooner? This is the art of retrospection.
In their book Agile Retrospectives, Esther Derby and Diana Larsen define a five step process and eloquently discuss how to proceed with each:
- Set the Stage
- Gather Data
- Generate Insight
- Decide What to Do
- Close the Retrospective
Of these, I have found that step 3, Generate Insight, is the hardest to do. It is easy to fall into a rut and continually generate the same insight retrospective after retrospective; discovering little if any new learning. Agile leaders face a challenge in keeping their teams' retrospectives fresh in order to drive out new insight and innovation. This requires continually varying techniques to keep the team engaged.
Let's look at some examples:
Stop, Start, Continue
I'm not sure where I first encountered this exercise, but it was most likely from Mike Cohn. Particularly for new teams, this exercise works well. The team examines what is working and commits to Continue doing those things. It also reflects on what is not working and agrees to Stop doing those things; and finally proposes new things to Start doing that may help the team improve. This is a good way to start a team with retrospectives as it can focus the team on specific behaviors. It can also provide a safely bound environment for team members to express their feelings about how the team is working. A statement such as "I felt left out when it was decided that we would not support more than one browser" may make the team reconsider how it ensures everyone's voice is heard before making decisions. After a few iterations however, the team may continue to generate the same Start, Stop, Continue lists or not have a list at all. So it is time to move on.
Four Questions
When Linda Rising talks about retrospectives she describes a similar exercise using four questions:
- What did we do that what don't want to forget?
- What should we do differently?
- What did we learn?
- What still puzzles us?
The first two questions are similar to the Start, Stop, Continue exercise but provide a little different approach. I particularly like the last two questions. I want agile teams to continually learn, so reflecting on what learning is actually occurring is important. If a team cannot identify what is being learned, that could point to some serious issues that need to be addressed. Inquiring about what still is puzzling is also very powerful. Puzzles typically abound with new agile teams and recognizing that should help the team identify how it can improve. This allows the team to pick something to experiment with in order to solve some piece of the puzzle in the upcoming iteration.
Continuous Retrospectives
For a co-located team, post a flip chart page in the team room or other common area that is divided into four quadrants: Happy, Sad, Ideas, Thanks. Throughout the iteration each team member can place a post-it note in the appropriate quadrant for things they have observed. What happened that made me happy? What happened that made me sad? What ideas do I have that might help the team improve? Who should I thank for helping me? This can provide some level of anonymity to the comments that are posted and help the team continuously reflect on its progress. Distributed teams can do something similar using a collaboration tool or shared document. At the retrospective, the team can review all the comments, discuss what they mean for the team and determine what actions it may want to take. If each team member is posting their thoughts every day or two, the team should have quite a bit of information to discuss.
Values to Actions
Scrum defines 5 values: Openness, Respect, Focus, Courage, and Commitment. I often ask teams to define value statements that reflect what these values mean to the team and in doing so also form working agreements for how the team should behave. This too could be a running exercise through one or more retrospective periods. Instead of posting ideas around Happy, Sad, Ideas, and Thanks; have the team post comments that reflect actions they have observed throughout the iteration that demonstrate each of the five values. Perhaps Openness is observed when team members are sharing ideas freely. Perhaps Courage is shown when the team recognizes and states that it will not meet the current iteration goal and adjusts to still get the best result they can. This can reinforce team values and help the team recognize their relative strengths in observing these values. If they observe only a few actions for a particular value, then the team can identify how to address that as well.
Free Your Strengths
In his book Go Put Your Strengths to Work, Marcus Buckingham shares some great insight on how individually we can identify our strengths and put them to work to achieve outstanding personal performance. These ideas have an application to agile teams as well. Of particular significance is Buckingham's view that "A good team member deliberately volunteers his strengths to the team most of the time". We can use this concept during a retrospective to see to assess how much of time each team member is actually using those strengths. It is likely as little as 17% of the time. During the retrospective the team can assess how to improve that for each team member and as a result improve the overall effectiveness of the team.
Serious Fun
Have you ever learned something from playing a game? Teams learn that way too, and Luke Hohmann's Innovation Games® are a great way to learn by having some serious fun. Combining creativity, analogy, and serious purpose, these games take people out of their normal routines to collaborate in new ways. The Speed Boat game is an excellent start. The team can identify both what made the boat go faster in the last iteration, but also what held the boat back. You might be surprised how many "appreciations" and "anchors" the team will identify in a short period of time. Then they have some rich material to consider in making their boat go faster in future iterations.
Facilitation is Essential
Retrospectives are a powerful tool for agile teams but their success depends on having a capable facilitator. This is likely the hardest facilitation job an agile leader has. While maintaining the trust of the team, we must be able to share observations, ask powerful open ended questions, probe for deeper thoughts, and be the one true mirror in which the team can see itself. As agile leaders we cannot let the team cheat themselves out of having productive retrospectives. We must instead reach in to find ways of keeping retrospectives fresh, purposeful, and safe.
It is the only way to keep the true essence of agility within our grasp.
