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.
Pages
About the author
A regular StickyMinds.com and Better Software magazine contributor, Esther Derby is one of the rare breed of consultants who blends the technical issues and managerial issues with the people-side issues. She is well known for helping teams grow to new levels of productivity. Project retrospectives and project assessments are two of Esther's key practices that serve as effective tools to start a team's transformation. Recognized as one of the world's leaders in retrospective facilitation, she often receives requests asking her to work with struggling teams. Esther is one of the founders of the AYE Conference. She co-author of Agile Retrospectives: Making Good Teams Great. She has presented at STAREAST, STARWEST and the Better Software Conference & EXPO. You can read more of Esther's musings on the wonderful world of software at www.estherderby.com and on her weblog at www.estherderby.com/weblog/blogger.html. Her email is derby@estherderby.com.
