Make the Retrospective Effective

With my last employer, we had noticed that our retrospectives were starting to lag in effectiveness and attendance. People felt like they were too busy delivering stories and solving problems to do anything substantial toward meeting retrospective goals. I knew that it wasn't the kind of company that would accept stalled improvement, yet developers were instinctively afraid to invest time.

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

There is no reason to delay this kind of work. The CIO told us he considered it our job to keep improving the team through reflection and experiment, or else he would have asked us to stop months earlier. Other behaviors developers were skittish about (refactoring, speeding the tests, getting legacy code under test) were considered part of the job but programmers were afraid of "losing" productivity to those tasks. Our enlightened management re-affirmed a commitment to quality work.

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.