Currently browsing the Quality tools Category

Recommended Posts: Standardized Work Instructions - Cease Mass Inspection for Quality - Visible Data - Evolution of the PDSA Cycle
Related: Management Improvement Tools Explained - 7 basic quality tools - PDSA - Control Chart - 5s - Kanban - Flowchart...


Agile Story Point Estimation

Posted on February 8, 2012  Comments (0)

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).

Related: Assigning Story Points to Bug Fixes – Mistake Proofing the Deployment of Software Code – Checklists in Software Development

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

Continue reading →

Pull Consulting: Immediate Management Consulting As You Need It

Posted on February 2, 2012  Comments (0)

I think the potential for consulting as you need it is great. I actually was looking into creating an application to support the ability to provide this service with someone else; but we just had too many other things going on. I have now made myself available for consulting you pull as you need it through MinuteBox. You can get consulting when you need it for as little time as you need.

So if you are trying to apply the ideas I discuss on this blog and run into issues you would like to get some help with connect with me and you can get some immediate coaching on whatever you are struggling with. I am offering a special rate of $1.99 a minute, for now. The graphic on the right of this post (any post on this blog, actually) will show if I am available right now (as does johnhunter.com). If so, you can connect and get started. If not, you can leave a message and we can arrange a time.

I am featured on MinuteBox with this cool graphic, isn’t it nice :-)

home page of MInute Box with John Hunter graphic

John Hunter feature on Minute Box homepage

One advantage of this model is that those of you following this blog have a good idea of what topics you would like to delve into more deeply with me. If you have any questions on a particular topic you would like answered today or arranging coaching on specific topics over a period of time or help planning a project or someone to bounce your ideas off give this consulting as you need it model a try.

For those of you management consultants reading this blog (I know there are many) you can create your own Minute Box account easily and provide this service also. And even if you are not a consultant if you have advice worth sharing (and I know there are many of you also) you can also set up an account.

Related: John Hunter’s professional life timeline – John Hunter online – John Hunter LinkedIn profile – Top Leadership blogs – Top Management and Leadership blogs – Top Management blog

Eliminate the Waste of Waiting in Line with Queuing Theory

Posted on December 15, 2011  Comments (2)

One thing that frustrates me is how managers fail to adopt proven strategies for decades. One very obvious example is using queuing theory to setup lines.

Yes it may be even better to adopt strategies to eliminate as much waiting in line as possible, but if there is still waiting in line occurring and you are not having one queue served by multiple representatives shame on you and your company.

Related: Customer Focus and Internet Travel Search – YouTube Uses Multivariate Experiment To Improve Sign-ups 15% – Making Life Difficult for Customers

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

Posted on December 5, 2011  Comments (0)

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 →

Management Blog Posts From October 2006

Posted on October 25, 2011  Comments (0)

I have selected a few posts from the Curious Cat Management Blog back in October 2006 for those of you who were not reading this blog then.

  • Why Pay Taxes or be Honest – “I don’t think acting illegally, immorally, unethically is excusable just because lots of other people are… It is sad how bad the behavior is that is considered acceptable.”
  • Hiring the Right Workers – “The job market is an inefficient market. There are many reasons for this including relying on specifications… Hiring is one of the area I think we could use some real innovation. I think much more flexibility would help.” I don’t feel as though any real progress has been made on better hiring in the last 4 years.
  • Righter Performance Appraisal – I know it is a silly title, but it is still one of my favorite blog post titles :-)
    • photo of Longwood Gardens

    Longwood Gardens. Delaware by John Hunter.

  • Deming Institute Conference: Tom Nolan – there are many important elements to managing well. Turning the PDSA cycle quickly is close to the top of those elements.
  • Google Shifts Focus – “Now that they have a bunch of decent, but not really great products, adjusting and taking the opportunity to improve those product makes sense.” You might think this is about the new initiatives Google’s new CEO, Larry Page, has been discussing but it isn’t. It is about one of Google’s previous efforts to focus and eliminate less important “distractions.”
  • Simple Cell Phone – “I don’t think these features are only desired in poor countries, but I am not basing that on any market research just my opinion. Complex devices with many points of failure (both technical failure and user inability to figure it out) should not be the only option.

Not Ambiguous Sign

Posted on August 18, 2011  Comments (0)

I like the series of posts by Jon Miller on Ambiguous signs (another example). Here is a sign that got my attention recently and they succeeded in keeping me away (which I think was their intention).

photo of sign showing gunman shooting someone, and warning in 5 languages not to enter

Photo in Johor Bahru, Malaysia near the Royal Palace by John Hunter.

The area is near the Royal Palace in Johor Bahru Malaysia, though I am not certain that is what the restricted area is. It isn’t obvious to me why this location requires shooting trespassers, but I took the idea from the sign to stay out. To me, this sign conveys pretty forcefully that you shouldn’t consider entering if you are not authorized to do so.

