When I started working on projects, we thought we could use a serial/waterfall approach to project management and product development. While we were wrong, one very good thing happened in the 1970s and 1980s: We took the time at the end of each phase to do a little retrospective. Yes, even for a serial approach, like the image above. (That comes from the Project Lifecycles book.)
While most of us examined our product progress, very few of us examined our product development process. (It never occurred to me or my teams to do so.) However, we used our past data and experience to inform our next decisions. We reduced our learning cycle time.
However, sometimes phases lasted a long time. That's how we got to the 90% Schedule Game, where after we finish the first 90%, we realize we have the next 90% still to do. The shorter the phase, the more often we could retrospect. We used what we learned to make more realistic future plans.
Notice what we did after each phase. Not just the re-estimate and replan, but the “possibly cancel.”
The possible cancellation made it possible for an organization to reconsider its project portfolio. The portfolio team could:
- Consider different projects. (Change the portfolio)
- Add or change teams on this project. (Transform the project.)
- Make this project part of a program—or break a program into separate products. (Strategic product decisions.)
We learned from what we did before, even if it wasn't full learning. That's why retrospectives are so important: they indicate a learning cycle time.
Learning Cycle Time
Today, many teams focus on delivery-based cycle time, because we have a built-in assumption: we will retrospect shortly after or with each delivery.
But the more I teach and coach about agility (see Create Your Successful Agile Project), the more I see this one important detail:
Too many supposedly agile teams do not deliver, so they don't retrospect. Or, they might deliver something, but they don't deliver “everything,” so they don't retrospect often.
A retrospective that includes product progress and process assessment helps teams see why they are not delivering. Or why they don't deliver “everything.” Or anything else.
Waiting to retrospect increases the team's learning cycle time, not just the cycle time for the product. The longer a team waits to learn, the less they learn.
How Long Do You Wait to Retrospect?
The longer it takes for a team to finish work, the more WIP that team has. Then, the longer it takes to finish, and the lower the throughput. (See Flow Metrics and Why They Matter to Teams and Managers.)
If a team waits to retrospect until after they ship something, they don't learn from not shipping. If they wait because they haven't finished “everything,” they don't learn something that can inform their next steps.
Worse, the longer the team waits to retrospect, the higher their possible learning WIP. That creates a longer learning cycle time. Worse, the less they remember—a lower learning throughput. That lower learning throughput means they have increased aging of what they could have learned.
As if to add insult to injury, they don't know if they could have been done already. (See the story about the furious VP in Release Criteria: Is This Software Done?)
Infrequent retros make everything worse.
In contrast, frequent retros can help teams see and solve problems right away and learn from them. That's the point of a short Kaizen.
Short, Frequent Retros Catch the Good, the Bad, and the Ugly
In From Chaos to Successful Distributed Agile Teams, Mark Kilby and I recommended that teams perform a kaizen—a learning event—whenever they had something to discuss. No one needs to wait for a retrospective.
While we focused on a 30- 60minute timebox to address problems immediately, we also suggested teams use a kaizen for:
- Catch people succeeding so the rest of the team can learn.
- Immediate learning the team needed to put into practice. (Imagine a security problem one person discovered and wants to immediately let everyone else know about.)
- Problems that look like they could create cascading defects.
The more frequent the retro, the faster the team can learn.
Infrequent Retros Postpone Learning
Infrequent retrospective postpone all the learning about the team's process, the product, and what to do next. The team, product manager, and the organization continue doing what they planned way back at the start of the effort.
Infrequent retrospectives create a serial lifecycle approach, often with very late and unplanned feedback loops. We don't know what we don't know.
I prefer to manage risks by changing as many of those unknowns into something we know more about.
That's why this is one of the questions I often ask my project/program manager coaching clients that they ask their manager or various stakeholders/sponsors/partners the question in How to Set Sponsor Expectations About Bad News To Avoid Surprises:
When do you want to learn any bad news?
The earlier a sponsor/stakeholder/partner wants to know about bad news, the more frequently we need to retrospect. That's because we now know we need to examine both the product progress and the process that gets us—or not—to that progress. More retrospectives decrease learning cycle time.
Infrequent retrospectives fool us into thinking we are learning fast enough. Too often, we are not. Instead, reduce your learning cycle time with more frequent and small retrospectives. You might even find those little retros make everything just a little easier.