Agile Fundamentals

The PDCA Cycle: Why the Best Teams Learn Faster Than They Plan

24 Mar 2026·10 min read

"Doubt is an uncomfortable condition, but certainty is a ridiculous one." - Voltaire

Unfortunately, I didn't have this retort in mind when I was being shouted at by my CEO for not delivering what I had apparently "promised."

When I tell the story of that project, many people have a similar one. Stakeholders and management are often uncomfortable with uncertainty. When they hear numbers about time and budget they only remember the ones they like, usually the smaller ones.

Those of us from the agile and lean communities understand that predictive, upfront planning is often a recipe for failure. What Voltaire stated is true for any complex adaptive system: certainty is an illusion because the exact future is still unknown.

Why Certainty Is an Illusion in Complex Work

I used to commute by car to work. Same car, same route, every workday. It didn't take the exact same time every commute.

Google Maps was good at forecasting my journey time based on the latest travel information. It would update the initial prediction based on new data: weather, traffic weight, accidents, roadworks. Sometimes the actual route to my destination would change dramatically.

Google learns from system feedback to refine the forecast. The world is made up of interrelated and interconnected systems that are infinitely complex. Anyone who says they are 100% certain is telling you they can predict the future.

Whether innovating a new product, running a project, or executing standard operational processes, the exact outcomes are unknown. Until we start doing something, everything is a guess or an assumption about what we think will happen. We need to find out how wrong we are as soon as possible.

The good news is that teams and organisations can usually do a lot to manage uncertainty by learning from feedback and experience. The best learning comes by getting an early version of a product, plan, or whatever out there in the real world.

What Is the PDCA Cycle?

The PDCA Cycle, also known as the Deming Cycle, the Deming Wheel, or the Shewhart Cycle, is an iterative and incremental practice for controlling and continuously improving processes and products. It is, at its core, a way of finding out how wrong we are and learning from that knowledge.

The four steps are:

Plan - what we will do, how we might do it, and importantly, why we're doing it. This may relate to an operational or a project process.

Do - execute the plan, process, or procedure.

Check - the results and outcomes in terms of the solution and our approach to delivery.

Act (sometimes Adapt) - use what we have learned to inform our next Plan step.

PDCA is commonly used because it is simple, natural, and applicable to many situations:

The creation and continuous improvement of operational processes and procedures
Innovating or maintaining products or services in our marketplace
Dealing with uncertainty when running projects or programmes

From Deming to Lean: Where the PDCA Cycle Came From

The approach is attributed to W. Edwards Deming but has roots in earlier theories and practices. When Deming introduced PDCA to Japan in the 1950s he referred to it as the Shewhart Cycle after his mentor at Bell Labs, Walter A. Shewhart. It was widely adopted by Japanese businesses and so became known as the Deming Cycle.

The adoption of PDCA in Japan led to the creation of the Toyota Production System (TPS) by Taiichi Ohno and others. TPS gave birth to the Quality Management and Lean movements across the world, first in manufacturing and increasingly in all aspects of business. In turn, Lean has greatly influenced the agile movement.

In complex situations, such as a change project or product delivery, the exact path is unclear. This reflects many modern roles where there is a need for creativity and innovation. In such scenarios, a team would do well to adopt an adaptive and experimental Lean or Agile approach, and in fact many do.

In Lean and Agile, each PDCA cycle focuses on a small chunk of the overall work:

Teams plan to focus on small batches, a subset of the overall requirement
Earlier reviews and testing mean quality problems are caught sooner
Small batches mean quicker releases and therefore quicker customer feedback
Frequent market feedback enables teams to validate value assumptions: did they really want that feature?
Team effectiveness is frequently reviewed to find improvements

The Origins of PDCA: From Francis Bacon to the Scientific Method

The roots of PDCA go back even further than Deming and Shewhart to theories around experimentation and learning.

The scientific method, developed from the work of Francis Bacon (Novum Organum, 1620), follows a similar cycle:

Hypothesis (Plan) - our big idea, what we think will happen
Experiment (Do) - what we do to see if our ideas are right or wrong
Evaluation (Check / Act) - how did we do? What have we learned? What will we do differently?

The educator John Dewey described a parallel cycle for learning:

Discover (Plan) - thinking up new ways of doing things
Produce (Do) - performing the new ways of doing things
Observe (Check / Act) - seeing the outcomes of our actions, leading to a new Discover step

As Peter Senge wrote: "Learning is never just an intellectual exercise. Nor is it a matter of changing behavior. It is an interactive process linking the two in a spiral of continually expanding our capabilities."

We think about how to do something and then do it. The act of doing helps us learn if we were right or if we need to make a change. PDCA is a learning cycle that helps teams identify problems and opportunities. It maximises the use of learning to inform the next set of activities.

The Four Steps of the PDCA Cycle in Detail

Plan

During the Plan step, the team defines an overall goal and develops ideas on how to get there:

Why are we doing it?
What is the change we wish to make?
How will we do it?
How will we know we have done it?

An overarching goal enables effective decision-making by giving a firm sense of purpose and destination. A good goal connects with people's intrinsic motivations better than catchy slogans. If people can connect to the goal, they are more likely to willingly come on the journey.

Teams can start by analysing existing data, discussing current knowledge and successful experiences to develop possible options. It is also a good idea to set intermediate goals to move the team forward.

Think about metrics and how you will measure the impact of your actions. Planning to do some benchmarking during the Do step is a good idea.

