Retrospectives Provide Valuable Data
When any team works for any period of time—even as short as a day—the team can examine its results (the work product) and its process (how the team worked). That’s the idea behind the agile retrospective. A retrospective is a look back at the team’s actions and output so the team can learn what to do next.
Too many agile teams shortchange their retrospectives. They stop doing them, the retrospectives become formulaic, or the team doesn’t change what it does.
How often should your team reflect? Here are some possibilities:
-
Reflect at a one- or two-week cadence, regardless of whether the team uses iterations.
-
Reflect every time the team releases to the customer. (If your team uses continuous delivery, that might be too often.)
-
Reflect at the start of the project to ask, “What do we want to keep, add, remove, or change from previous work we’ve done?”
-
Reflect at the end of the project.
Don’t wait until the end of the project to hold a retrospective. In the “general agile picture” here, you saw the team demonstrate and reflect on a regular basis. The team has an opportunity to learn from its work together about the product and its process.
You may have heard the old project-management adage: “Plan the work and work the plan.” That is an example of single-loop learning as illustrated in the following figure.
Single-loop learning is good. It helps a team deliver small value fast. Single-loop learning helps the team adjust the remaining features in the feature set as it proceeds.
Single-loop learning is insufficient to deliver on the promise of agile approaches, however. When the team and the product owner check their assumptions, not just the feature, they are able to replan, together and separately. The product owner can check her or his assumptions about the necessary minimum or even the overall content of the feature set. The team can check its assumptions about how it works, not just what it delivers.
Retrospectives encourage double-loop learning, as illustrated in the next figure. We can challenge and understand the assumptions we made in order to decide what to do and how to do it next. The more often the team creates opportunities to learn, the more often it can experiment. In Learn Early Instead of Failing Fast, I suggested teams create small, safe-to-fail experiments. The more often the team reflects and creates experiments, the faster it will learn.
Your team might prefer a more continuous flow of improvement. In that case, the lean idea of kaizen, a change for the better, might be useful. The Lean Enterprise Institute presents the ideas of flow kaizen and process kaizen.[21] Flow kaizen looks at the value stream to see where the value is in all the activities. Process kaizen focuses on individual processes.
Instead of separating the two types of improvement, consider taking a holistic approach. Where is the value stream for this team? Are people working in a way that promotes the value of the product under development? Where are opportunities to improve and change? Two terrific books on organizing retrospectives and kaizen activities are Agile Retrospectives [DS06] and Getting Value out of Agile Retrospectives [GL15].
Make sure your team has an action-item list as it works through its retrospective. The team might discover numerous things it wants to improve. Consider helping the team decide on no more than three items to work on until the next retrospective. Some teams want to fix the accumulated years’ worth of problems in two weeks. That’s not possible.
Instead, help the team take an agile approach to improvement. The team might want a ranked backlog of improvements. It can select some small number of improvements so the improvement WIP remains small, too. The team is more likely to see progress that way.
Use a Parking Lot for the Improvement List
Teams new to agile approaches may have a long list of possible improvements. Instead of trying to work on all of those improvements at once, consider a visible parking-lot board, like the one shown in the following table.
Idea | Date Added | Value to Us | Notes | Progress |
|---|---|---|---|---|
Figure out how to build learning into our normal week. | Feb. 10 | We would have time to learn. | We are so full of WIP and new work we don’t seem to have time to do this. If not started by Aug. 10 (six months) do something different. | Goal: Some kind of learning every week |
Smoke test automation from API. | May 2 | We would know about the builds. | Full API smoke tests take a few weeks. Chip away? | Goal: For all new features, another 10% every two weeks |
Full system test automation from API. | May 2 | We would have support for frequent changes. | Start with engine, add email, admin ASAP. | Goal: For all new features, another 10% every two weeks |
Mob. | June 15 | Improve throughput? | Mary to learn and explain. | None yet |
Track cycle time as well as velocity. | May 15 | Story size. | Just talking about it made some progress. | Need to change board. Tool doesn’t allow us to do both. |
Although I’ve created this board in the text, some of the best parking lots are corkboards with index cards. You might not need the Progress column. As long as the team can track what it added and have a way of working through the parking lot, the team will continue to progress through its improvements.
When the team next plans its work, it can decide how many items to take off the parking lot, turn into stories, and work on. The nice thing about turning improvement into stories is that stories require acceptance criteria. The team might decide to Learn from an MVP or an MVE, before it decides on this specific action. The team might discover an unexpected root cause.
If the team discovers a cluster of defects, or a similar problem occurring over time, consider asking the team to do a root-cause analysis so it can decide on corrective action.