Jay Fields' Thoughts

Retrospectives can be complicated meetings. Done correctly, they can provide immense value. Done poorly, they can be a show that provides negative value. A well run retrospective requires more than just going through the motions. Several things contribute to a successful retrospective; however, in my experience the key ingredient is trust.

I expect Fred George (all the way on the right, 2nd from the top) would probably agree with me. Fred is the only person I've ever met that would start each retrospective by asking everyone to write down, on a scale of 1 to 5, where their trust level is at.

A retrospective without trust is pretty worthless, so measuring trust at the beginning of the meeting definitely makes sense. If the trust level is ever below the acceptable level (assuming 5 is complete trust, anything below a 4 is potentially a problem) then the meeting doesn't proceed until a solution is found to the lack of trust.

Of course, if trust is low, you might not give a true trust level. This problem can fairly easily be addressed by having a retrospective facilitator that is in no way invested in the project. The facilitator can collect the trust measurements in an anonymous manner that protects the innocent team members.

If you're finding that your retrospectives aren't providing as much value as they should be, you might want to measure the trust level. You may find that people are afraid to talk about the bigger problems.

I'm a huge fan of retrospectives. When consulting I found retrospectives to be absolutely required. An enormous amount of value was derived from expressing concerns and discussing the expected and actual impacts. However, I've also worked on a few highly functioning teams that never seemed to get the same value from retrospectives.

Highly functioning teams tend to address issues as soon as they are discovered, which is far better, but removes some of the value that is usually derived from retrospectives.

I don't like ad-hoc retrospectives, I prefer a routinely scheduled meeting. I favor the scheduled version because often it doesn't seem like a retrospective is needed and it's delayed too long. Delaying valuable meetings definitely doesn't seem like a good plan.

The problem is, on highly functioning teams we'd often end up in the retrospective with only 1 or 2 issues to talk about. Eventually the retrospectives would seem superfluous and be removed from the calendar. I've always been uneasy with disregarding something that's proven so valuable in the past, but you can't argue with removing waste. (where waste = loss of time)

On highly functioning teams, I've always worried that smaller issues were falling through the cracks and costing us efficiency. But, retrospectives seemed too expensive a tool to identify the smaller issues.

A few years ago I worked on a team that had an "issues" white board. Anything that annoyed you could be put on the issues board. Any time you ran into an issue, you would add a new issue, or put a + next to the existing issue if the issue had already been recorded.

The issues board gave us great visibility into things that bothered the team. Adding plusses gave us a good gauge to see which issues were the most annoying. If something was annoying and encountered often, it would quickly gather severals plusses. However, if something was annoying, but extremely rarely encountered, it might not make sense to invest the effort necessary to address the issue.

As an example, if a test has a race condition that causes the build to fail 5 times a week, it's probably going attract plusses quickly and signal the team that the race condition needs to be addressed. Conversely, if the race condition causes the build to fail once a year, and it would take substantial effort to fix, it's not likely to get '+ support'. And, any issue without + support is probably not worth addressing. Usually, issues with little + support are removed after it appears that the ROI isn't positive on addressing the issue. If the issue pops back up it can easily be added back to the issues board.

The first time I used the issues board it was in conjunction with retrospectives; however, these days I find the issues board to be a great replacement for retrospectives on highly functioning teams. I view the issues board as a continual retrospective that can be modified at any time. You also get the added benefit of providing a real time view into what currently slows or stops progress on the team.

Replacing retrospectives with a continual retrospective isn't something I'd recommend under normal circumstances. Like I originally said, I find retrospectives to usually be extremely valuable. However, if the value of retrospectives seems to be negative when compared with the value of time, then a continual retrospective is probably better than no retrospective at all.