Posts about Quality tools

Managing Our Way to Economic Success

From Managing Our Way to Economic Success, Two Untapped Resources by William G. Hunter, my father. Written in 1986, but still plenty relevant. We have made some good progress, but there is much more to do: we have barely started adopting these ideas systemically.

there are two enormously valuable untapped resources in many companies: potential information and employee creativity. The two are connected. One of the best ways to generate potential information to turn it into kinetic information that can produce tangible results is to train all employees in some of the simple, effective ways to do this. Rely on their desire to do a good job, to contribute, to be recognized, to be a real part of the organization. They want to be treated like responsible human beings, not like unthinking automatons.

W. Edwards Deming has illustrated one of the troubles with U.S. industry in terms of making toast. He says, “Let’s play American industry. I’ll burn. You scrape.” Use of statistical tools, however, allows you to reduce waste, scrap, rework, and machine downtime. It costs just as much to make defective products as it does to make good products. Eliminate defects and other things that cause inefficiencies, and you reduce costs, increase quality, and raise productivity. Note that quality and productivity are not trade-offs. They increase together.

Potential information surrounds all industrial processes. Statistical techniques, many of which are simple yet powerful, are tools that employees can use to tap and exploit this potential information so that increasingly higher levels of productivity, quality, and innovation can be attained. Engaging the brains as well as the brawn of employees in this way improves morale and participation…and profits.

What is called for is constant, never-ending improvement of all processes in the organization. What management needs, too, is constant, never-ending improvement of ideas.

Related: William Hunter, articles and booksInvest in New Management Methods Not a Failing CompanyThe Importance of Management ImprovementStatistics for Experimenters

Statistical Engineering Links Statistical Thinking, Methods and Tools

In Closing the Gap Roger W. Hoerl and Ronald D. Snee lay out a sensible case for focusing on statistical engineering.

We’re not suggesting that society no longer needs research in new statistical techniques for improvement; it does. The balance needed at this time, however, is perhaps 80% for statistics as an engineering discipline and 20% for statistics as a pure science.

True, though I would put the balance more like 95% engineering, 5% science.

There is a good discussion on LinkedIn:

Davis Balestracci: Unfortunately, we snubbed our noses at the Six Sigma movement…and got our lunch eaten. Ron Snee has been developing this message for the last 20 years (I developed it in four years’ worth of monthly columns for Quality Digest from 2005-2008). BUT…as long as people have a computer, color printer, and a package that does trend lines, academic arguments won’t “convert” anybody.

Recently, we’ve lost our way and evolved into developing “better jackhammers to drive tacks”…and pining for the “good ol’ days” when people listened to us (which they were forced to do because they didn’t have computers, and statistical packages were clunky). Folks, we’d better watch it…or we’re moribund

Was there really a good old days when business listened to statisticians? Of course occasionally they did, but “good old days”? Here is a report from 1986 the theme of which seems to me to be basically how to get statisticians listened to by the people that make the important decisions: The Next 25 Years in Statistics, by Bill Hunter and William Hill. Maybe I do the report a disservice with my understanding of the basic message, but it seems to me to be how to make sure the important contributions of applied statisticians actually get applied in organizations. And it discusses how statisticians need to take action to drive adoption of the ideas because currently (1986) they are too marginalized (not listened to when they should be contributing) in most organizations.
Continue reading

People Cannot Multitask

There is plenty of research showing that people can’t multitask. But this knowledge is missed by many people. Here is another study showing this: Why We Can’t Do 3 Things at Once

That’s because, when faced with two tasks, a part of the brain known as the medial prefrontal cortex (MFC) divides so that half of the region focuses on one task and the other half on the other task. This division of labor allows a person to keep track of two tasks pretty readily, but if you throw in a third, things get a bit muddled.

“What really the results show is that we can readily divide tasking. We can cook, and at the same time talk on the phone, and switch back and forth between these two activities,” said study researcher Etienne Koechlin of the Université Pierre et Marie Curie in Paris, France. “However, we cannot multitask with more than two tasks.”

Now I wouldn’t base my judgement on this one study. But we don’t have to. Multitasking decreases productivity. The siren song of multitasking. Multi-tasking: why projects take so long. What we should strive for is flow, the opposite of multi-tasking.

