To resolve the problem, I talked with the CIO. Our discussion ended up with this set of triage rules for retrospective follow-ups:
- If it is free, just do it.
- There is no reason to delay implementing some changes, including (but not limited to):
- posting a graph,
- composing a "top-ten" list,
- swapping pairs more often,
- trying pomodoro technique,
- changing how stand-up meetings are performed,
- making better use of QA, tech writing, or Customer resources
- instituting changes to coding standard
- If it takes a couple of man days, just do it.
- The team was surprised that they could peel off a member or a pair to do technical work that would improve the team. This allowed the team to take on tasks like improving the build system, metrics gathering, checking out new mocking libraries, solving version control process problems, performing global clean-ups like duplication removal, writing instructions on the team wiki. We were, in fact, not permitted to not do these things. We happily devoted a few man days per iteration to accelerating the team.
- If it will take longer, we should talk about it
- There were architectural changes, large legacy code reworks, and grand experiments that came up in the retrospectives. Some people were afraid to even mention something that might take *weeks* of developer time to complete. People were surprised to hear that management was not against such things, but merely wanted to be measured and cautious with goals, measurement, and timing. We did some large things, and we failed some grand changes (as one might suspect) but we didn't fail for lack of permission.
This triage system worked, and for the next several months we had items in all three categories.
No retrospective technique I've found will be able to single-handedly keep retrospectives fresh and vibrant and productive in perpetuity, but this one was useful to shake off a fear of lost productivity long enough to get some good changes in place and to conduct some good experiments. We did a few large-scale changes, which really were also experiments. A lot of the work paid off.
If your retrospectives are going stale, you might talk with your C-level supporters and bring the team a policy that clearly spells out their permission to try, change, and grow. Developers want to be productive (a fact worthy of a blog series if not a new book), and may need to be encouraged to look past the stories and tasks to work that might accelerate the whole team.