Agile is based on empirical process control — things are verifiable by observation or experimentation; transparency, Inspection and adaptation are the 3 pillars of empiricism.
Application: the famous Plan, Do, Check, Adjust/Adapt (PDCA) is a learning cycle…things are inspected and adaptation follows based on what has been learned and observed. This cycle occurs at every level be it team level, program level, or solution level… hence the mantra ‘Inspect and Adapt’ for relentless and continuous improvement.
At the program Level of SAFe, there is a program event called ‘Inspect and Adapt (I&A)’. No surprise there. The purpose of which is exactly that, to pursue relentless and continuous improvement.
It comes in three parts: 1) the system demo; 2) the quantitative measurement; 3) retrospective and problem solving workshop.
The system demo: This is the time for product manager and or product owner to demo the features — representing the business objectives — that were completed and accepted during the program increment, with the development teams and/or system team setting up the staging environment for the demo.
The quantitative measurement: during the system demo, business owners, customers and other vital stakeholders collaborate with the Agile team to rate the actual business value of the objectives. The planned and actual business values are input to the program predictability measure calculation….a measure of the predictability of delivery of value by the ART. As you can see in the image below, the sweet spot is between 80% and 100% predictability… otherwise, address and improve.
Retrospective and Problem solving workshop: in the retrospective part, the main idea is to identify significant problems for the teams to solve and the program to solve. It’s open season — anybody can nominate a problem to solve be that be at the team level or program level … self-selection of problem to solve is encouraged. This self-selection encourages cross-functional and multi-dimensional view of problems … and seeds the problem solving workshop with those who are most impacted and most voracious to solve the problem.
For program-level problem solving workshop, a structured approach is used … the six-step is illustrated in the image below. Follow the six steps from left to right top row first.
Remember relentless and continuous improvement? Yeah…make sure that you put the improvement items to the team/program improvement backlog and roadmap… and address / act upon these… otherwise, what’s the point of having this ‘Inspect and Adapt’?
Kaizen is about changing the way things are. If you assume that things are all right the way they are, you can’t do kaizen. So change something! —Taiichi Ohno
October 15, 2022: My new book, “SAFe Is Like …“, is now available on Amazon. 
You will get a FREE SIGNED COPY if/when you register, pay, and complete a class by the Lean Agile Guru.
