I’ve read a few posts across the web over time in which Agile Cult proponents have tried to tie the Agile Manifesto as being on a continuum from Deming. Given the #NoEstimates drive you would expect someone to cherry pick a portion of item 3 of his Fourteen Points of Management, that is, “Cease dependence on inspection to achieve quality,” omitting the remainder of the point: “Eliminate the need for inspection on a mass basis by building quality into the product in the first place.” There are even a few that have attempted to appropriate Deming’s work by redefining the meaning of his systems approach and philosophy. (A classic symptom of ideologues and cults, but more on that in a later post).
W. Edwards Deming was from all accounts a brilliant statistician. In 1927 he met physicist and statistician Walter A. Shewhart of Bell Telephone Laboratories who is generally accepted as the originator of statistical quality control. Shewhart’s work focused on processes and the related technical tool of the control chart. One of his most important observations was his data presentation rules, which are:
1. Data have no meaning apart from their context and,
2. Data contain both signal and noise. To be able to extract information, one must separate the signal from the noise within the data.
These concepts are extremely important in avoiding the fallacy of reification, in which to regard something abstract as a material or concrete thing. This is a concept that I have come back to at various times in this blog, particularly as it relates to statistical performance measures such as EVM and risk measurement. Shewhart’s work no doubt was influenced by the work of astronomer, statistician, mathematician, and philosopher Charles Sanders Peirce in this regard.
Another important feature of Shewharts approach was the development of the Shewhart or Deming (Plan-Do-Study-Act) cycle. This is:
-
Plan: identify what can be improved and what change is needed
-
Do: implement the design change
-
Study: measure and analyze the process or outcome
-
Act: if the results are not as hoped for
Deming’s insight and contribution came when he realized that Shewhart’s methods not only applied to equipment performance but also to both manufacturing and management practices. He further refined his methods by applying and training U.S. war industry personnel in Statistical Process Control (SPC) during the Second World War. After the war he served under General MacArthur during the U.S. occupation and rebuilding of Japan as a census consultant to the Japanese government. He then made his mark in assisting Japanese industry in applying his statistical and management methods to their rebuilding efforts.
To illustrate how different Deming was from Agile and #NoEstimates, it is useful to understand that the purpose of his methods, rooted in empirical methods (the accepted definition and not the appropriated ideological Agile definition), were focused on improving quality and reducing costs. The formula for this approach is summed up as follows:
Quality = Results of Work Efforts/Total Costs
We have seen the validation of this formula with each generation of technological development, particularly in software and hardware development. But in order to gauge success in order to insert quality into the process we must estimate, measure, inspect, and validate. These are elements of the feedback loop that are essential in establishing a quality improvement process.
As Dave Gordon at the Practicing IT Project Manager blog stated in his post entitled Received Knowledge, Fanaticism, and Software Consultants, in the end, for all of the attempts at special pleading and to misdirect the assessment of risk in the system through Agile methods, it still all comes down to coding–and coding quality can be measured. “But this doesn’t drive out fear!” can be heard in the reply by mediocre Agile coders, cherry picking Deming. No, not if you’re not creating quality code in this particular example. Human Resources Management (HRM) for good and bad is a leadership and management responsibility, and nowhere in a full reading of Deming does he eliminate these decisions given the denominator of cost in the equation of quality.
This is one aspect of IT coding that is slightly different from our other systems: software design and coding is as much as an art as a skill. This is what we mean by elegance when we see well written code–it coheres as a simple systemic solution to the problem at hand that maximizes performance by leveraging the internal logic of the language being used and, as such, avoids defects not only in its current version but also is written in such a way that its internal logic, simplicity, and cohesion will allow for incremental improvement, and the avoidance and elimination of defects in future builds.
My first real life experience with this concept came during my first assignment as a project manager when I was a young Navy Lieutenant in San Diego. I had just learned how to code software and had performed at the top of my class in pursuing a degree in software engineering. This apparently qualified me in the eyes of my superiors to take over a failing program (read to mean: above cost and behind schedule) tasked with building a standard procurement system for the Navy (later the joint procurement system). In reviewing the reasons for failure it became apparent that the army of systems analysts, technical consultants, and software developers were pulling the effort into conflicting directions. My first act was to narrow the field to one lead developer and one very good coder, letting the rest to find other employment. I then pared from there in building a cohesive team (within the realistic span of control) focused on quality and project success after we had defined what success would look like. And, yes, we used estimates. We recovered the program in six months until it was transferred to D.C. and placed under a more senior officer–the occasional price of success.
Neither Deming’s propositions nor Agile software development methodology are received knowledge or wisdom (see my last post on Carl Sagan), though the latter makes special pleading along those lines. Both are open to questioning, validation, and testing. This principle is implicit in Deming’s own System of Profound Knowledge regarding what he described as the Theory of Knowledge–an approach resting firmly within the principles of the scientific method. Manifestos are beliefs, opinions, and assertions absent proof and, as such, many of the propositions of Agile are worlds away from Deming.
Note: Minor edits made to correct grammatical errors in the original.
Life, Project Management, and Everything 