<img height="1" width="1" src="https://www.facebook.com/tr?id=2077527452260672&amp;ev=PageView &amp;noscript=1">

Plan - Do - Check - Adjust/Act (PDCA) Cycle in Lean-Agile

People are often so busy with the implementation that they put less attention to the previous steps that deal with the problem. That’s what creates a pitfall!

Without a clearly defined problem, how would you know what you’re trying to improve and how much you will need to do reach the goal? You would be attacking a target that doesn’t exist. Without thorough analysis, how would you know which target to point at? In my previous “Every problem-is-an-investment-opportunity…..” , we had a detail discussion on this.

The Agile process is an alignment and collaboration of many short cycles of PDCA (Plan-Do-Check-Adjust). This suggests that everything starts with a plan, but there are multiple steps we need to follow to develop an action-based plan.



(Note: You may have heard the PDCA cycle in different names like the Deming cycle, Shewhart cycle, Deming wheel, Control circle, or plan–do–study–act (PDSA))  

Plan: Develop an Action plan (Iteration Planning)

The industry has developed many tools to support the action planning but complex problems are still out of the capability. In Lean thinking “We believe, the method or tool is not as important the thought process and the skills of the user.” Because resources are sure to waste if the plan is unclear and everyone is not skilled enough to perform the task. In Toyota, the term “Countermeasure” is used to describe the proposed solution (Plans).

The countermeasures are mainly divided into:

  1. Short - term Countermeasures
  2. Long - term Countermeasures

In Toyota, It is generally taken that a large portion of countermeasures will be implemented quickly (Within a week). Therefore the definition of the short term and long term are according to the overall permanency of the countermeasures. Short term plans are utilized to reduce the defects and ensure that they will not result in the next process. They additionally minimize the lost production time due to the constant cleaning. In some circumstances, the short - term solutions become permanent if the teams don't find a more effective solution.

The long - terms are the most effective solutions. But these type of solutions are usually difficult or not possible to implement in the current capability. So, long - term solutions are only intended to permanently eliminate the root causes. Implementing it may take weeks to months. So, the teams usually divide the long-term plan into smaller increments. The process of smaller increments by reducing Muda (wastage) is known as “Heijunka” (Production Leveling or production smoothing).

In SAFe, the iterations are the shorter increments or the common short goals of the team according to the Team PI Objective and the outcome demoed at the team and system demos.

There are many benefits of short - term increments:

  • Smaller, bite-sized tasks provide a smaller check frequency interval.
  • The progression can be evaluated more closely and assistance can be given if the tasks fail to complete on schedule.
  • The ideas can run through testing after a shorter interval after a smaller percentage is completed rather than waiting for the entire process to end.
  • It gives a proper detail about what, who, when, where and how everything is working out.
  • The chances of successful completion are higher.


Do: Implementing Solutions (Executing the Iteration)

When can you declare a product completion? Most of us would answer -- when the goals are achieved. But in Lean, the answer lies in the successful achievement of smaller improvements by actively pursuing the issues at all levels. One must continue to observe and correct until the process creates lesser problems requiring modification and performs as planned.

Iteration execution is the process where implementation happens in Agile and the teams complete the “Do” part of PDCA cycle. In the daily stand-up, the teams evaluate the progressing work towards the goal and update each other about their development.

Check: Validation of Results (Team Demo)

It is necessary to have a comparison of results between the previous data and Post-improvement data. Because now and then surprisingly the teams discover the missing points in the prior data even if the idea was tested before. It happens because of the eagerness to solve the problem without knowing the problem clearly.

The team demo serves as the “Check” part of the cycle. As I have mentioned before, Teams deliver the stories in an iterative fashion. In the iteration demo, the teams show the tested incremental value (some percentage) to the Product owner, stakeholders (optional) and get feedback. The outcome of this meeting shows up in the backlog of the next iteration. The teams also participate in an integrated system demo. This is where all the coordination, collaboration, and alignment happens among the teams of Agile Release Train.

Adjust/Act: Make necessary Adjustments (Improving the Process)

This entire process is a continuous progression -- Developing hypothesis, testing, measuring the outcomes and adjusting for the desired result. A thorough understanding of the root causes and team's contribution towards the problem makes the upcoming changes predictable.  

Sometimes finding the solution is easy but implementation becomes difficult and it’s not uncommon for a solution to create other problems. In some cases, the core problem is often broken into smaller ones. So, continuous improvement is necessary to address those subproblems.

 “Don’t try to eliminate all the problems since that is unlikely and you could work towards that goal for a lifetime!”

-- The Toyota Way field Book


Once the solutions become reality, it is wise to ensure the adjustments. Follow Genchi Genbutsu (actual place or actual thing) and observe the new process whether it is free from major problems or not. The responsibility issues play a bigger role in Action and improvement (or reflection activities).

(Note: It’s not one person’s responsibility but rather the entire team has enough responsibility to take part in the product completion.)

Iteration retrospectives such stages where both the action with improvement occurs. The teams evaluate the process data (both prior and after), the improvement items, problems, root causes that goes to the next iteration team backlog. The product owner is responsible to refactoring, re-prioritizing the old and new backlog items.

The “Adjust” phase of the cycle is there to encourage the relentless improvement at team levels. Some frustration may happen because of undesired results, but do not get panicked. This is the time to develop your leadership skills and change other’s behaviors to face the problems.






Like this post? Share it with friends