Retrospectives as agile-experience gaugePosted: February 3, 2012
How might you quickly quantify your agile experience? A typical measurement (think resumes) is to express experience in years. But what if we used the number of retrospectives that we attended as an objective, rough gauge for our agile experience?
Team feedback is one of the three main feedback types in an agile project, and retrospectives are one of the main ways we achieve it (in addition to pairing and sharing our workspace). In my experience, healthy and high-performing agile teams regularly practice retrospectives, usually as a built-in part of each iteration. A team that doesn’t take the time to reflect, celebrate success and improve — or as the manifesto puts it, “reflects on how to become more effective, then tunes and adjustsits behavior accordingly” — has a hard time improving because it can’t get out of the trench they’re working in and fix core problems proactively. Basically, it short-circuit the team feedback loop.
Still I think that the retrospective count is a handy rough estimator of agile experience (other than, say, the number of successful projects delivered, which is subjective). If it’s “rate stats” that you like (and I certainly do in baseball), you could divide the number of retrospectives by time (e.g., years) and get a sense of the frequency of team feedback. For instance, I’d argue pretty strongly that a team that has two retrospectives per year isn’t as productive as a team that has 12 or more per year. Sure, the caveat that they need to be quality retrospectives applies, but again, I think that a team is more likely to quit the practice of retros altogether than keep doing them badly.