The real world often requires dealing with many interruptions (forcing you not to multi-task but to break up your tasks into fragments). Single piece flow shows the value (the efficient system performance) of getting one thing done then picking up the next. Many interruptions force you to keep stopping and starting tasks. People think they are multi-tasking but in fact they are just doing 4 tasks serially switching back and forth between them. Which slows them down and increases the odds of forgetting something. In these environments checklists are even more important than if you are not being interrupted frequently.

Related: costs of context switchingThe Multi-Tasking MythInterruptions Can Severely Damage Performance

Mistake Proofing Deployment of Software Code

This is a continuation of my previous post: Improving Software Development with Automated Tests. Lets look at a typical poka-yoke example. A USB connector must be put in the right way up – for the connection to work properly and the communication to occur as intended. So to mistake proof the process the connector won’t allow the USB device to be put in upside down – the hardware connection designed to not allow that type of connection.

Using a deployment process that prevents code from being submitted that has an error follows a nearly identical process. The process blocks an error from being made. It seems to me a process that blocks code with a bug from being deployed with an error is the basically the same as a USB connection that will not accept the device being put in upside down.

Mistake proofing in no way should limit focusing on improving the process. Mistake-proofing a process both improves it (many poka-yoke solutions make the process easier to use) and prevents an error in case you still try something wrong. So I see the automated tests as a way to serve as a backstop, in case the process improvement you made to the software development process failed in some form. Then the automated testing required to deploy would prevent the introduction of that error to the production environment.

Related: Checklists in Software DevelopmentBaking in Quality to Software DevelopmentCombinatorial Testing for Software DevelopmentGreat Visual Instruction Example

Combinatorial Testing – The Quadrant of Massive Efficiency Gains

My brother, Justin Hunter, gives a lightning talk on Combinatorial Testing – The Quadrant of Doom and The Quadrant of Massive Efficiency Gains in the video above. The following text is largely directly quoted from the talk – with a bit of editing by me.

When you have a situation that has many many many possible parameters and each time only a few possible choices (a few items you are trying to vary and test – in his example in the video, 2 choices) you wind up with a ridicules number of possible tests. But you can cover all the possibilities in just 30 tests if your coverage target is all possible pairs. When you have situations like that you will see dramatic efficiency gains. What we have found in real world tests is greatly reduced time to create the tests and consistently 2 to 3 times as many defects found compared to the standard methods used for software testing.

You can read more on these ideas on his blog, where he explores software testing and combinatorial testing. The web base software testing application my brother created and shows in the demo is Hexawise. It is free to try out. I recommend it, though I am biased.

Related: Combinatorial Testing for SoftwareVideo Highlight Reel of Hexawise – a pairwise testing tool and combinatorial testing toolYouTube Uses Multivariate Experiment To Improve Sign-ups 15%What Else Can Software Development and Testing Learn from Manufacturing? Don’t Forget Design of Experiments (DoE)

Justin posted the presentation slides online at for anyone who is interested in seeing more details about the test plan he reviewed that had 1,746,756,896,558,880,852,541,440 possible tests. The slides are well worth reading.
Continue reading

Improving Software Development with Automated Tests

Automated software testing is a mistake proofing (poka-yoke) solution for software development.

The way automated testing works is that software code is written that tests the software code of the application. This automated testing code test that business rules are correctly being followed by the code in the application.

So for example, a user should not be able to create a new account without entering password. Then you create code that does not allow an account to be created without a password. And you write a test that passes if this is true and fails if it is false.

The best implementation will then not allow deploying code to your production environment until the code has passed all the automated tests. So if a software developer changes the code, the automated tests are all run and if there is an error noted by the automated testing the code cannot be deployed to the production environment. So, in the example above, if somehow the changes made to the application code somehow now let an account be created without a password the test would fail, and the developer would know to fix the problem before putting the code into production.

Thus automated testing mistake proofs the process. Now the mistake proofing is only as good as the test that are added. Software development is complex and if the code has an error (based on the business rules) that is not tested then the code can be deployed to production and affect customers. But it is a huge help in preventing many errors from affecting customers.