Related: Living in Malaysia – bear warning sign on hiking trail – Visual Instructions Example

Visual Management with Brown M&Ms

Posted on August 15, 2011  Comments (2)

When you hear about rock musicians having a clause in their contract that they must have a bowl of M&Ms in their dressing room with all the brown M&Ms removed you could be excused for thinking: what will these crazy celebrities do next. Well it might just be those crazy celebrities are using visual management (granted I think there could be better methods [a bit more mistake proofing where the real problems would be manifest] but it is an interesting idea). Basically if they didn’t have the bowl of M&Ms, or if the brown M&Ms were not removed, they could distrust the thoroughness of the contractors. And they would check to see what other, actually important, contractual requirements were not followed.

Righting The Wrongs: Van Halen and M&Ms

The staff at venues in large cities were used to technically-complex shows like Van Halen’s. The band played in venues like New York’s Madison Square Garden or Atlanta’s The Omni without incident. But the band kept noticing errors (sometimes significant errors) in the stage setup in smaller cities. The band needed a way to know that their contract had been read fully. And this is where the “no brown M&Ms” came in. The band put a clause smack dab in the middle of the technical jargon of other riders: “Article 126: There will be no brown M&M’s in the backstage area, upon pain of forfeiture of the show, with full compensation”. That way, the band could simply enter the arena and look for a bowl of M&Ms in the backstage area. No brown M&Ms? Someone read the contract fully, so there were probably no major mistakes with the equipment. A bowl of M&Ms with the brown candies? No bowl of M&Ms at all? Stop everyone and check every single thing, because someone didn’t bother to read the contract. Roth himself said:

“So, when I would walk backstage, if I saw a brown M&M in that bowl . . . well, line-check the entire production. Guaranteed you’re going to arrive at a technical error. They didn’t read the contract. Guaranteed you’d run into a problem. Sometimes it would threaten to just destroy the whole show. Something like, literally, life-threatening.”

Related: The Importance of Making Problems Visible – Visual Work Instructions – Good Process Improvement Practices – Great Visual Instruction Example

Good Execution Can Make Management Tools Like Time and Motion Studies Useful

Posted on August 11, 2011  Comments (0)

In my experience most management concepts are applied poorly. Many of the concepts may also be bad. For example, performance appraisals are both done poorly and a bad idea. The solution is not to do performance appraisal righter: for what to do read Peter Scholtes.

But, many tools and concepts that are applied with poor results, where the actual application is criticized (with good reason), can be used successfully. I would put benchmarking and time and motion studies in that category. Most of the time they are done poorly and produce bad results. But they can be done well, and provide value, so long as you have the right management system surrounding it and execute well. In practice I think, one thing that helps separate good managers from bad ones, is knowing how your organization will actually execute (not just dreaming about how nice things could be if only…) and not just trying things that they should know will produce bad results in their organization.

Based on my comment on: Time & Motion Studies Are Not “Discredited,” Just How They Are Used

Related: Improvement Tools and Improving Management – How to Get a New Management Strategy, Tool or Concept Adopted – Checklists in Software Development

One factor at a time (OFAT) Versus Factorial Designs

Posted on May 25, 2011  Comments (2)

Guest post by Bradley Jones

Almost a hundred years ago R. A. Fisher‘s boss published an article espousing OFAT (one factor at a time). Fisher responded with an article of his own laying out his justification for factorial design. I admire the courage it took to contradict his boss in print!

Fisher’s argument was mainly about efficiency – that you could learn as much about many factors as you learned about one in the same number of trials. Saving money and effort is a powerful and positive motivator.

The most common argument I read against OFAT these days has to do with inability to detect interactions and the possibility of finding suboptimal factor settings at the end of the investigation. I admit to using these arguments myself in print.

I don’t think these arguments are as effective as Fisher’s original argument.

To play the devil’s advocate for a moment consider this thought experiment. You have to climb a hill that runs on a line going from southwest to northeast but you are only allowed to make steps that are due north or south or due east or west. Though you will have to make many zig zags you will eventually make it to the top. If you noted your altitude at each step, you would have enough data to fit a response surface.

Obviously this approach is very inefficient but it is not impossible. Don’t mistake my intent here. I am definitely not an advocate of OFAT. Rather I would like to find more convincing arguments to persuade experimenters to move to multi-factor design.

Related: The Purpose of Factorial Designed Experiments – Using Design of Experiments – articles by R.A. Fisher – articles on using factorial design of experiments – Does good experimental design require changing only one factor at a time (OFAT)? – Statistics for Experimenters

Factorial Designed Experiment Aim

Posted on April 25, 2011  Comments (2)

