Editor’s Note: Original blog was published on Nov 4, 2016
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 to 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 detailed 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 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:
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 constant cleaning. In some circumstances, the short - term solutions become permanent if the teams don't find a more effective solution.
The long - term are the most effective solutions. But these types of solutions are usually difficult or not possible to implement in the current capability. So, long - term solutions are only intended to eliminate the root cause permanently. Implementing it may take weeks to months. Thus, 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:
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 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 the PDCA cycle. In the daily stand-up, the organizations 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.
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 the team's contribution to 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 a reality, it is wise to ensure the adjustments. Follow Genchi Genbutsu (an actual place or actual thing) and observe the new process, whether it is free from major problems or not. The responsibility issues play a more significant role in Action and improvement (or reflection activities).
(Note: It's not one person's responsibility, but rather the entire team has enough trust to take part in the product completion.)
Iteration retrospectives such stages are the action, where improvement occurs. The teams evaluate the process data (both prior and after), the improvement items, problems, root causes that go to the next iteration team backlog. The product owner is responsible for refactoring, re-prioritizing the old and new backlog items.
The "Adjust" phase of the cycle is there to encourage constant 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.
REFERENCES:
http://www.scaledagileframework.com/iterations/
http://agileinaflash.blogspot.in/2009/07/plan-do-check-act.html
https://agilecraft.wordpress.com/2010/11/24/pdca-cycles-and-scrum/
