Retrospectives

by Jeff Langr

January 30, 2009

Iterations are the heartbeat of agile–a consistent pulse, something that can be measured. If iterations are the heartbeat, the heart is retrospectives, representing the core and true spirit of agile: How do we adapt, how do we continually improve?

Too many teams don’t run retrospectives, and many of those that do fall off quickly. Often they fell into the trap of running a consistently boring meeting: What things did we do well, what things do we want to improve upon? Worse, they treated the outcome of the retrospective as a bunch of vague promises. I’d certainly stop attending them if that’s all they were.

A solution to the first is the Esther Derby/Diana Larsen book, Agile Retrospectives. The biggest value of this book is that it provides a number of activities to help you run your retrospectives. It provides a great starting point to devising your own activities–being creative is an important way of keeping people interested in attending retrospectives. There are a number of areas that remain to be explored with respect to retrospectives. For example, I’m currently continuing to explore distributed retrospectives.

With respect to the second challenge–lack of commitment–I like treating the retrospective items as stories, or experiments, that are introduced for the upcoming iteration (but these are not project stories). Thus acceptance criteria are required, and the stories must be specific, concrete things that people will (or won’t) do. During the subsequent retrospective, the team can’t consider the experiment complete if the acceptance criteria has not been met, and thus shouldn’t base subsequent actions on that experiment.

There’s always someone who wants an agile litmus test. “You aren’t agile if…” I feel comfortable in saying that “you aren’t agile if you aren’t consistently doing retrospectives and adapting the process based on them.”

Comments

Jake Dempsey January 30, 2009 at 09:13pm

Yeah I agree that if you can write down what it takes for your team to be agile and you can’t look at that list later on and say “wtf!?” then you aren’t agile.


Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.