Plan, Do, Something, Act

Last night I attended a Heart of England Scrum User Group meetup where Mike Harris was asking So where did all this agile stuff come from? Luckily he was answering also: W. Edwards Deming.

Mike's presentation was a high-level overview of the history of Lean and Agile in which he traced back to foundational work done by Deming and then to Deming's influence Walter Shewhart who integrated scientific methodology and statistics into industrial quality practices.

I have read a little Deming but I'm motivated to look more deeply after this. In particular, Mike drew attention to the fact that Plan, Do, Study, Act and Plan, Do, Check, Act were, for Deming, very much not the same thing. I had never realised this. 

The paper Circling Back: Clearing up myths about the Deming cycle and seeing how it keeps evolving by Ronald D. Moen and Clifford L. Norman talks about the strength of Deming's feeling about it, quoting him:

They bear no relation to each other ... [PDSA] is a quality control program. It is a plan for management. Four steps: Design it, make it, sell it, then test it in service. Repeat the four steps, over and over, redesign it, make it, etc. Maybe you could say that [PDSA]  is for management, and the [PDCA] is for a group of people that work on faults encountered at the local level.

Their source is Proceedings from the U.S. Government accounting Office’s Roundtable Discussion Product quality — Japan vs. United States (1980) which looks like a fascinating document. Just prior to the words that Moen and Clifford cite, Deming says:

I think, to most people, quality assurance is figures that show where you have been, whereas quality control is a program for continual improvement.

Again that's not a distinction I'd come across before, at least not with those names. 

Given that I've done only a cursory review, my sense is that Deming is suggesting that both PDCA and PDSA are quality control programs, each wanting to incrementally act, inspect, and adapt, but that they operate at a different granularity and so will naturally have different real-world actvities.

Two of my own experiences come to mind. I have been struck many times by the fact that organisations will promote "agile" working practices yet persist in "big up-front design" for other activities, such as annual reviews. Management by do-what-I-say-not-what-I-do. 

I attended a Scrum Inc course last year and, when we were asked to summarise Scrum in 30 seconds or less, I encouraged my group to use PDCA to abstract away from the ceremonies and other process baggage. That kind of big picture view exposes the underlying iteration, inspection, and improvement cycle. The trainers said no-one had done that before on their courses and that, usually, people simply dive into the details of the practices.

What these anecdotes hint is that, while we can certainly argue the toss about S or C, there are probably more deep-seated concerns around people not being aware of the way they work, why they work that way, and the outcomes they create by doing so.

There's clearly plenty for me to dig into here. Mike shared his references after the talk:

P.S. I attended this meetup sitting in my freezing cold car outside the pool while my daughter was inside at swimming club. Drawing notes with icicle fingers by the light of my laptop screen was an interesting challenge and didn't result in much that was readable so I copied the scribble out tidily for here.