Retrospectives in PDCA Cycles for Continuous Improvement

Continuous improvement is essential for all organizations that want to survive and thrive in a world that changes faster and faster.

When you are in the software development space, you likely use agile methodologies to drive continuous improvement.

Outside of that space, continuous improvement often happens in PDCA cycles: planning, doing, checking, and acting (or adjusting).

In both, learning and adapting are crucial.

And that’s where the non-software world would do well to take a page out of agile’s book in adopting retrospectives as part of their PDCA cycle.

Let’s start with some fundamentals and then dig into how retrospectives can enhance your PDCA cycles.

Continuous Improvement and PDCA: The Fundamentals

What Is PDCA?

If you’re in business, you might have heard of PDCA. But even if you haven’t, we’ll break it down.

PDCA stands for Plan-Do-Check-Adjust. It’s a way to keep improving your processes and products by planning, doing, checking, and adjusting them. It’s all about being iterative and keeping things moving forward.

As you’ve seen, the phases in PDCA are plan, do, check, and adjust. Let’s break them down in more detail:

Plan: In the first phase, you’ll plan out your work. You’ll determine your goals, figure out what you need to achieve them and make a plan for how to go about them.

Do: Here, you’ll start executing your plan, working on achieving the goals laid out during the previous step.

Check: In this phase, you’ll evaluate your work. You’ll check to see if you’re on track with your goals and objectives, and you’ll assess the quality of your work. The check phase is a crucial step in the process because it helps you identify areas for improvement.

Adjust: In the final phase, you’ll make adjustments based on your evaluation in the check phase. You’ll figure out what changes you need to make, and you’ll make them. This phase is about continuous improvement, which means you’ll keep making changes and improving your work as you go along.

How Does PDCA Relate to Agile?

PDCA and agile share common aspects, but the PDCA cycle is older, predating the agile software movement by several decades. The usage of PDCA is undoubtedly applicable to organizations using and not using agile principles and practices.

How Did PDCA Develop?

The origins of PDCA are somewhat fuzzy. It can trace its roots to the 1950s or even earlier. Dr. W. Edwards Deming is often credited with creating the method in Japan after World War II. Some people claim, though, that what Deming emphasized was the PDSA cycle or Plan-Do-Study-Act.

The PDCA cycle has roots in the work of another quality control pioneer, Walter A. Shewhart. who developed a similar method called the Shewhart Cycle in the 1930s.

The Shewhart cycle had the same basic four steps: Plan, Do, Study, and Act. The PDCA cycle we know today is an adaptation of Shewhart’s cycle, with the “Study” step replaced with “Check.”

How Is PDCA Related To Continuous Improvement?

Until now, it’s become clear that PDCA and continuous improvement are related, but how? In what ways do they complement each other?

To sum it up in one sentence: continuous improvement is a philosophy, and PDCA is a process.

Continuous improvement refers to the idea that organizations should constantly be improving. PDCA offers a practical framework that teams and companies can use for continuous improvement.

Retrospectives and PDCA: What’s the Relationship?

Now that you know what PDCA is, it’s time we move on to retrospectives. What are they, and how do they fit into this puzzle?

What Are Retrospectives?

Retrospectives (or retros, for short) are meetings held at a certain cadence—usually at the end of every cycle or iteration—in which the team discusses what happened during the cycle and how they can improve.

They are a crucial part of agile methodologies.

During a retrospective, you’d typically see a discussion of:

• What went right during the cycle. What are the wins we have to celebrate?

• What didn’t go right. What didn’t go according to plan, why, and how can we learn from it?

• Root cause analysis. What are the fundamental, root causes of what did and didn’t go right.

• Improvement opportunities. Suggestions for actions the team can take to improve: boosting what went right, fixing what didn’t.

You know a retro was successful if you walk out of there with a plan. Everyone knows what to do to address the pains and gains identified and prioritized during the meeting.

Before we move on, let’s clear up some retrospective misconceptions.

Don’t Let These Misconceptions Keep You From Benefiting From Retrospectives

First, retrospectives aren’t exclusive to Scrum. Yes, the name “retrospective” traces its origin to this specific agile framework. Still, the concept of reflection—i.e., reflecting on your work to learn how to improve—is an integral part of agile in general.

