The PDSA loop – Plan-Do-Study-Act | Hacker News Reader

The PDSA loop – Plan-Do-Study-Act

commoncog.com

85 pointsnsoonhui24 comments

The key point is having the full iteration cycle. You can't learn from simply thinking, dreaming, and planning. You need to follow through and experience the consequences. That is what uncovers the unknown unknowns. Those things you can't plan for.

The inability to truly learn from the consequences of their actions is the primary criticism leveled against many consultants. they plan, they do but they rarely stick around for the study and act.

It feels like that is essentially the main selling point of working for a consultancy

You can indeed learn things when your models highly accurately reflect reality (or in situations where the models themselves are their own reality). Logic and mathematics are powerful tools for making discoveries and learning.

My PhD in a nutshell, only learned to close the loop in year 3 when I went from one paper in 2.5 years to 3 papers in 1.5 years.

I feel like I'm lacking imagination - the "act" sounds a lot like the "plan' to me. Surely you apply the things you've learned by making the next plan?

My take is that many get stuck in rapid cycles between "Plan and Do". Without taking the time to actually study the results to build plans based on what you find, you are likely not understanding why you are succeeding or failing.

That is, even if you are currently succeeding, if you are stuck in too rapid of a "plan and do" cycle, you are likely to get blind sided by what you aren't learning.

Loops like PDCA/PDSA aren't necessarily tight loops, where you immediately jump into the next. Since the objective is process/quality/whatever improvement the Plan phase is defining a plan to improve the process (sticking with that one). The Do phase is enacting the plan. The Study phase is studying the effect and learning. The Act phase is the continuation of the plan (if successful) or perhaps a rollback if not. Then, at some point, you start another loop (ideally this becomes continuous, but most orgs and teams aren't ready for that I've found). But again, continuous doesn't mean tight.

As a hypothetical, you get hired into a team that doesn't use version control (me 12 years ago, fortunately they already knew it was dumb and were fixing it). So you decide to introduce git. There are a dozen codebases and 30+ people on this system. So you start with one codebase and a coupe motivated individuals, you create a Plan. You plan to use gitlab or whatever and see if you can work out kinks (like merge conflicts that they never know about until testing because "merge" is "copy files into the same directory, keep the newest"). Then you Do the plan, you and the motivated individuals try it out for a cycle (whatever that means in this team). Then you study it, see if you had fewer issues, delivered faster, higher quality, fewer erroneous "merges" (probably none now). Then you Act, you roll out this process to the rest of the team and codebases.

And if your team is ready for it, you repeat this method over and over to reach continuous process improvement, tackling different aspects of the process and system that are causing problems.

I just started reading this which covers some similar topics: https://beautiful-programmers-stone.netlify.app/

If I had to give a one-sentence synopsis of the first chapters it would be that there are 2 ways of thinking about things/working: “packing” memorizing facts and following routine, and “mapping” compressing facts into truths via reflection.

The latter is what leads to the 10x programmer because they are able to move pieces of the map around in their brain and solve problems more creatively-and seems to be linked to the study component of this approach.

I’m still not really sure what the difference between the study and act steps are, but I like the philosophy in general.

This makes me think of the "MAPE loop" I encountered in a presentation in the bowels of an IBM research facility once. This was about autonomous systems but applies equally to cognition, and I think puts the phases in a more intuitive order.

Monitor (observe) the existing environment.

Analyze the data you acquired through monitoring.

Plan your actions based on analysis.

Execute your plan.

Lather, rinse, repeat.

There's a bunch of versions. You can also Orient, Observe, Decide, and Act.

Measure, Understand, Solve.

Scientific method has so many pen names: OODA loop, Deming cycle…

The key part of the scientific method is the hypothesis and then testing the hypothesis. The OODA loop doesn't have that. It's not the same thing.

I concur, though it’s fair to note that the PDSA loop / Deming cycle has an hypothesis embedded, in the form of a theory of action — “I hypothesize that changes X to the system/process will result in outcomes Y.”

Not the same as inference to the best explanation, but not unrelated.

> OODA loop doesn’t have that.

Feels pretty 1:1 to me. Both work to define a model & state (shared observe), both seek to identify ways to improve the model and/or state (orient/hypothesize), both take real world action to secure those improvements (do/act/test), both have ongoing feedback.

OODA may be more rapid and strategically oriented (haha), but they’re doubtless the same methodical approach at the end of the day.

I claim it’s scientific method having multiple pen names simply because scientific method is older than PDSA & OODA from late ‘50s. If OODA loop came from Sun Tzu, I’d say it’s all OODA loop pen names.

OODA loops might look superficially like the same concept, but that's hiding a lot of the complexity of it. The difference between the scientific method and OODA is that OODA is a framework for making decisions under extreme uncertainty. It's not just the feedback loop of continuous learning, but its about recognizing that your adversaries also have their own OODA loops and that if your loop operates faster than theirs, you have a distinct advantage. This implies both that you should make decision faster than your opponent, or that you should make your opponent make slower decisions (such as by causing confusion). Very powerful tool.

Right - the most important thing about OODA is realising that OODA itself can be an anti-pattern, and really you should be aiming to attack the enemy's OODA, not worrying about your OODA so much.

Has anyone else seen the animation of the two fists rhythmically striking each other at the same time, until one side accelerates their loop and strikes the enemy when they're not prepared?

'Shatter the enemy's cohesion and will to fight by getting inside their OODA loop' - that's the one-sentence summary of contemporary military thinking.

> Has anyone else seen the animation of the two fists rhythmically striking each other at the same time, until one side accelerates their loop and strikes the enemy when they're not prepared?

Please come back and share this if you remember what it is or where to find it!

I think the difference is OODA informs your actions. You aren't 'testing' the enemy - you're acting yourself.

(I've taught and applied OODA professionally.)

PDSA/PDCA are applied outside of combat (if we're comparing it to OODA) with training, exercise, and study. Learn what the aircraft can do and develop a new maneuver, practice the maneuver until it becomes automatic, then in combat with the OODA loop (tightened by training and practice) you apply the maneuver when it's appropriate to overcome your opponent.

PDSA/PDCA can improve the OODA loop because it can inform how you train, but the OODA loop is not PDSA/PDCA.

I prefer Shewhart cycle, personally, as did Deming. Deming popularized PDSA, but he gave the credit to Shewhart.

Do and Act are the same thing, so it's Plan-Act-Study-Act.

Why isn't it Plan-Act-Study and then loop? (BTW that looks a lot like Red-Green-Refactor)

Do and Act are not the same thing. Do is carrying out the plan. Act is revising the process so the next plan goes better.

While they're both implementation steps, they exist in different contexts. Same with Plan and Study. One is prospective and other retro/introspective, the former in regards to product, the latter with regard to process.

Reply on news.ycombinator.com