How often does your team conduct a retrospective? If you’re like most of my clients, not often enough.
When I ask why the team doesn’t retrospect at least once every couple of weeks, these teams tell me many reasons:
- They don’t finish “enough” work often enough. (If you’re part of an “agile” team and you don’t finish at least one thing every two weeks, stop. Conduct a retro right now! You need to know why your cycle time is so long.)
- Retros take “too long.” (Timebox them. You can conduct an effective retro or short kaizen in 20-30 minutes.)
- The team starts off being ambitious about all the changes they want to make. Then, they don’t change things fast enough. Yes, they have change fatigue.
Now, I said “team” up above. While these ideas are true for feature teams, they are even more true for management teams. So, any team, anywhere in your organization, might have this problem of learning from their retros.
You have an easy way to manage this problem: Limit your possible action items. In Create Your Successful Agile Project, I recommended the team maintain a parking lot of possibilities. Then, when it was time to decide on the next experiment, to limit the number of experiments a team chose at any one time. About a year after I published that book, I still advocated a parking lot, but I strongly recommended a WIP of one. Yes, one experiment at a time. (And frame it as an experiment.)
I said much the same in Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility. Except, in that book, I focused on the speed of learning to reduce unplanned feedback loops.
The faster a team—any team—learns, the faster they can deliver. That learning includes the team’s retros.
Retrospectives Offer Opportunities for Teams to Learn to Experiment and Adapt
The point of the retro is to offer the team an opportunity to use double-loop learning, that image at the top of this post. What did the team learn about the product they are developing? What did the team learn about its process as they worked? (Managers deliver decisions, which is why retros are not just for teams, but for managers, too. Managers need to learn not just about their decisions, but their process for getting to those decisions.)
If retrospectives offer learning opportunities, why would I recommend a team limit its experiments to just one at a time?
Because the more experiments, the higher the WIP. That prevents teams from learning as fast as possible. Instead, the team’s learning cycle time gets longer and longer and longer. (See Measure Cycle Time, Not Velocity for the basics of cycle time. And How to Move from Story Points and Magical Thinking to Cycle Time for Decisions for what I often see in teams. Also see Little’s Law for Any Kind of Product Development: How to Learn How Long Your Work Will Take for what managers might see about their decisions.)
I’m not the only one to notice this problem: the higher the WIP (Work in Progress), the longer the cycle time, even for retro-focused learning. Brad Ward and his team published this guide: The Follow-Through Index: do retrospective action items actually get done?
That longer cycle time is all about WIP (and aging). (See Flow Metrics and Why They Matter to Teams and Managers.)
The more action items or experiments from a retro, the less likely the team can finish any of them in a reasonable period of time.
Reasonable Cycle Times for Retro Actions or Experiments
There are some retro actions that the team can complete within a day or so, because the team changes its working agreements. For example, if the team decides its definition of done needs to change, the team might have to practice that new definition, but they can do that right away. That’s not necessarily an experiment. It’s a fix for a problem the team saw and chose to fix.
I once worked on a distributed team where Tom, a team member, wanted to use a particular messaging system no one else used. As the other half of his pair, I said, “No.” I wanted all the messages in our team-based environment.
Tom and I raised the issue with the rest of the team at our retro, and the team agreed with me. After much sighing, Tom decided it wasn’t worth fighting about. He used our team-agreed-upon messaging environment. That was an action, not an experiment.
But much of the time, the team needs to learn as fast as possible. That means it’s time to choose the fewest experiments for higher throughput. I like to ask this question:
“What is one thing that would allow us to lower our cycle time and increase our throughput?”
Consider experiments that answer that question. Once you get through the team process issues, then, you can ask questions about the product. But if the team can’t deliver something useful every day or two, the team still has process issues. Fix those. That will allow you to attend to product issues much faster.
Learn Fast with Fewer Actions or Experiments
While Tom and I had a problem we could solve, most team-based retro actions need to be experiments. We think we know what will work. However, we need to learn what will work.
The faster we can learn, the faster we can finish the product. And that’s the double-loop learning that will help your efforts succeed.