Tag Archives: variation

Interview of Bill Hunter: Statistical Variability and Interactions

Interview of Bill Hunter on Statistical Variability and Interactions by Peter Scholtes, 1986:

In this interview Bill Hunter describes how results are made up of the impact and interactions of many variables. Many of those variables we don’t know about or account for. What we normally do is try to figure out the most important variables for processes and then experiment with those variables to find the best options given what we are trying to achieve.

Often the description of what is going on in such cases is that there is arbitrary error or random variation that influences the final results. What Bill discusses in this interview is that what is seen as arbitrary or random is often identifiably caused by specific variables. But often we don’t know what those variables are or how they are varying while we are getting different results over time.

He discusses how many research efforts seek to find the most important 2 variables and create a model based on those 2 variables to predict results. Even in PhD level research that is often done. He then discusses how to deal with other important variables.

He discusses the real world problems businesses must face in creating solutions that work.

If they are going to sell the product in Mississippi, and they are going to sell in Arizona and North Dakota, they have to have a robust product that will work in all these different conditions… It is not good enough for them to have a model that works sometimes… they’ve got to probe deeper and learn how relative humidity affects things and build that into the whole system in a different kind of way… they have to try and dig out the effects of these other x’s

So the business has to figure out the impact of many more variables in order to create reliable and robust products and services. This example is about variables that impact the use of the product by a customer, but the same concept applies to processes within your business.
Continue reading →

Don’t Expect Short Quotes to Tell the Whole Story

When people try to use a short quote as an accurate encapsulation of a management concept they will often be disappointed.

It is obvious that Dr. Deming believed that organizations failed to use data effectively to improve needed to change and use data effectively in order to thrive over the long term. He believed that greatly increasing the use of data in decision making would be useful. He also believe there were specific problems with how data was used, when it is was used. Failing to understand variation leads to misinterpreting what conclusions can appropriately be drawn from data.

Using data is extremely useful in improving performance. But as Deming quoted Lloyd Nelson as saying “the most important figures that one needs for management are unknown or unknowable.”

I believe Dr. Deming would have said something like “In God we trust, all others bring data” (I haven’t been able to find a source verifying he did say it). Others don’t believe he would referencing the Lloyd Nelson quote and all Deming’s other work showing that Dr. Deming’s opinion that data isn’t all that matters. I believe they are correct that Dr. Deming wouldn’t mean for the quote to be taken literally as a summation of everything he ever said. That doesn’t mean he wouldn’t use a funny line that emphasized an important message – we need to stop relying so much on unsubstantiated opinion and instead back up opinion with data (including experiments).

Quotes can help crystallize a concept and drive home a point. They are very rarely a decent way to pass on the whole of what the author meant, this is why context is so important. But, most often quotes are shared without context and that of course, leads to misunderstandings.

A funny example of this is the Deming quote that you often see: “if you can’t measure it, you can’t manage it.” Deming did actually say that. But without the context you get 100% the wrong understanding of what he said. Deming’s full statement is “It is wrong to suppose that if you can’t measure it, you can’t manage it – a costly myth.” Now normally much more context is required to truly understand the author’s point. But this is a funny example of how a quote can be even be accurate when passed on to you and yet completely misleading because it is taken out of context.

Continue reading →

Special Cause Signal Isn’t Proof A Special Cause Exists

One of my pet peeves is when people say that a point outside the control limits is a special cause. It is not. It is an indication that it likely a special cause exists, and that special cause thinking is the correct strategy to use to seek improvement. But that doesn’t mean there definitely was a special cause – it could be a false signal.

This post relies on an understand of control charts and common and special causes (review these links if you need some additional context).

Similarly, a result that doesn’t signal a special cause (inside the control limits without raising some other flag, say a run of continually increasing points) does not mean a special cause is not present.

