Category Archives: Quality tools

Management Blog Posts From October 2006

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

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 Malaysiabear warning sign on hiking trailVisual Instructions Example

Visual Management with Brown M&Ms

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 VisibleVisual Work InstructionsGood Process Improvement PracticesGreat Visual Instruction Example

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

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 ManagementHow to Get a New Management Strategy, Tool or Concept AdoptedChecklists in Software Development

One factor at a time (OFAT) Versus Factorial Designs

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 ExperimentsUsing Design of Experimentsarticles by R.A. Fisherarticles on using factorial design of experimentsDoes good experimental design require changing only one factor at a time (OFAT)?Statistics for Experimenters

Factorial Designed Experiment Aim

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

[the broken link to the embedded video was removed]

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 WebcastMihaly Csikszentmihalyi: Creativity, Fulfillment and Flowlean management, books, articles…

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.

Related: Future Directions for Agile ManagementMistake Proofing Deployment of Software ApplicationsChecklists in Software Development

Annual Management Blog Review: Software, Manufacturing and Leadership

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

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