Near-Continuous Improvement: WIP-Triggered Retrospectives

Perhaps this has happened to your team: You’re at the weekly retrospective, and the team has generated a lot of issues. Too many issues. After the allotted hour is up, you’ve barely come to a consensus on how to solve one of the issues, to say nothing of the five other things that probably matter.

Like a testing “gate” in a waterfall process, saving up all the issues until the end of an iteration or cycle tends to give short shrift to those issues, frustrate the team and rob the team of benefiting from earlier improvement. In my experience with retrospectives, teams often identify more problems than they can handle. And in the rare cases in which they do have enough time to decide on solutions for each, they often bite off too many action items to effectively enact and/or create independent experiments for.

Surfacing lots of issues is helpful. Surfacing them all in a batch generally isn’t.

retro-unlimited-wip

“How often should we have our retrospective?” That’s a common question teams ask, usually at the outset of a project. Typically for teams working in iterations, the retrospective happens on the same cadence as planning and delivery ceremonies. But it doesn’t have to.

What if you held the retrospective not on a set schedule but instead just before you had too many issues to discuss? That is, trigger the retrospective based on a limited number of work items — or, in this case, issues — in progress:

retrospective-limited-wip

Just as you would treat a WIP limit in a work-item board, the WIP-limited retrospective board enforces a discipline to proactively deal with issues to improve flow/reduce bottlenecks/speed learning/decrease lead times. This is the same pattern of Jidoka (stop-the-line): stop-the-line, find the cause and fix it immediately. Or, if you decide to limit your issues in progress to more than one, near-immediately. And as you would empirically adjust WIP limits for work-item states, you can do the same with issues (though I would suggest smaller is better, at least to begin).

This approach to retrospecting has at least a few benefits:

  1. The team gains the advantages of improvement (or learning) sooner than if it waited until the scheduled retrospective.
  2. The team is assured of spending enough time that each issue requires, and each issue gets a fair “hearing.”
  3. The team can focus on improving one thing at a time and isolate improvement experiments.
  4. The team avoids being overwhelmed with too many action items.

In the same way a stop-the-line approach for dealing with product defects facilitates the orderly flow of work, so too can a more just-in-time approach to dealing with process problems facilitate the orderly flow of process improvement. To do so, consider WIP-triggering your retrospectives.

 

Advertisements


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s