It seems pretty obvious but until the widespread adoption of agile software development techniques and frameworks that make it easy to adopt automated testing (like Ruby on Rails) this sensible process improvement tool was used far less often than you would think.

Related: Combinatorial Testing for SoftwareMetrics and Software DevelopmentChecklists in Software DevelopmentGoogle testing blogHexawise software testing blog

Toyota Stops Lines – Lots of Lines

The practice of stopping (either the machine automatically detecting a problem and stopping or a person stopping) the line when a problem is detected is part of Jidoka. Jidoka is also highlighting and making problems visible. Jidoka and Just in Time are the two pillars of the Toyota Production System. Today Toyota practiced Jidoka on a large scale: Toyota Halts Sales of Eight Models After Recall

Toyota Motor, still struggling to resolve a problem with accelerator pedals, said Tuesday it would temporarily stop selling and building eight models in the American market, including the popular Camry and Corolla sedans

“This action is necessary until a remedy is finalized,” Robert S. Carter, a Toyota group vice president, said in a statement. “We’re making every effort to address this situation for our customers as quickly as possible.”

Toyota said it would immediately stop selling the Camry, Corolla and Avalon sedans, Matrix wagon, RAV4 crossover, Tundra pickup, and Highlander and Sequoia sport utility vehicles. It will also stop building those models the week of Feb. 1. All of the vehicles are assembled in the United States or Canada, at a total of five plants.

The models affected accounted for more than a million sales in 2009, 57 percent of Toyota’s American total for the year.

The most recent recalls follow what Toyota insisted was a companywide effort to improve quality that was started by Katsuaki Watanabe, who served as its president before he was replaced last year by Akio Toyoda, grandson of the company’s founder.

My guess is there are quite a few people in Toyota that are getting a frustrated that they continue to have problems that they have been unable to successfully address. This strikes is as the kind of action initiated near the top of the organization chart to remind the organization that problems must be addressed immediately. It is not ok to continue business as usually when problems have not been addressed in the Toyota Production System. Toyota is capable of failing to live up to the principles of lean manufacturing. But they also seem to understand this risk and continue to strive to improve. To succeed though they need to improve results – intentions alone are not enough.

Related: Cease Mass Inspection for QualityRecalls at Toyota and SonyReacting to Product ProblemsWorkplace Management by Taiichi Ohno

Prophet Unheard: Dr. W. Edwards Deming – 1992

This is an interesting video on Deming and American management (by the BBC in 1992): Prophet Unheard. It includes some nice old footage of Deming in Japan. The importance of respect for people is clear and the video also touches on the idea the danger of relying on data (when you do not understand variation and that many important matters and unmeasurable). The video features many snippets of Dr. Deming speaking and includes Don Peterson, Ford CEO; Clare Crawford Mason, If Japan Can, Why Can’t We producer; and Myron Tribus.

Related: Dr. Deming Webcast on the 5 Deadly DiseasesRed Bead Experiment WebcastPerformance without Appraisalmanagement webcasts

Part two of the documentary explores the Deming Prize, understanding data and the PDSA cycle:
Continue reading

Video Overview of the PDSA Cycle

Robert Lloyd, PhD From the IHI Open School‘s, presents a nice overview of the PDSA Cycle (plan-do-study-act). The webcast includes an example of using PDSA to improve the discharge process for a hospital.

As I have said many times the keys to success are to turn the PDSA cycle rapidly, predict the results in advance, and analyze the results to continually improve. the Improvement Handbook is an excellent resource.

The IHI Open School is a great resource and exactly the type of thing organizations with a mission to improve performance should be doing. Provide resources online that are easy for people to access and then apply in their organization. See more management webcasts.

Related: Tom Nolan on PDSASaving Lives: US Health Care Improvement5 Million Lives Campaign

Making Better Decisions

I think the most important thing you can do to make better decisions is to learn from the decisions you make. It sounds easy, but very few people do so effectively.

The best strategy to learn from decisions is to:

Baking in Quality to Software Development

