Kaizen means continuous improvement. It implies an iterative process where lessons are learned and applied to the next iteration of a process. A retrospective is a technique to facilitate kaizen.

In a Scrum setting, retrospectives happen after every sprint or release. In a Kanban approach, releases occur more regularly. The closer you get to continuous delivery, the less sense it makes to have a retrospective after each release. Instead, you can hold a retrospective whenever it makes sense. At Pez.AI we have retrospectives after completing a significant milestone of an initiative.

Anatomy of a retrospective

The scientific method is the foundation of our decision-making process at Pez. We regularly define hypotheses and conduct experiments to test them. Sprint retrospectives are no different. The goal of retrospectives is to identify which aspects of a process work well and which aspects don’t. Each potential solution to make the process more efficient is a hypothesis that can be tested.

A retrospective follows these steps:

• Identify areas of waste in last milestone. Use TIMWOOD as a guide
• Quantify the cost of the identified wastes, either in time, money, or intangibles
• Pick top waste to address/improve based on cost
• Brainstorm what can be done to reduce the waste in the next milestone. These ideas are your hypotheses
• Decide how you can measure the outcome and confirm that waste has been reduced
• Commit to this improvement in the next milestone

Waste Analysis

Lean defines 7 wastes that form the acronym TIMWOOD. These can be a starting point for identifying waste in your process. For example, how much did people WAIT for others? Were there DEFECTS in communication (aka miscommunication)? Was there too much MOTION waste from multitasking?

Once you’ve identified sources of waste, estimate the cost of that waste. In software development, the cost is typically in units of time, though it could also be in monetary units. Try to stick to one unit so it’s easy to compare. For example, meetings can be wasteful since not everyone gets value from a meeting. Therefore the cost is typically quantified as people in meeting * meeting duration. If people are stuck waiting for someone else to complete a task that is also in time units.

Remember to include intangibles, like morale, in your cost estimate. It’s also important to include common resources that might be depleted despite individual efficiency gains.

The beauty of quantification is that it simplifies prioritization. Just pick the waste with the highest cost and focus on that. Just be sure you have reasonable estimates for the costs. If there is one waste that is clearly larger than the others, then go with it. If there is a near tie, then spend some extra time improving the estimates. This iterative approach is efficient since detail is added only when necessary, which minimizes over-processing (it’s a form of just-in-time production).

The above steps can be done prior to the meeting by a product manager or team lead. It may involve surveying or interviewing individual contributors to get a better sense of the wastes. Either way, it’s useful to review the wastes so everyone can appreciate how these wastes affect their productivity.

Improvement Hypotheses

Once a waste has been chosen, work with the team to identify ways to minimize the waste. This is a brainstorming exercise, so get input from everyone. Understanding TIMWOOD helps here as well: solutions typically depend on the type of waste identified. For example, if there is too much MOTION (ie manual tasks) waste during a deployment, consider automating parts of the process. Sometimes a process needs to be rearranged to segregate manual steps from automatable steps.

Pick the top 2 or 3 improvement hypotheses. For each hypothesis, determine what metric you will measure and how. This should be straightforward since you’ve already quantified the waste. For example, waste in a deployment process can take the form of time or additional defects. If the main concern is the time taken to deploy, then agree to how you will measure the time to deploy. Does it include testing? How many people are involved? If you’re concerned about an unreliable deployment process, how will you measure reliability?

Field testing

Now that you have a plan, you need to commit to the plan. This is the hard part and requires commitment and discipline from the team to

• follow the plan, and
• track/measure the outcome.

This is the weakest link in the process because it’s easy to ignore following the process for personal reasons: either too lazy or want to focus on something else. Hence, efficiency is often a tragedy of the commons, since one person acting out of self-interest can torpedo the whole initiative. It’s therefore important that there is full buy-in and the team applies social pressure to ensure everyone follows the process.

Debrief

Congratulations, you’ve reached your milestone! Now is the time for your next retrospective to review your hypotheses and evaluate how effective they were. This review process is the cornerstone of continuous improvement. Each iterarion builds on the lessons of the previous retrospective. Take the time to

• review your previous kaizen goal
• review your metrics and outcomes
• make a judgment (was it effective or not?)

These insights feed into your next set of improvement hypotheses. After a few iterations you should notice some tangible improvements in your process.