Understanding Variation by Donald J Wheeler, Chapter 2 Notes

Notes from Chapter 2 of Understanding Variation: The Key to Managing Chaos, by Donald J Wheeler

The chapter is titled:"Knowledge is Orderly and Cumulative". Here Wheeler discusses three approaches to interpreting data, and the benefit of the control chart.

Two people may have access to the same set of data, but they can arrive at different conclusions. The reason is because they may have different interpretation processes.

Not all interpretation processes are valid. Wheeler describes two problematic approaches, and then discusses Shewhart's approach.

The Specification Approach

The first approach is 'comparison to specifications', or the Specification Approach. In this approach, data is interpreted in comparison to specifications, and its 'goodness' or 'badness' is determined based on how well it conforms to specifications.

For example, management may demand that the factory produce 1,000 units per month (the specification). If the factory produces 800 units in one month, that figure is interpreted as 'bad'.

Comparison by specification leads to binary results: either data conforms or it does not. it also leads to sudden changes in goodness or badness. A process could be in good graces one month, and in bad graces in another.

But the biggest problem with this approach is because specifications are the 'voice of the customer'. This is what the 'customer' wants.  The process has nothing to do with it. The voice of the process is what the process is able to achieve. If the voice of the customer and the voice of the process is not aligned, the result is people distorting the system or distorting the data in order to meet the specification on paper.

Nevertheless, the voice of the customer is important because it tells you when you're in trouble. 

The Average Value Approach

The Average Value approach compares the goodness of data against the average value of the data. "Why is sales 10% below last year's average?". This approach to interpreting data leads to pathologies similar to the Specification Approach -- people tend to distort the system or distort the data so they don't have to explain why the data is too far away from the average.

At least the Average Value approach uses the voice of the process (after all, the average value is produced by the process, and not some arbitrary number).

Shewhart's Approach to Interpreting Data

Walter Shewhart was the first to define the voice of the process. He called this a "control chart."

A control charts has time in the X-axis, has a central line, has two control limits, one on either side of the central line, both the same distance from the central line. The distance of the control limits is determined from the data, from the voice of the process. The values plotted can be raw data, or some value calculated from the raw data.

The control chart helps interpret the data by characterising the behaviour of the data and allowing us to predict the future behaviour of the data.

The control chart shows that there really is no distinction between good outcomes and bad outcomes; they both came from the same process.

A process that is in control is predictable. In other words, we can predict its behaviour in the future and make plans based on that prediction.

The Second Principle for Understanding Data

Shewhart's second principle for understanding data is:

While every data set contains noise, some data sets may contain signals. Therefore, before you can detect a signal within any given data set, you must first filter out the noise.

(His first principle is introduced in Chapter 1. It's: No data have meaning apart from their context.")

The two mistakes that could be made in analysing data is treating random variation as a meaningful departure from the past, and the second mistake is not recognising when data is a sign of change.

Attempting to avoid the first mistake by not reacting to variation can cause you to miss true signals of change, and thus make the second mistake. Attempting to avoid the second mistake by reacting to every signal causes you to make the first mistake

The key benefit of a control chart is it identifies for you data that is noise, and data that is signal.

Needs Versus Wants Versus Needs

Requirements professionals, who help shape the products are trained to: "Focus on needs, not on wants."

Sales professionals, who sell the products, are trained to: "Sell on wants, not on needs."

There seems to be a disconnect here somewhere.

***

When (Not If) Robots Take Over

We'll know the robots are taking over when CAPTCHAs begin to look like this.

***

Another Root of Evil

Premature allocation of requirements is the root of many system architecture evils.

(With a hat tip to Donald Knuth, who coined: "Premature optimization is the root of all evil.")

***

Si Senor, I think with an Accent

Actor Giancarlo Giannini delivers a memorable line in the movie "A Walk in the Clouds". Giannini plays Alberto Aragon, a Mexican father, very protective of his daughter.  He reminds a younger American man (played by Keanu Reeves): "Just because I talk with an accent doesn't mean I THINK with an accent!".

He's right, however, he's only partly right.  He does think with an accent -- WE ALL THINK WITH AN ACCENT. 

Our 'thinking accent' is formed by our age, base intelligence, education, cultural background, industry, personal experiences, personality, values, fears, intentions, and so many other factors.  It makes each one of us see and process things differently from others.

***

A Collection of Short Posts 2

 Short posts I made on LinkedIn

Do rewards motivate people to behave in the desired manner, or do they just attract people motivated by rewards?

***

Soldier pinned down by enemy fire: "Fire Control, this is Foxtrot. We need close air support now! Over."

Fire control reservist (who is a Business Analyst in civilian life): "Foxtrot, that's a solution, not a requirement. What do you REALLY NEED? Over"

***

If you fail to plan, plan to be agile.

***

***

If you like putting out fires you should be a firefighter.

If you like recovering after a fire you should be in disaster recovery.

If you like tallying up the cost of fires you should be in accounting.

If you like analysing tradeoffs between the risk of fire and cost of prevention you should be an analyst.

If you like preventing fires you should be in safety or quality.

If you like monitoring distant fires and where they are heading you should be in risk.

If you like playing with fire you should be a scientist.

If you like harnessing fire you should be a manager or engineer or entrepreneur.

If you like starting fires you are just an arsonist.

***

If you attended a course that teaches how to do better in IQ tests, and you did get higher scores afterwards, did your IQ get higher, or did you just learn how to do better in IQ tests?

***

***

***

***

A Collection of Short Posts 1

 A collection of short posts I made on LinkedIn:

The MoSCoW priority labels coincidentally also describe Hitler’s and Napoleon’s changing attitudes toward capturing the eponymed city:

Must have it
Should have had it by now
Could have it still if only
Won’t have it.

* * * 

Not everything that matters can be measured
Not everything that can be measured matters

To twist JFK’s words:
Ask not what you can measure
Ask what measures can do for you

To badly paraphrase Einstein:
Everything that matters and can be measured must be measured, but no simpler

***

Carpe diem caveat – “Seize the day”, not “cease the day”. The intention may be the former; the result may be the latter.

***

Continuous improvement must seek to do two things: make existing processes better, and stop introducing new bad processes in the first place.

***

Remind your audience that THERE IS such a thing as a stupid question -- it’s the question you keep to yourself.

***

Lots of people talk about 'Systems Thinking'. What's the verb for doing systems thinking it? Shh... be quiet, I'm systems thinking!

***

If you believe that user stories are requirements, try calling them 'user requirements'.

***

What's the term to describe the opposite of scope creep -- when scope keeps getting reduced because we're running out of time or budget?

***