One word of caution: beware of too much analysis and planning. Plans do not need to be perfect before you start. The value of doing is that there will be unforeseen learning and realisations that cannot be planned upfront. Learning is not purely an intellectual activity. We want to find out how wrong we are as soon as possible. Failing early is still valuable because it teaches us what not to do.

Do

In this step, we do what we planned as the first steps towards our overall goal. How you proceed is context-specific, but early feedback is desirable to learn what works and what does not.

In software development, this might be after a few weeks of work (or sooner). For a business change programme, the feedback loop is likely to be longer to assess the impact of organisational changes.

Either way, the aim is to test out our ideas in a way that minimises risk and produces usefully significant outcomes before we have spent too much money and time.

Check

Here we close the feedback loop to analyse the results based on our benchmarking activities. At the very least there is a discussion to see if our actions have had the intended impact.

There are different views to consider. Does the solution work correctly and does it meet the actual business needs? The other aspect is whether the process we are following to deliver the solution works: is it effective, or should we refine it too?

Act

In the final step, we look at how to make improvements to our process. Observations from the previous steps help us identify issues with our ways of working and the solution. More often than not, these issues were not foreseen and are only identified after they have occurred.

At the end of this step, we should have better ways of working or even a refined overall goal. This learning feeds into the next Plan step as the PDCA cycle repeats.

Short feedback cycles are better than long ones. Knowing whether something works prevents you from investing too long in a bad approach. Fast feedback reduces the risk of getting it wrong and gives more room to experiment. When things are still fresh in people's minds there are more details they can reflect upon.

Problems and errors identified should not be repeated in the next cycle. We have the opportunity to make informed and timely course changes. Whatever the context, the PDCA cycle repeats based on improved knowledge with the next experiment.

PDCA in Action: Agile, Legacy Projects, and AI

PDCA is a natural way of working. It is how most people learn without even realising it. Here are a few examples.

Agile Timeboxes

Within most agile frameworks, timeboxes are used to control and manage work. A timebox is a fixed period of time with an overall goal. In Scrum it's called a Sprint; in SAFe and other frameworks it's known as an iteration.

Agile timeboxes map directly to PDCA:

Plan - Timebox Planning: what is the goal, what can we deliver, how will we do it?
Do - Execute the plan to build and test the product
Check - Timebox Review: how did we do?
Act - Timebox Retrospective: where can we improve our ways of working?

Legacy Project Management

A more traditional waterfall project can also be thought of as a long PDCA cycle:

Plan - Analysis and design phase to create a project plan
Do - The plan is executed through a development phase
Check - Deliverables are verified during a test phase
Act - Project review to assess success and capture lessons learned

The issue with this approach is that the feedback loop is too long. We don't get feedback early enough to make changes based on learning. Solutions are built on assumptions and a general misunderstanding of business needs.

AI-Assisted Work

PDCA is equally relevant when working with AI tools. Every prompt is a micro-PDCA cycle:

Plan - Define what you need the AI to do and what a good result looks like
Do - Run the prompt or task
Check - Review the output critically. Is it accurate? Is it useful? Does it meet the need?
Act - Refine the prompt, adjust the approach, or change direction entirely

The teams getting the most from AI are the ones running tight PDCA loops: trying something, checking the output honestly, and iterating quickly. The teams struggling are the ones who skip Check and Act, accepting whatever the AI produces without critical review.

How PDCA Connects to the Build-Measure-Learn Loop

If PDCA sounds familiar to anyone who has read Eric Ries's The Lean Startup, it should. The Build-Measure-Learn (BML) loop is essentially PDCA applied to product innovation:

Plan becomes the Hypothesis (what assumption are we testing?)
Do becomes Build (the smallest thing that tests it)
Check becomes Measure (did it validate the hypothesis?)
Act becomes Learn (iterate, pivot, or stop)

The connection is not coincidental. Ries drew directly from Lean thinking, which drew from the Toyota Production System, which drew from Deming's PDCA. The ideas are centuries old. The applications keep evolving.

For more on how BML applies to AI-assisted product development, see our post on MVP Thinking in the Age of AI.

Conclusion

PDCA is a simple practice that can be applied to many different contexts and at different levels of scale. It has its roots in ideas that go back centuries and have endured because they are pragmatic and common sense.

Like all adaptive approaches, it needs buy-in and support from senior leaders. Modern leaders need to understand and be comfortable with uncertainty. In many organisations, the development of products depends heavily on teams innovating and standing out from the competition.

Leaders need to foster a safe-to-fail culture that supports creativity and experimentation. Teams need room to learn, even if that means failing part of the time.

This is as true for AI adoption as it is for any other kind of change. The technology is new. The approach to navigating its complexity is not.

"There is no certainty; there is only adventure." - Roberto Assagioli

Related reading:

MVP Thinking in the Age of AI - how BML applies to AI-assisted product development
Humans in the Loop Is Not a Checkbox - using Cynefin to map where AI should lead and where humans must

References

Deming, W.E. (1986). Out of the Crisis. MIT Press.
Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
Senge, P. (1992). "Building Learning Organisations." Journal for Quality and Participation, March 1992.
Appelo, J. (2012). How to Change the World: Change Management 3.0.
Bacon, F. (1620). Novum Organum.

Alun Davies-Baker is an agile coach, trainer, and the founder of Altogether Agile. He helps organisations navigate complexity using empirical approaches grounded in Business Agility.