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.