 |
Home > Detail: Eight Reasons Retrospectives Fail
| A StickyMinds.com Original |
|  | |
Eight Reasons Retrospectives Fail
(And What You Can Do About Them)
By Esther Derby
   
Summary: Retrospectives work for most teams, yet some teams are convinced that retrospectives will never work for them. When Esther Derby came across several of these teams for which retrospectives had failed, she questioned why and discovered eight common reasons for those failures. In this week's column, she details these eight reasons and offers solutions for each one. | | |
|
|
 |
I've seen retrospectives help teams make major improvements. Yet, each time I talk to a group about retrospectives, someone always tells me, "We tried retrospectives, and they don't work for us." Why?
My inquiries revealed eight common reasons behind retrospective failures. Some failures happen before the retrospective starts, some happen during the retrospective, and some relate to how teams follow through on retrospective results. The good news is that most of the problems are relatively easy to fix.
1. No Preparation
Every significant working session or meeting requires preparation, and retrospectives are no exception. Showing up for a meeting with no idea of how the group will use the time is a waste of everyone's time and results in unbounded discussions that lead nowhere. Take time to prepare an agenda that will help the team reach their goal.
2. No Focus
Every retrospective needs a focus. The focus describes the territory the team will explore, without specifying an outcome. For example, many teams start with a focus of "continuous improvement." That may suffice for a while, but after a few retrospectives the team may run out of things to say. Sharpening the focus will help the team delve deeper. Choose a focus that reflects the challenges of the previous iteration or period of work. For example, if the team members found that the stories they selected were under-defined, they might focus on "improving our work with the product owner to groom the backlog." (And invite the product owner to come to the retrospective.)
3. Failing to Gather Data
Many teams start their retrospectives by asking: "What did we do well?"; "What should we do differently?"; or some other variation. These aren't bad questions, but they shouldn't be the first questions. These questions ask for analysis and conclusion, which require data. Before talking about what to change, talk about what happened. Choose data related to the focus of the retrospective. Depending on the type of data, it may help to pull the information together prior to the retrospective meeting.
When the team skips gathering data, each team member is analyzing his or her own perceptions. When the team members review data together, they are creating a more complete picture of the iteration and are all working from the same data.
4. One or Two People Dominating the Conversation
It's easy for one or two dominate personalities to control an unstructured discussion and push their ideas onto the group. The result is that the team as a whole doesn't fully accept the retrospective outcome. Rather than leave the field open, use pair or small-group discussions and activities to ensure that everyone has a chance to participate and contribute to the result.
5. Focusing Only on Impediments That Are Outside the Control of the Team
We all know that many of the problems teams face are systemic problems--problems that management needs to fix. When team members only focus on issues outside their team, they can become demoralized. Worse, they come to view themselves as hapless victims. I find there's plenty they can do to improve their own processes and methods--much more than most teams initially recognize. Focus on choosing improvements the team can do themselves or on which they have strong influence (in which case, the action is creating and executing an influence plan). Even when the team doesn't have control, they can choose to respond differently.
6. Biting Off More than the Team Can Chew
Some teams generate long lists of things they need to improve, and then they try to do them all at once. Too much change can overwhelm the team and leave too little time to work on the product. Choose one or two actions that the team can work on in the next iteration.
7. Choosing Actions the Team Doesn't Have Energy For
When it comes to deciding what improvement or experiment to work on for the next iteration, words matter. I often ask the team to rate the candidate actions on two scales: which one is most important and which one do they have the most energy for. The rankings are often quite different.
The team may recognize that something is important but not want to work on it. There are lots of reasons for this: They may have tried before and failed, the task may be too difficult or time-consuming given the other work they have to do, or the work may be plain unpleasant. In any case, when the team doesn't have energy to work on an improvement, chances are pretty good it won't get done. Go with the task the team has the energy to complete.
8. Keeping a Separate "Improvement Plan"
The most common reason I see for "do nothing" retrospectives is that the team keeps one plan for "real work" and another plan for improvements. Guess what happens to the improvement plan? When the improvement work is considered separately from "real work," it doesn't get done. Improving the team's capability is real work, so put it in the real plan. That way it will be considered when the team makes commitments to working on features and will be in front of the team throughout the iteration. Write a story card for the chosen improvement, and take it into the next iteration planning meeting.
There are some organizations where retrospectives truly won't work.
In organizations where there is a pervasive culture of blame, people may be too frightened to bring up issues. In that case, retrospectives may do more harm than good. When teams are facing relentless deadlines and not working at a sustainable pace, there may be so much pressure to produce that teams feel they can't step back and look at the way they work or afford time to learn new skills or make changes. Both of these are systemic problems and are too big for team retrospectives to solve.
Fortunately for most retrospective failures, the remedies are quick and straightforward.
About the Author
A regular contributor to Better Software magazine and StickyMinds.com, Esther Derby blends technical and managerial issues with people issues to help teams grow to new levels of productivity. Esther is the co-author of
Agile Retrospectives: Making Good Teams Great. She is one of the founders of the AYE Conference and has presented at STAREAST, STARWEST, and the Better Software Conference & EXPO. She can be reached at derby@estherderby.com.
Back to Top
StickyMinds.com Weekly Column From 5/19/2008
|