One of the reasons my organizations switched to Ruby on Rails for software development was the great integration with automated testing. We always wanted to have good test coverage on our software applications (which are web applications – some used only inside our organization) but didn’t actually find the time to do so. Since we adopted Ruby we have been doing much better in this regard. It isn’t just the switch to Ruby, of course, but the switch to Ruby coincided with the beginning of many improvements to our software development practices that have continually improved over the last couple of years.

Here is a post on How to build quality software by an agile, Ruby, lean software developer

I’ve mentioned previously about baking-in quality and not having developers throw code over a wall to testers.

Everyone on the team is concerned with not only assuring quality in what we deliver, but making it visible to ourselves and the business.

We work in an agile manner, iterating through development with extreme programming practices and Behaviour Driven Development. Facilitating our relationship with the business is Scrum and we utilise kanban principles and systems thinking to maintain a speedy throughput of high-quality work. This mixture allows us to communicate effectively, develop the correct features properly and continuously deploy our work when it is complete, thus maximising business value. I should also mention that we are fortunate enough to have our business people/customer sat across from us.

Without testers or a QA team there is no wall over which work can be thrown and the responsibility for quality absolved.

The inspection typically carried out end-of-cycle only yields bugs that were low severity and of no real impact to the end user.

An agile testing must-have, we use TeamCity to continuously run our unit tests on each check-in. We also execute our Cucumber acceptance tests on scheduled runs. The status of the builds are visible on dedicated monitors around the office as well as a nice 6′ projected screen.

via: @benjaminm

Related: Combinatorial Testing for SoftwareChecklists in Software DevelopmentSoftware Supporting Processes Not the Other Way AroundSoftware Development and Business Process SupportTop Blogs for Software DevelopmentHexawise: more coverage, fewer tests (my brother’s company)

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.

Related: Fooled by RandomnessPerformance Measures and Statistics CoursePerformance without AppraisalExploring Deming’s Management IdeasEliminate Slogans

Checklists in Software Development

Verify your work with checklists

WHO has recently shown that surgical deaths can be reduced by a third when hospitals follow their Surgical Safety Checklist. The checklist is very low tech. It includes questions like whether the patient has been properly identified, whether the proper tools are available, and whether everyone knows what kind of procedure is about to be done.

If a checklist so simple can save so many lives, I thought the technique could surely help us do better as well. So after reading about this study and their checklist, I’ve been pushing us to create checklists for all the common procedures at 37signals.

We now have checklists in Backpack for confirming that a feature is complete, we have a checklist for preparing the feature for deployment and for executing the deployment, and finally for verifying that the feature is working as expected in the wild.

It’s the kind of stuff that we all know, but that we’ll often forget if we’re not being reminded about it in the moment. Thinking back to the mistakes we’ve made in the past, there are plenty of those that could have been avoided or caught much earlier if we had been using checklists.

This is a great reminder of two things: using checklists and adopting good ideas. Checklists are a simple and effective quality management tool. We use them for our software development (I have been a bit slow at getting them in place but we have been making progress recently). Also this shows how management improvement should work. You get good ideas from others and adapt them for use in your systems. Copying what others do, doesn’t work well. But understanding the concepts they use to improve performance and then adapting those concepts to your organization is the path to improved performance.

Related: Checklists Save LivesFind Joy and Success in BusinessLean, Toyota and Deming for Software DevelopmentThe Power of a ChecklistMost Meetings are Muda

How to Create a Control Chart for Seasonal or Trending Data

Lynda Finn, President of Statistical Insight, has written an article on how to create a control chart for seasonal or trending data (where there is an underlying structural variation in the data). Essentially you need to account for the structural variation to create the control limits for the control chart. She also provides a Minitab project file. Both are available for download from the Curious Cat Management Improvement Library.

Related: Control Charts in Health CareCommon Cause VariationManaging with Control ChartsMeasurement and Data CollectionFourth Generation Management

ER Checklist

The popular ER TV show highlighted the importance of using checklists in surgery yesterday.

Such powerful quality tools, like the checklist, are just waiting to be used. But far too many fail to use these simple improvement tools. And in health care those failures are potentially critical.

Related: Checklists Save LivesThe Power of a Checklistmanagement improvement dictionaryArticles on Improving the Health Care System