The reason control charts are useful is to help us maximize our effectiveness. We are biased toward using special cause thinking when it is not the most effective approach. So the control chart is a good way to keep us focused on common cause thinking for improvement. It is also very useful in flagging when it is time to immediately start using special cause thinking (since timing is key to effective special cause thinking).

However, if there is result that is close to the control limit (but inside – so no special cause is indicated) and the person that works on the process everyday thinks, I noticed x (some special cause) earlier, they should not just ignore that. It very well could be a special cause that, because of other common cause variation, resulted in a data point that didn’t quite reach the special cause signal. Where the dot happened to land (just above or just below the control limit – does not determine if a special cause existed).

The signal is just to help us systemically make the best choice of common cause or special cause thinking. The signal does not define whether a special cause (an assignable cause) exists of not. The control chart tool helps guide us to use the correct type of improvement strategy (common cause or special cause). But it is just a signaling device, it isn’t some arbiter of whether a special cause actually exists.

Continue reading →

Introductory Videos on Using Design of Experiments to Improve Results

The video shows Stu Hunter discussing design of experiments in 1966. It might be a bit slow going at first but the full set of videos really does give you a quick overview of the many important aspects of design of experiments including factorial designed experiments, fractional factorial design, blocking and response surface design. It really is quite good, if you find the start too slow for you skip down to the second video and watch it.

My guess is, for those unfamiliar with even the most cursory understanding of design of experiments, the discussion may start moving faster than you can absorb the information. One of the great things about video is you can just pause and give yourself a chance to catch up or repeat a part that you didn’t quite understand. You can also take a look at articles on design of experiments.

I believe design of experiments is an extremely powerful methodology of improvement that is greatly underutilized. Six sigma is the only management improvement program that emphasizes factorial designed experiments.

Continue reading →

Agile Story Point Estimation

In agile software development tasks are documented as user stories. Then the level of effort for those stores can be estimated by assigning each story points. The velocity that can be produced in a period (called a sprint, for us 2 weeks) can be estimated. Thus you can predict what can be delivered in the next sprint (which can help business managers make priority decisions).

I have found estimation to be worthwhile. In doing so, we accept there is a great amount of variation but points give a hint to scale. They can help prioritize (if you have 5 things you want but 1 is much harder you may well drop that to the bottom). I have always accepted a great amount of variation in the velocity, worry about the variation I don’t find worthwhile. I do think trying to act as though the velocity is precise can lead to problems. At the same time having a measure of velocity, even accepting understanding variation was present, was useful.

Over time reducing variation (probably largely through better estimation and perhaps a few better tools, reduced technical debt, better documentation, testing…) is helpful and laudable. We made improvement but still lots of variation existed. The biggest help in reducing the measured velocity was breaking down large stories to more manageable sizes. The challenge of estimating user stories, I suspect, has some fairly high variation (even with good system improvements that can help reduce variation).

Large stories just can hide huge variation in what is really required once getting into implementing it.

The way we did estimation (discussing in a sprint planning meeting) did take some time (but not a huge amount). It was agreed by those involved that the time spent was worthwhile. Sometimes we did slip and spend too much time on this, that was an area we had to pay attention to. The discussions were educational and helped provide guidance on how to approach the story. The value of discussions around estimations was probably the biggest surprise I have had in implementing any agile ideas. The value of those discussion was much higher than I imagined (I basically anticipated them just as non-value added time to get the result of an estimate, but they were a source of learning and consensus building).

These thoughts were prompted by: Story Points Considered Harmful – Or why the future of estimation is really in our past…

Continue reading →

Dr. Deming in 1980 on Product Quality in Japan and the USA

I posted an interesting document to the Curious Cat Management Library: it includes Dr. Deming’s comments as part of a discussion organized by the Government Accounting Office in 1980 on Quality in Japan and the United States.

The document provides some interesting thoughts from Dr. Deming and others; Dr. Deming’s statements start on page 52 of the document. For those really interested in management improvement ideas it is a great read. I imagine most managers wouldn’t enjoy it though (it isn’t giving direct advice for today, but I found it very interesting).

