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.
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.
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?
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.
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.
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.
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.
[+] [-] don_albrecht|3 years ago|reply
[+] [-] don_albrecht|3 years ago|reply
[+] [-] beebmam|3 years ago|reply
[+] [-] RandomWorker|3 years ago|reply
[+] [-] LAC-Tech|3 years ago|reply
[+] [-] Jtsummers|3 years ago|reply
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|3 years ago|reply
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.
[+] [-] owenfi|3 years ago|reply
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.
[+] [-] saltcured|3 years ago|reply
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|3 years ago|reply
[+] [-] raydiatian|3 years ago|reply
[+] [-] chrisseaton|3 years ago|reply
[+] [-] argiopetech|3 years ago|reply
[+] [-] lupire|3 years ago|reply
Why isn't it Plan-Act-Study and then loop? (BTW that looks a lot like Red-Green-Refactor)
[+] [-] argiopetech|3 years ago|reply
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.
[+] [-] dev_0|3 years ago|reply
[deleted]