It seems like retrospectives are still one of the more challenges agile activities/ceremonies to execute and get right. Which is somewhat surprising to me in that it’s a fairly simple activity. For example –
A team sits down periodically to look in the mirror and brainstorm way(s) to improve themselves.
How hard can that be?
We could also apply the word kaizen or kaizen event to it. Here’s a snippet as to what Wikipedia has to say about its meaning –
The Japanese word kaizen means "change for better", with inherent meaning of either "continuous" or "philosophy" in Japanese dictionaries and in everyday use. The word refers to any improvement, one-time or continuous, large or small, in the same sense as the English word "improvement".[5]
Again, it’s a simple, yet core element of your agile culture and I don’t necessarily understand why it’s so challenging. But let me share a few stories to illustrate the point that it IS challenging. At least to do it well…
I watch my fair share of TV shows that surround real-world business and projects. I’ve noticed a theme that I want to share to see if you see it the way I do. So here are a few examples:
Fast ‘n Loud is a show on Discovery Channel here in the US. It’s about a garage that takes in “needy” cars and refurbishes them for resale.
The owner of Gas Monkey Garage is Richard Rawlings. In the episodes he generally is scouring the countryside for fixer upper cars that have up-side profit potential.
Book References
Project Retrospectives - A Handbook for Team Reviews by Norm Kerth
Sort of the “Godfather” of the modern day, agile retrospective is Norm Kerth. I always try and mention norm and his work as a means of giving folks a sense of the pre-Agile legacy of retrospectives. Point being, it pre-dates agile approaches.
The other nice thing about Norm’s work is his notion of “safety” in retrospectives and his Prime Directive. I almost always reference the prime directive at one point or another with each of my clients and in my teaching. It epitomizes the “mindset” of a healthy retrospective.
I’m wondering if you think this post will be about the Scaled Agile Framework or SAFe? Well, it’s not. Before there was SAFe, there was good old-fashioned “safety” from an agile team perspective. And that’s where I want to go in this piece. So just a warning that no scaling will be discussed :-)
Within Retrospectives
I often advise teams and organizations that are contemplating “going Agile” to consider safety as a factor when running their retrospectives. I share the “Galen-rule” around not inviting or having “managers” in the teams’ retrospective.
My partner Josh Anderson and I just finished a Meta-Cast on the topic of self-directed teams. One of our listeners asked us to share our thoughts on handling agile team members who simply wanted to be “told what to do”.
On the surface, this doesn’t seem like such a bad thing. In fact, I’ll bet these folks are bright, capable and work very hard. They’re also probably “good people”. So if there is an issue with this in agile teams, what is it? And why would it be a problem?