Some selected quotes from the document follow. On his work with Japan in 1950:

This movement, I told them, will fail and nothing will happen unless management does their part. Management must know something about statistical techniques and know that if they are good one place, they will work in another. Management must see that they are used throughout the company.

Quality control must take root with simple statistical techniques that management and everyone in the company must learn. By these techniques, people begin to understand the different kinds of variation. Then quality control just grow with statistical theory and further experience. All this learning must be guided by a master. Remarkable results may come quick, but one has no right to expect results in a hurry. The learning period never ends.

The statistical control of quality is not for the timid and the halfhearted. There is no way to learn except to learn it and do it. You can read about swimming, but you might drown if you had to learn it that way!

One of the common themes at that time was Deming’s methods worked because Japanese people and culture were different. That wasn’t why the ideas worked, but it was an idea many people that wanted to keep doing things the old way liked to believe.

There may be a lot of difference, I made the statement on my first visit there that a Japanese man was never too old nor too successful to learn, and to wish to learn; to study and to learn. I know that people here also study and learn. I’ll be eighty next month in October. I study every day and learn every day. So you find studious people everywhere, but I think that you find in Japan the desire to learn, the willingness to learn.

You didn’t come to hear me on this; there are other people here much better qualified than I am to talk. But in Japan, a man works for the company; he doesn’t work to please somebody. He works for the company, he can argue for the company and stick with it when he has an idea because his position is secure. He doesn’t have to please somebody. It is so here in some companies, but only in a few. I think this is an important difference.

At the time the way QC circles worked in Japan was basically employee led kaizen. So companies that tried to copy Japan told workers: now go make things better like the workers we saw in Japan were doing. Well with management not changing (and understanding Deming’s ideas, lean thinking, variation, systems thinking…) and staff not given training to understand how to improve processes it didn’t work very well. We (those reading this blog) may all now understand the advantages one piece flow. I can’t imagine too many people would jump to that idea sitting in their QC circle without having been told about one piece flow (I know I wouldn’t have), and all the supporting knowledge needed to make that concept work.

QC circles can make tremendous contributions. But let me tell you this, Elmer. If it isn’t obvious to the workers that the managers are doing their part, which only they can do, I think that the workers just get fed up with trying in vain to improve their part of the work. Management must do their part: they must learn something about management.

Continue reading →

Assigning Story Points to Bug Fixes

Agile software development has teams estimate the effort to deliver requests from the product owner. The estimates are done in points (in order to abstract away from hours – as estimates have plenty of variation in how long they will really take). Then the teams capacity (velocity) is determined based on looking at how many points they complete in a “sprint” (a set length, often 2 weeks). Then the product owner can prioritize all of the requests with an understanding of how much effort each is estimated to take and the historical capacity of the development team.

I think it is good to add point estimates to bugs. It may well impact how bugs are prioritized – if it is known to be simple a program manager may say, yes I want these 6 first then… If then know the first 2 are likely to take a bunch of time, they may think, ok, I am not going to get these 4 for awhile… They might just accept that, or may wish to shift more hours to bug fixes this sprint. Or they might say well if it is that big an issue maybe we could do x instead…

In practice I rarely has us estimate emergent bugs we are going to fix in the current sprint, but we do it for bugs that are in the backlog. I sometimes will have us estimate a current bug if I think it is may take significant time – to help determine what we really want to and what the impact may be on the teams output for the sprint. We do not have many emergent significant bugs so it isn’t much of an issue for us.

We do have more difficulty accurately estimating bugs, compared to new stories, but we still provide actionable estimates (they are not perfect, but are usable).

We use agile software development principles at work and they have been a great help in letting us be much more effective than we had been previously. The discussion of priorities and delivery expectations are much improved by such methods I believe. And unrealistic expectations can be reduced. For various reason, without adopting some form of agile/lean… software development methods the common pattern I see is software developers being frustrated by unrealistic expectation of their customers (project managers…) being frustrated by failure to communicate what it is reasonable to expect and status updates. A big part of this is the failure to acknowledge variation (and the related difficulty in estimation). Agile/Kanban… are systems that take the variation into account, and therefore the variation is dealt with as natural instead of leading to bad outcomes for developers and their customers.

