[HN Gopher] The PDSA loop - Plan-Do-Study-Act
___________________________________________________________________
The PDSA loop - Plan-Do-Study-Act
Author : nsoonhui
Score : 76 points
Date : 2022-11-03 07:11 UTC (1 days ago)
(HTM) web link (commoncog.com)
(TXT) w3m dump (commoncog.com)
| lupire wrote:
| 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)
| saltcured wrote:
| 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.
| halJordan wrote:
| There's a bunch of versions. You can also Orient, Observe,
| Decide, and Act.
| lupire wrote:
| Measure, Understand, Solve.
| raydiatian wrote:
| Scientific method has so many pen names: OODA loop, Deming
| cycle...
| chrisseaton wrote:
| 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.
| raydiatian wrote:
| > 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.
| Jtsummers wrote:
| 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.
| [deleted]
| Naga wrote:
| 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.
| chrisseaton wrote:
| 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.
| cosmojg wrote:
| > 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!
| chrisseaton wrote:
| 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.)
| aaronharnly wrote:
| 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.
| RandomWorker wrote:
| 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.
| don_albrecht wrote:
| 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.
| beebmam wrote:
| 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.
| don_albrecht wrote:
| 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.
| heavenlyblue wrote:
| It feels like that is essentially the main selling point of
| working for a consultancy
| LAC-Tech wrote:
| 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?
| Jtsummers wrote:
| 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.
| taeric wrote:
| 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.
___________________________________________________________________
(page generated 2022-11-04 23:02 UTC)