Multivariate experiments are a very powerful management tool to learn and improve performance. Experiments in general, and designed factorial experiments in particular, are dramatically underused by managers. A question on LinkedIn asks?

When doing a DOE we select factors with levels to induce purposely changes in the response variable. Do we want the response variable to move within the specs of the customers? Or it doesn’t matter since we are learning about the process?

The aim needs to consider what you are trying to learn, costs and potential rewards. Weighing the various factors will determine if you want to aim to keep results within specification or can try options that are likely to return results that are outside of specs.

If the effort was looking for breakthrough improvement and costs of running experiments that might produce results outside of spec were low then specs wouldn’t matter much. If the costs of running experiments are very high (compared with expectations of results) then you may well want to try designed experiment values that you anticipate will still produce results within specs.

There are various ways costs come into play. Here I am mainly looking at the costs as (costs – revenue). For example the case where if the results are withing spec and can be used the costs (net costs, including revenue) of the experiment run are substantially lower.
Continue reading →

Why Lean is Different

Posted on April 12, 2011  Comments (0)


Why Lean is different by Operae_Partners

Short webcast by Michael Ballé discusses what makes lean manufacturing different: going to where the work is done, standardize processes (from the gemba view), practice respect for people and continually improve. Lean thinking focuses on achieving better results and through that process improves trust and teamwork internally, as well as better supplier and customer relationships.

Related: Non-technical Control Chart Webcast – Mihaly Csikszentmihalyi: Creativity, Fulfillment and Flow – lean management, books, articles…

Assigning Story Points to Bug Fixes

Posted on January 27, 2011  Comments (0)

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.

Related: Future Directions for Agile Management – Mistake Proofing Deployment of Software Applications – Checklists in Software Development

Annual Management Blog Review: Software, Manufacturing and Leadership

Posted on January 9, 2011  Comments (2)

In my contribution to the 3rd annual management blog roundup I will take a look at 3 blogs: Dennis Stevens, How to implement “Lean Thinking” in a Business and the Three Star Leadership Blog. This year 14 management bloggers contributed to highlight over 40 blogs, be sure to check out all the posts.

photo of Dennis Stevens

Dennis Stevens


Dennis Stevens writes a blog of the same name focused on agile software development principles with a strong focus on Dr. Deming’s ideas and lean thinking.

  • What’s Deming got to do with Agile – “Deming is not about manufacturing. He is about showing management how to create an environment for success. Deming is about culture – and his System of Profound Knowledge creates an environment that is especially effective for knowledge work… In knowledge work, where products are invisible, impact can be difficult to demonstrate. Kanban clearly shows progress and demonstrates the contribution of each person to the delivery of value. Additionally, PDSA provides opportunities for everyone to contribute to improving the quality of the organization’s capabilities.”
  • Kanban Mental Models and Double Loop Learning – “the Kanban cycle supports continuous learning that the team internalizes. Argyris’s model gives us some insight into why Kanban teams are consistently achieving double-loop learning and rapid maturity.”
  • We are Doing QQ All Wrong- “Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests… Test driven development or test just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation.”
  • Shorten and Reduce Variability in Lead Times Using Kanban – ” identify and leverage strategies like reducing waiting, reducing rework, making work ready, defining small size work, and swarming, to improve lead time. Tracking causes of defects and blockages can help make decisions to focus these strategies appropriately. Reducing lead time duration and variability will result in increased predictability, faster feedback, improved flexibility and responsiveness.”
photo of Tracey Richardson

Tracey Richardson

Tracey Richardson writes the How to implement “Lean Thinking” in a Business blog focused on the lean manufacturing and the Toyota Production System.

  • Common Mistakes when we are Problem Solving – “Not utilizing the ‘Power of the gemba’,–or often referred to as “Go see the work/process“.!! I often see teams working together in a room trying to solve the problem by using their experiences, hypothetical guesses, and what their opinion is. I quickly disperse the huddle to “go-see” with their own eyes the current situation.”
  • How many different types of A3′s are there? – “I will briefly describe the 4 different types of A3′s and when to use them based on my experience: Problem Solving A3, Proposal A3, Status Report A3, Strategic Planning A3. All A3′s should follow the PDCA thinking regardless of which type you are working on.”
  • Why is asking “Why” so important? – “It is important to ask why repeatedly when visiting the gemba to determine what is current happening versus what should be happening. In many cases we stop at a symptom to the problem because we are often pressured for results and quickly solving the problem without going past the symptom seems to be the best answer.” [this one is actually from 2009 but I included it anyway - John]

Building Adoption of Management Improvement Ideas in Your Organization

Posted on December 8, 2010  Comments (5)

Continuation of How to Get a New Management Strategy, Tool or Concept Adopted