Secondly, retrospectives aren’t even restricted to agile. You can leverage them in an iterative process.

Finally, let’s bust the biggest myth of all. Retrospectives are not just for software projects.

You can—and should—leverage this powerful practice whenever you get the chance, in all kinds of projects and at all levels of the organization—from individual contributors to the C level.

How Comparable are Retrospectives to the Check Phase In PDCA?

The check phase in PDCA and retros are quite comparable. A good way to see how they relate is to “translate” scrum practices into the PDCA phases. We can consider that each sprint refers to a complete PDCA cycle.

Thus, the correspondence would be:

• P – the Plan phase corresponds to the sprint planning meeting
• D – the Do phase encompasses the daily work done during the sprint
• C – the Check phase includes not only the retro but also the sprint review
• A – finally, the Act phase consists in gathering the feedback from the previous phase into actionable items

To sum it up, we could say that a retro is a specific way of conducting the check phase of the PDCA cycle. Or, probably more precisely, the retro is one of the possible components of that phase.

Finally, we already said it, but it bears repeating: retros aren’t a Scrum-exclusive thing. You can use it regardless of whether you adopt this specific agile framework.

How To Run Effective Retrospectives in Your PDCA Cycle?

By now, you know that:

• the PDCA cycle is crucial if you’re serious about continuous improvement,
• and retrospectives are a worthy addition to your PDCA process

So, the question now is: how do you go about running effective retrospectives?

Optimize the Cadence, Format, and Facilitator

Decide how often your retros will take place. You want them spaced closely enough so everyone remembers what happened since the last one, but you don’t want to run them so often that you don’t have a chance to apply what you learned. A good rule of thumb to get started is two weeks.

Also, pick a format for your retros—there are many to choose from, and mix it up regularly to keep it fresh.

A good facilitator is crucial to ensure that everyone feels free to contribute constructively so the retro is as effective as it can be. To achieve that, a facilitator has to be a good communicator, empathetic towards team members, and able to provide a welcoming and inclusive environment for all.

Make Sure To Follow Up on the Most Pressing Issues

It’s demoralizing when the issues you brought up during retros don’t get any follow-up.

You don’t have to track all issues that people mention during retros. Pick the most pressing ones — for example, using anonymous voting. And then collaboratively create action plans to address those.

Create a Space of Psychological Safety

Retros can devolve into toxic finger-pointing and blame-assigning if you’re not careful.

That’s another reason to have a good facilitator. Someone who can ensure retros are a psychologically safe place for everyone.

But it’s not all down to good facilitation. You need to foster the right kind of atmosphere between retros too.

First, understand—and promote the view that—retros aren’t for finding scapegoats. When problems do arise, instead of pointing fingers, you should work together with your team to understand why the problem happened and what you can do to prevent it from happening again.

During and after retros, don’t punish people for mistakes made because they took risks—you’ll be preventing innovation if you do. Don’t shame people when they throw out ideas that turn out not to be so great—you’re incentivizing them to say nothing if you do.

In short: during and between retros, your work as a leader is to be a role model: non-judgmental, empathetic, open, transparent, and inclusive.

Improve Continuously With Reflection Built-In

Now that you know what a PDCA cycle is, how it relates to continuous improvement, and how you can use retrospectives to make it all work, it’s your turn.

And the one thing I want you to take away from all this, is that there’s no way you can practice continuous improvement if you don’t have any least something that resembles a PDCA cycle.

How can you achieve your goals if you don’t know what they are? How to improve if you’re not measuring your past performance and analyzing how you did?

That’s why, when it comes to continuous improvement, the most important letter in the PDCA acronym is the C. If you want to improve, you gotta check. And then, of course, act upon what you learned.

Retrospectives are a great way to ensure you’re checking and acting effectively.

As you’ve seen, they’re not restricted to Scrum, agile, or even software projects. You can leverage them from the ground level to the C-suite, and as long as you do them right, you’ll reap the benefits.

A final tip. Whether you’re just starting with retrospectives or are an old hand at them, be sure to check out NimbleRetro. It’s a versatile retrospective tool that can make your retros effective and take them to a new level. Start your free trial today.