Jeff Bezos and Root Cause Analysis

Jeff Bezos and Root Cause Analysis by Pete Abilla

There are several things amazing about this experience:

  1. Jeff Bezos cared enough about an hourly associate and his family to spend time discussing his situation.
  2. Jeff properly facilitated the 5-why exercise to arrive at a root cause.
  3. He involved a large group of stakeholders, demonstrated by example, and arrived at a root cause and he didn’t focus on symptoms of the problem.
  4. He is the founder and CEO of Amazon.com, yet he got involved in the dirt and sweat of his employees’ situation.
  5. In that simple moment, he taught all of us to focus on root causes — quickly — not heavily relying on data or overanalysis of the situation, and yet he was spot-on in identifying the root causes of the safety incident.

Using quality tools really works. Lots of people don’t use them. Improving is often not any more difficult than just applying tools that have been used for decades. Improving does not require rocket science. Just do the simple things and you are well on your way to great success. Of the 10 stocks in my original 10 stocks for 10 years post Amazon is one of 4 that are up.

Related: Bezos on Lean ThinkingAmazon InnovationBezos Webcast on the Internet BoomImprovement Tools and Improving ManagementRoot Cause AnalysisEuropean Blackout is Not “Human Error”

Checklists Save Lives

photo of surgery room

Checklists are a simple quality tool that have been used widely for decades. Pilots use them, without fail, to save lives. Some surgeons have been using them and the evidence is mounting that checklists can save many more lives if more in health care use them. Studies Show Surgeons Could Save Lives, $20B by Using Checklists

Eight hospitals reduced the number of deaths from surgery by more than 40% by using a checklist that helps doctors and nurses avoid errors, according to a report released online today in the New England Journal of Medicine.

If all hospitals used the same checklist, they could save tens of thousands of lives and $20 billion in medical costs each year, says author Atul Gawande, a surgeon and associate professor at the Harvard School of Public Health.

In his study, which was funded by the World Health Organization, hospitals reduced their rate of death after surgery from 1.5% to 0.8%. They also trimmed the number of complications from 11% to 7%.

The study shows that an operation’s success depends far more on teamwork and clear communication than the brilliance of individual doctors, says co-author Alex Haynes, also of Harvard. And that’s good news, he says, because it means hospitals everywhere can improve.

Researchers modeled the checklist, which takes only two minutes to go through, after ones used by the aviation industry, which has dramatically reduced the number of crashes in recent years.

This is more great evidence of the value of applying simple management tools that are already well known. The idea that improvement takes brand new breakthrough ideas is just plain wrong.

Related: Using Books to Ignite ImprovementThe Power of a ChecklistNew, Different, BetterManagement Improvement History and Health CareOpen Source Management TermsFast Company Interview with Jeff Immelt

Six Sigma v. Common Sense

Response to LinkedIn question: “Whether Six Sigma as a quality tool really delivers the benefits ? How does it makes difference from a common sense approach ? (Where the process wastes and the required solution is known / can be easily identified just by applying common sense)”

Six sigma (or another management improvement method) can help in several ways. First, lots of things that are sensible are not done. A method to assure that more sensible things are done is useful.

Second, many things are sensible, but are not sensible when looked at in isolation (sub-optimization). Six sigma can (not does, can – sometime this won’t happen) assist those in the organization to evaluate from a larger context than they normally do. So instead of say the IT department forcing everyone to use some poorly designed software because it is the cheapest thing for the IT department to support the added costs to the rest of the organization are more fully considered.

Third, many things that are sensible are not evaluated based on their sense but instead based on internal politics… A standard methodology can help focus people on the merits of a proposal instead of who said it (again six sigma can do this, often it fails as the organization continues to cling to old patterns of power over sense).

Fourth, many of the tools, go beyond what sensible people alone see (design of experiments, understanding variation, PDSA, systems thinking, root cause analysis). Using the tools can often lead to valuable discoveries that were not obvious without using the tools.

