For years, I’ve seen people argue online about who should and should not be invited to a retrospective. In typical consultant fashion, my answer is “It depends.” Here I want to describe the dependencies so that it’s not such a mystery.
First, let’s define the basics so we have a foundation for the conversation. My definition of a retrospective is
- Looking at the past, together
- To gain insights
- And make choices for the future.
“Looking at the past, together” is what the word “retrospective” literally means. The word dates to the 17th century, and is formed from the Latin retro meaning “back,” and specere “look at.”
Let’s see how this affects the question of who should attend.
Michael James is on a rant against Agile Coaching as it often appears to be practiced, but what he describes doesn’t sound much better, to me.
Michael describes Agile Coaching as “push[ing] processes and ways of working on teams,” and “trying to ‘change management culture.'” He suggests “starting with a clear system optimization goal stated again and again from upper management.” Never mind that this, itself, is an example of trying to change management culture, assuming that’s not what they’re already doing.
Imagine you work for a company that produces a videoconferencing system. You’ve done pretty well with it, but you’re middle of the pack of competition. Then there’s a worldwide pandemic, and the market for videoconference software explodes. There’s a silver lining in this terrible event. A rising tide lifts all boats, right?
Maybe not, if the competition has more of what the customers want. It’s critical to remain a viable choice in the eyes of customers.
It’s my observation from watching small groups of people working together that it’s almost universally common that some people will take charge and direct the common effort and others will get quiet, abdicating any such role.
It’s also my observation that, even in a small team working together daily, people notice different things, interpret the things they notice differently, and assign different significance to those interpretations. People often think that because they are immersed in a common experience that there’s no need to talk about it. This appears to not be so.
Groups of technically oriented people often want to optimize the work process to those activities needed for the technically oriented output, and overlook those that are focused on the needs of humans and groups of humans working together. Yes, you can have a standup and not get any value from it. You can also not have a standup and avoid providing a convenient mechanism for taking advantage of the differences in observation, interpretation, and significance made by the entire team.
If you’ve got a really good team facilitator, they’ll likely notice this and help bring it out. If they’re really excellent, they’ll convince the team to work in a fashion where it can more easily come out without them acting as a middleman to make it happen. They might use a simple technique such as a daily standup to create such an opportunity.
You may have noticed I haven’t been writing much on my blog. That’s because I’ve been writing a book, instead.
I’ve self-published before, both solo and with co-authors. This is my first professionally edited book, though.
It’s been a lot of work, but my editor, Adaobi Obi Tulton, has helped me create a much better book than I would have created by myself.
Take a stroll over to Pragmatic Bookshelf where you can buy it. And after you read it, I’d love to hear what you think.
A friend asked for suggestions on a metric for backlog grooming. I’ve never written down these numbers, but this is the metric I use in my head.
Agile 2018 has come to an end. Once again, virtually all of my time was spent in the Audacious Salon, where I was a track chair. Once again, it was an immersive and powerful experience for me.
It’s time, perhaps past time, for me to describe the salon to the world. To describe how it came to be, the intent, the evolution, and the magic I’ve seen flourish.
This description is, of course, the viewpoint of one man. Undoubtedly I’m biased. Understandably, others will have different viewpoints based on different hopes and wishes, different experiences, and different knowledge. I invite you to share these differences in the comments, even if your viewpoint seems negative toward the concept. Perhaps particularly if you have some complaint, doubt, or fear about the Salon. I, or we, can learn most from a diversity of opinion from diverse people. Read More
On numerous occasions I’ve observed long-time members of the Agile community complain about misinterpretations of what Agile means, and how it performed. Frequently this is precipitated by yet another blog post about how terrible Agile is, and how it damaged the life of the blogger. Sometimes it’s triggered by a new pronouncement of THE way to practice Agile software development, often in ways that are hardly recognizable as Agile. Or THE way to practice software development is declared post-Agile as if Agile is now obsolete and ready to be tossed in the trash bin. Read More
Ryan Ripley has posted the second Agile for Humans podcast where he, Amitai Schlair, and I discuss the life of a consultant, how to make retrospectives valuable, and the place of managers in an Agile organization.
My article, Agile Adoption: Changing Behavior by Asking the Right Questions, has been published over on ProjectManagement.com (free registration required). It talks about when managers want change, but don’t want to squeeze the Agile out by force.