Response to Should story points be assigned to a bug fixing story.

How to Manage What You Can’t Measure

In Out of the Crisis, page 121, Dr. Deming wrote:

the most important figures that one needs for management are unknown or unknowable (Lloyd S. Nelson, director of statistical methods for the Nashua corporation), but successful management must nevertheless take account of them.

So what do you do then? I am a strong advocate of Deming’s ideas on management. I see understanding system thinking, psychology, the theory of knowledge and variation as the tools to use when you can’t get precise measures (or when you can).

Even if you can’t measure exactly what you want, you can learn about the area with related data. You are not able to measure the exact benefit of a happy customer but you can get measures that give you evidence of the value and even magnitude. And you can get measures of the costs of dis-satisfied customers. I just mention this to be clear getting data is very useful and most organizations need to focus on gathering sensible data and using it well.

Without precise measures though you must use judgment. Judgment will often be better with an understanding of theory and repeated attempts to test those theories and learn. Understanding variation can be used even if you don’t have control charts and data. Over-reaction to special causes is very common. Even without data, this idea can be used to guide your thoughts.

The danger is that we mistake measures for the thing itself. Measures are a proxy and we need to understand the limitation of the data we use. The main point Deming was making was we can’t just pretend the data we have tells us everything we need to know. We need to think. We need to understand that the data is useful but the limitations need to be remembered.

Human systems involve people. To manage human systems you need to learn about psychology. Paying attention to what research can show about motivation, fear, trust, etc. is important and valuable. It aids management decisions when you can’t get the exact data that you would like. If people are unhappy you can see it. You may also be able to measure aspects of this (increased sick leave, increased turnover…). If people are unhappy they often will not be as pleasant to interact with as people who are happy. You can make judgments about the problems created by internal systems that rob people of joy in work and prevent them from helping customers.

For me the key is to use the Deming’s management system to guide action when you can’t get clear data. We should keep trying to find measures that will help. In my experience even though there are many instances where we can get definite data on exactly what we want we fail to get data that would help guide actions a great deal). Then we need to understand the limitations of the data we can gather. And then we need to continually improve and continually learn.

When you have clear data, Deming’s ideas are also valuable. But when the data is lacking it is even more important to take a systemic approach to making management decisions. Falling back into using the numbers you can get to drive decision making is a recipe for trouble.

Nice Non-technical Control Chart Webcast

This very brief introduction to control charts by PQ Systems provides a very watchable non-technical overview. Getting people to understand variation is important, and not easy. This video is one more quick reminder for those still trying to incorporate an understanding of variation into their view of the world.

The idea is simple. But actually thinking with an understanding of variation people find difficult, it seems to me. It is very easy to continue to revert to special cause thinking (who did it? is often a sign of special cause thinking) – thinking that results are due to a special (unique) cause, instead of as the result of a system (which includes lots of common causes).

The value I see in this video is as a reminder for all those trying to operate with an understanding of variation. It is also a decent introduction, but much, much more would be needed to get people to understand why this matters and what is needed.

Red Bead Experiment Webcast

Dr. Deming used the red bead experiment to present a view into management practices and his management philosophy. The experiment provides insight into all four aspects of Dr. Deming’s management system: understanding variation, understanding psychology, systems thinking and the theory of knowledge.

Red Bead Experiment by Steve Prevette

Various techniques are used to ensure a quality (no red bead) product. There are quality control inspectors, feedback to the workers, merit pay for superior performance, performance appraisals, procedure compliance, posters and quality programs. The foreman, quality control, and the workers all put forth their best efforts to produce a quality product. The experiment allows the demonstration of the effectiveness (or ineffectiveness) of the various methods.