If the solutions were obvious why were they not done last year? It is true that there are often plenty of simple improvements waiting to be adopted because management has done such a poor job that obvious improvement are left undone. But once sensible management is in place, eventually those obvious improvement will be done and a more structured approach to finding improvement is valuable. Even simple concepts like letting those that work on the process improve the process are often ignored by organizations (even those saying they are doing six sigma, unfortunately). So I see a strong value in adopting management improvement principles and tools.

Related: Management Advice FailuresImprovement Tools and Improving ManagementSix Sigma PitfallsWhy Isn’t Work Standard?European Blackout: Not “Human Error”

Management Improvement Carnival #45

Read the previous management carnivals. Also see the management Reddit for popular new blog posts to include in future carnivals.

  • Hire them, fire them, do what you want with them by Jay Padinjaredath – “A quote from Deming: “In Japan when a company has to absorb a sudden economic hardship… First the corporate dividends are cut. Then the salaries and the bonuses of the top management are reduced…. Lastly, the rank and file are asked to accept pay cuts…”
  • The Art of the A3 by Matthew May – “Every A3 tells a story. And like every story, each one is a little different, style-wise. But like any good story, there’s a clear structure.”
  • Spirit of the Toyota Suggestion System by Mike Wroblewski – “Our job as lean leaders is to help create that environment and inspire everyone to act, to take action to make improvements.”
  • To Motivate or Not to Demotivate by Jurgen Appelo – “Some people tell me that ‘you cannot motivate a person’. You can only “remove the impediments that prevent a person from being motivated”. Or, in other words, ‘you can only eliminate demotivation‘. Well, I don’t agree!”
  • Managing To Learn by Tom Southworth – “PDCA, or continuous improvement, never has an end, does it? We’re not solving problems, we’re implementing countermeasures to make positive changes to an existing condition.”
  • Demotivating a (Good) Programmer by Louis Brandy – “consider this your executive summary: he is motivated because he likes the actual work. That’s the Achilles heel. Now, before you think you’ve got this problem solved, let me explain to you the secret to the secret: what he thinks is cool is almost beyond your comprehension”
  • Apologizing Does NOT Get to the Root Cause by Mark Graban – “if you’re just putting the fire out without looking for a root cause or for prevention, you’re going to have the same problem occur again.”
  • Continue reading

The Contradictions That Drive Toyota’s Success

An interesting article in this month’s Harvard Business Review looks at the seeming contradictions at Toyota – The Contradictions That Drive Toyota’s Success by Hirotaka Takeuchi, Emi Osono, and Norihiko Shimizu

Many of Toyota’s goals are purposely vague, allowing employees to channel their energies in different directions and forcing specialists from different functions to collaborate across the rigid silos in which they usually work. For example, Watanabe has said that his goal is to build a car that makes the air cleaner, prevents accidents, makes people healthier and happier when they drive it, and gets you from coast to coast on one tank of gas… Zenji Yasuda, a former Toyota senior managing director, points out the wisdom of painting with broad strokes. “If he makes [the goal] more concrete, employees won’t be able to exercise their full potential. The vague nature of this goal confers freedom to researchers to open new avenues of exploration; procurement to look for new and unknown suppliers who possess needed technology; and sales to consider the next steps needed to sell such products.”

A good explanation of how Toyota avoids the trap of arbitrary numerical goals (Innovation at Toyota).

Toyota’s eagerness to experiment helps it clear the hurdles that stand in the way of achieving near-impossible goals. People test hypotheses and learn from the consequent successes and failures. By encouraging employees to experiment, Toyota moves out of its comfort zone and into uncharted territory.

This is another key point often overlooked. Experimentation is key to gaining knowledge and improving. And they have steadily improved their method of experimentation building on the PDSA/PDCA cycle:

Toyota organizes experiments using strict routines, as is widely known. It has refined Plan-Do-Check-Act (PDCA), the continuous-improvement process used throughout the business world, into the Toyota Business Practices (TBP) process. The eight-step TBP lays out a path for employees to challenge the status quo: clarify the problem; break down the problem; set a target; analyze the root cause; develop countermeasures; see countermeasures through; monitor both results and processes; and standardize successful processes. Similarly, the A3 report… forces employees to capture the most essential information needed to solve a problem on a single sheet that they can disseminate widely.

Continue reading

  • Recent Trackbacks

  • Comments