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.
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.
“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.”
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
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
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?
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.
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.
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.
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.
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.”
- 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]
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.
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.
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.
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.
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.
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
“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.
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.
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) – Maximize Test Coverage Efficiency And Minimize the Number of Tests Needed
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.
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.
Related: Control Charts in Health Care – How to Create a Control Chart for Seasonal or Trending Data – Measurement and Data Collection – Six Sigma and Common Sense – European Blackout, not Human Error
Toyota’s journey from Waterfall to Lean software development by Henrik Kniberg
A modern car is pretty much a computer on wheels! In a hybrid car about half of the development cost is software, it contains millions of lines of code as all the different subsystems have to integrate with each other. He mentioned that a Lexus contains 14 million lines of code, comparable to banking and airplane software systems. Ishi-san concluded that “Therefore Toyota needs to become an IT company”.
Most of Toyota’s ideas about how to do Lean software development resonated well with me. My feeling was that they are on the right track.
One thing bothered me though – the extreme focus on detailed metrics. I agree with the value of visualization, standardization, and data-driven process improvement – but only if used at a high level. My feeling was that Toyota was going to far. They say engineer motivation is critical, but how motivating is it to work in an organization that plans and measures everything you do – every line of code, every hour, every defect, how many minutes it takes to do an estimate, etc?
via: Justin Hunter
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. Automated software testing tools are 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.
Slogans mainly are bad. But like most things they can be used in ways that help or hurt. The main problem is when they substitute for a method to achieve the aim (most of the time). If the slogan serves like a mission statement to focus people on something useful to focus on and it is one minor part of a system to achieve a result it can be fine and even useful.
The issue, to me, is not so much that slogans are innately horrible. It is that, in practice, slogan are used in harmful ways most often (especially outside of sports). They tend to substitute for system improvement. The main work of shifting psychology (we do expect to win now, we do expect a focus on reducing bugs in our code…) after years of creating a different culture has to be in changing methods, priorities, values… Slogans, if done right, can be a way of focusing on the change. Or they can be a real reminder of values. But the slogan only provides value as part of a system confirming the aim they emphasis.
Unfortunately, they also to be used as a way to focus criticisms on individuals. Don’t you know/care that our slogan says zero defects? Can’t you read? Jeez, I even put up a huge poster with our slogan saying zero defects and you can’t even do what it says in this beautiful poster? Well, I will give you a bad performance review now, you can’t say you don’t have that coming after you failed to do what our slogan told you to do.
A slogan by itself has negative value. Take any wonderful slogan and move it somewhere else it will do more harm than good. As a minor part of a system though it can tap into how we people think and act (psychology) and provide value. Be careful though, it is much easier to do harm with slogans than to provide value.
If the slogan emphasizes what is being practiced every day, it can be a helpful reinforcer. If it conflicts with what is done every day it breeds cynicism and shows disrespect for people. This which is a huge problem. And managers have to know it is very easy for people to see the lack of cloths on the emperor slogan. Dilbert does a great job showing the risks of using slogans. Those you are targeting the slogan to are more likely to think like Dilbert than the they are to think like the pointy haired boss (and if you are the one pushing the slogan that means you are well on your way to being the phb – so be careful).
Slogans clearly fall under Deming’s understanding psychology area of management. To use them effectively you need to make sure the value provided, exceeds the cost and risk. I see no better way to evaluate slogans than through the lens of Deming’s system of management, interdependent components of: psychology, systems thinking, understanding variation and theory of knowledge. If the slogan is not supported by they system of management in place it will do harm.
In response to: Are Slogans Always Bad or Can They Inspire?
Related: Deming on eliminating slogans and motivational posters – Eliminate Slogans – Toyota Targets 50% Reduction in Maintenance Waste – posts on psychology – How to Improve – Stop Demotivating Employees
[embedded webcast links removed because they have been removed from YouTube. To see video with W. Edwards Deming see the Deming Institute YouTube channel.]
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.
Part two of the documentary explores the Deming Prize, understanding data and the PDSA cycle: [removed]
Part 3 explores the efforts at Florida Power and Light, the first USA Deming Prize winner: [removed]