I participated in the 4-day Scaled Agile Frame Program Consultant (SPC). Jennifer Fawcett and Mark Saymen facilitated this wonderful session. As part of the structured slides while furthering the discussion on the double operating system concept, discussions emerged regarding Deming's PDCA cycle. Later during the discussions, I heard participants discuss the need to give up project management principles towards the product management mindset. As the class continued, I heard root cause analysis discussed more as a technique rather than as tool to further the discussions in SAFe approaches that were introduced by Leffingwell (n.d.) in 2011 almost 10 years after the original Agile Manifesto was published to scale up agile in teams of teams at the business level. I echoed in the class and wrote to the facilitators the importance of how unsafely we are promoting techniques over principles without truly connecting with history. Here is my summary of these thoughts.
First, Deming did not conceptualize the PDCA cycle (Moen, 2010) and neither claimed ownership nor embraced it. Edward Deming worked under Walter Shewart, who iterated on his model of "specify, produce, inspect" around 1939 coming up with a "Design, Produce, Sell, Redesign" in 1950's as a starting point to initiate conversations around the need to have interactions across the value chain. Shewart drew his inspiration from two different sources (Moen & Norman, 2009). The first was John Dewey's pragmatic principles of product design. These pragmatic principles were called in four stages, "Discover, Invent, Produce, Observe." Separately, Clarence Irving Lewis was promoting a 3-step pragmatic learning concept "Experience, Application, Susceptibility" contributing to Shewart's inspiration of specify, produce, inspect.
Deming didn't package Shewart's cycle as Plan-Do-Check-Act at all. He called Shewart's cycle only Shewart's cycle in honor of his mentor. However, as the word spread around, the concept of Plan-Do-Check-Act emerged among the Japanese manufacturers crediting Deming with this concept. Contrary to the practitioners' thinking, such as the Agile Manifesto that prescribed "individuals and interactions over processes and tools" and SAFe that continue to build its premise on PDCA, Deming himself did not prescribe to this concept because he felt that this approach didn't promote the much-needed learning required in both the people and processes.
Separately, several contributors such as Alan Graham and Karou Ishikawa promoted many other concepts laying the foundation for quality to be a movement (Schneier, Russell, Beatty, & Baird, 1994) to promote continuous learning (hence Kaizen was born) but not limiting quality to be only incremental actions but also innovative big picture thinking (hence Kaikaku was born). So, many concepts like the Quality Function Deployment (QFD) and House of Quality (HOQ), Quality Circles, 5S principles, Design Thinking and Systems Thinking emerged (Senge, 1992). All these authors converge on the learning organization should inculcate building a shared vision, personal mastery, working with mental models, team learning and systems thinking. Empowered by these thoughts, Deming in 1993 conceptualized the need to 'study' creating the Plan-Do-Study-Act (PDSA).
So, the question is, why do practitioners continue to miss out history and go back to antiquated non-existing theory only to rest their blames on theory? Seems like this is the same thing that happened with Royce (1970) who iterated with dozens of pictures for a system development lifecycle (SDLC) model, but people stopped at the second figure in the first page creating a waterfall theory that never was proposed by Royce (Rajagopalan, 2014) to begin with!
Another thing to keep in mind is the principle of force-field analysis. This notion was promoted by Kurt Lewin (1939) who said a cause could be coming from forces that oppose (resistors) and support (enablers) a cause. We can see that all the time in any change - those that support and those that resist! Ishikawa approached the manufacturing context using his 4M (men, machine, method, materials) introducing the fish-bone diagram (Watson, 2004). Instead of only looking at Fishbone, many practitioners have incorporated the force field analysis over the root cause analysis as a combined approach to allow prioritization rather than just move forward with dot voting as the SAFe classes promote.
Now, let us ask ourselves. Do we work with various stakeholders and team members, sometimes with contracted workers, in product development? Is there some level of known scope of work we are committing to deliver on a specific schedule? Are we all working pro bono and getting materials free, or do we incur direct or indirect costs? Does quality factor into the way we work, delivering value to the customers? Aren't we impacted by assumptions that prove to be wrong or risks that come from known/unknown areas impacting us positively or negatively? Don't we hold ourselves to communicate through various means keeping everyone abreast of what's going on in our product development? When any one of these elements change, aren't we embracing them to evaluate how to pivot? Every one of these highlighted words represent a knowledge area in project management that product management cannot live without! The goal is not to give up these project management principles but adopt them and elevate to higher level systems thinking towards benefit sustenance and value delivery. Product Management mindset builds on Project Management basics!