Target something that actually provides a good story. It often helps if there have been failures in attempts to solve a problem in the past. That makes the new success more impressive. Something that is relate-able to the audience you are trying to win over is also useful. Even if senior management cares about an issue, if the solution is so technical they are completely baffled, they will be happy with a solution but they won’t be as excited about expanding the strategy you are trying to encourage when they can understand the process that lead to a solution.

Favor efforts that will help you build organizational capacity to do more of what you want going forward (adopt lean thinking, use design of experiments…). Some of this is about building expertise in the organization. It is also about building your circle of influence. Growing your ability to influence how the organization grows will help you encourage the improvements you believe in.

It is very helpful to show connections between individual efforts. Often you build using various tools: in several instances using PDSA cycle to guide improvement, in others mistake-proofing to cement improvement, in another adopting one piece flow to make problems visible and encourage improvement, in another assuring the respect for people to build the right culture for improvement, and in another using an understanding of variation to make evidence based decision rather than jumping to faulty conclusions with limited information. These management tools, concepts, methods and ideas any many more, are used together for a reason. They support each other. So it is very helpful if you tie them together. As you start adding new tools, ideas and concepts to the management system show how they support each other. Individual tools can help. But the gains they offer are minor compared to the gains possible with a systemic change of management.

Another good strategy is picking the right people to involve in an effort. If you are trying to gain support, find those people in the organization that set the tone that others follow (which are not merely those with organizational power due to their job title). It is nice if you can find such people that have generally positive outlooks and like new challenges (this is often the case). If the culture is very toxic you may well have some who are likely to try and discourage hope in others (often because they have been disappointed so many times themselves they have finally decided not to be disappointed again). Often (though not always) you can win these people over.
Continue reading →

How to Get a New Management Strategy, Tool or Concept Adopted

Posted on December 6, 2010  Comments (6)

Often when learning about Deming’s ideas on management, lean manufacturing, design of experiments, PDSA… people become excited. They discover new ideas that show great promise to alleviate the troubles they have in their workplace and lead them to better results. But how to actually get their organization to adopt the ideas often confounds them. In fact, I believe most potential improvements efforts may well fail even before they start because people can’t get past this problem.

I believe the way to encourage adoption of management improvement tools, methods and ideas is to solve people’s problems (or give them new opportunities). Instead of trying to convince people by talking about why they need to adopt some new ideas, I think it is much better to show them. To encourage the adoption of whatever it is (a philosophy like Deming or a new tool) try to find projects that would be good candidates for visible success. And then build on those successes.

For adopting whole new ways of working (like lean thinking) you go through this process many times, adding more and more new ideas to the accepted way of doing things. It is a bit easier if you are the CEO, but I think the strategy is very similar whoever you are. For smaller efforts a boss can often just mandate it. But for something like a large improvement in the way work is done (adopting a lean management system, for example), the challenge is the same. You have to convince people that the new methods and ideas are valuable and that they can use the ideas to help improve results.

Start small, it is very helpful if initial efforts are fairly small and straight forward. You often will have limited resources (and limited time people are willing to invest) at first. so start by picking projects that can be accomplished easily and once people have seen success more resources (including what is normally the most important one – people’s time) should be available. Though, honestly getting people to commit will likely be a challenge for a long time.

It is a rare organization that adopts a continual improvement, long term focus, system thinking mindset initially. The tendency is often strong to focus on fire fighting, fear (am I taking a risk by doing x, if I spend time improving y – what about the monthly target my boss is measuring me on…) and maintaining the status quo. It is baffling to many hoping for improvement, when you have huge successes, and yet the old way of doing things retains a great hold. The inertia of organizations is huge.
Continue reading →

Managing Our Way to Economic Success

Posted on August 23, 2010  Comments (0)

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 books – Invest in New Management Methods Not a Failing Company – The Importance of Management Improvement – Statistics for Experimenters

Stop Starting and Start Finishing – Jason Yip

Posted on August 5, 2010  Comments (1)

Jason Yip explores the value of reducing work in process and reducing context switching costs to optimize throughput. By designing processes to work on projects serially instead of in parallel we reduce context switching, and other costs, of multitasking.

Related: Multi-Tasking: Why Projects Take so Long – The Importance of Making Problems Visible – One piece flow (continuous flow) – Kanban

People Cannot Multitask

Posted on May 24, 2010  Comments (1)

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 switching – The Multi-Tasking Myth – Interruptions Can Severely Damage Performance

Mistake Proofing Deployment of Software Code

Posted on May 19, 2010  Comments (1)

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 Development – Baking in Quality to Software Development – Combinatorial Testing for Software Development – Great Visual Instruction Example

Combinatorial Testing – The Quadrant of Massive Efficiency Gains

Posted on May 17, 2010  Comments (1)

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 Software – Video Highlight Reel of Hexawise – a pairwise testing tool and combinatorial testing tool – YouTube 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 →

  • Recent Trackbacks

  • Comments