Examine the common sources of errors in product development activities. By being aware of the things we can change in our environments, we can reach our goal of preventing errors. Then, a number of techniques can be employed in order to help teams work towards a zero-defect goal.
In part 1 of "The Zero-Defect Vision," I explore how to develop strategies to eliminate errors and prevent defects in your product or service. Here, I will examine the common sources of errors in product development activities
People
In order to be able to recognize, and prevent, human error, it is important to understand that developing technology is a people business. Completely eliminating human error is not possible, so we should focus on minimizing the conditions that increase the possibility of error. Some of the factors to pay close attention to are:
- Lack of knowledge, skills, or ability
- Mental errors
- Sensory overload
- Repetitive strain or exhaustion
- Distractions
- Forgetfulness
- Loss of emotional control
This is where we rely on other parts of the organization to help employees ensure that a good social environment exists, and that the right people—with the right skills—are put in the right positions, giving them the best chance for success. Managing by spreadsheets has been the worst violation I have seen in our industry, because it takes the human element out of the picture. Managers move people around, often overloading them on project assignments as long as their full time equivalent total is within their budget. This practice is unrealistic and causes much stress in the worker ranks. In fact, I deplore the use of the term “resources” when talking about people. In any conversation, when I hear someone use the term “resources” when talking about people, I stop them and say, “Do you mean people?” That catches on pretty quickly and has a way of changing the way they think.
Methods
It’s important to have the right people in place, and you must set them up in the right conditions for developing a product. You need to have a good set of methods to use in the development process, including process steps, transportation (information, people, technology), and decision making. Improper methods are often the cause of errors. Methods include:
A good process will quickly expose the problems that exist in creating value for a customer. Having courage and determination to face these problems head-on while making changes to improve is key to producing products faster at higher quality.
In lean enterprises, transportation—the movement of people and materials—is minimized to ensure that everything is where it is needed, when it is needed. In software and systems development organizations, you must primarily focus on where people are located in order for them to work most effectively together. The most effective teams are usually collocated such that team members can at least see each other without moving around. They have ready access to information and equipment they need to do their job.
Decision making needs to move beyond sentiments such as“ I think” or “I feel” to a fact-based reality. Too many decisions are made from personal agendas or posturing in an effort to avoid getting blamed. Sometimes there is the appearance of a data-based decision, only to find out later that the data was fabricated. Rarely do I see an organization make decisions based on real economic factors or the cost of not doing something. It’s time we raised the visibility of the decision-making process so that everyone can see it. This will help eliminate organizational confusion.
Environmental
Getting the right people, having the right methods, and giving people the right environment to perform their jobs effectively is the most important role of management in a company. But basic environmental factors like lighting, temperature, and noise can have a devastating impact on people; they can affect attention, energy, and reasoning ability. I’ve seen people work in environmental conditions that seem almost criminal: People subjected to four-by-six fabric cages—isolated from interactions with others—with cluttered workspaces, poor lighting, annoying clicking clocks, noisy air handling systems, and buzzing fluorescent lighting. Workers battle these distractions by donning noise-cancelling headsets, which further isolate them from co-creators.
Where is management and “human resources”? What is their responsibility in all of this? Who is responsible for creating the work conditions that maximize the ability of the employees to create high-quality products and services. I can’t tell you how many times I’ve suggested workplace improvements only to be told by senior management that the facilities group “won’t let us do that” or “they don’t think it looks professional.” That makes my blood boil!
Others
Here are some other important sources of errors that are common in our industry:
- Materials: Not having the proper supporting materials to encourage collaboration and learning. Examples: whiteboards, markers, Post-its, collaboration tools, and instant video conferencing.
- Machines: Old computers and servers, slow build machines, low bandwith connections, and unreliable development environments
- Pressure to get a product shipped regardless of known quality issues
- Internal competition for scarce “resources”
- Pressure for promotions and increased wages
With a bad economy comes frugality at the cost of the ability to create value. We end up cutting the critical supply of things we need to create value. This is common in a cost-focused versus value-focused organization. The cost cutting starts with reductions in people—which we have all kinds of fancy names for— then it hits the other factors described above, until we have limited our ability to create value. We then punish the survivors and force them to push systems out the door when they are clearly not ready. I believe the US auto industry used to refer to this practice as “Move the Metal!” Unfortunately, it didn’t work out so well for them, so let’s not repeat history.
Error Proofing
The first step in error proofing is to become aware of how errors are injected into the work processes. I hope the first part of this article helped do that for you. The next step is to fix some of the problems and measure results so we can see the economic impact of the efforts.
There are three basic error-proofing methods that can be employed. These methods will quickly identify issues and problems, which must then be vigorously attacked using problem solving methods such as the 5 Whys and A3 Problem-solving methods, to be discussed later.
Inspection
Inspection means that we are continuously monitoring process and outputs both by automated and manual processes. This inspection is accomplished by performing activities such as user workshops where development teams have conversations with users about their needs and the issue they are trying to solve. A good way to increase knowledge and decrease errors earlier in the inspection is to have the developers conducting code review and walkthrough activities, ensuring that code is being written in adherence to a coding standard. This should include testing activity conducted at various levels throughout the development process, not just at the end. The testing activity applies to the highest risk areas of integration, performance, and load testing.
Error-proofing Devices
In software and systems development environments, error-proofing devices—such as automated tests at the unit, function, and system levels—can be extremely effective at establishing and maintaining high quality. Automated builds and continuous integration with signal notification via lights or email help the entire project team know that the product is healthy or when it’s time to “stop the line.”
The checklist is one of the most effective tools I have used. This checklist should show the steps, activities, or artifacts that are required by our process to complete a piece of work, along with the quality check to know that we’ve met the condition. Figure 1 shows a sample of a checklist for a very disciplined team.
 |
Figure 1: Sample definition of done |
By employing a checklist such as this one, teams are less likely to skip steps; there is a standard set of tasks that everyone is committed to, and there is a quality measure that must be met.
Immediate Feedback
Increasing the frequency and quality of feedback throughout the process is a critical component to increasing agility and quality. The least expensive and simplest time to fix an issue is immediately when it is detected.
Receiving end-user feedback from the beginning and engaging them through the process can help identify and correct misunderstandings or misinterpretations. This is common in product companies that are relearning the practice of speaking with end-users. Often there is a fear of what the end-users might say. However, this is exactly the fear we must face. It is better to find out that something is wrong as early as possible.
The same holds for the detection of errors in the development process. From design to coding to testing—the faster we detect an error, the faster and least expensive it is to correct.
Problem Root Cause and Removal
When any problem is seen through any of these methods, the next critical step is to root cause the issue and develop a solution. The following two methods are easy to use and implement: These are the core problem-solving techniques used by companies like Toyota.
5 Whys
This is a simple tool that can be used by a small group looking to identify the root cause of a problem in a process. First, determine the problem statement, then ask yourselves “why” five times. As you develop each answer, the next “why” will help the group dive deeper until it finds the possible root cause of the problem.
A3 Problem-solving Method
The A3 Problem-solving Method is practiced by Toyota’s lean system. Once a problem is identified, all information related to resolving it is captured on a single A3 paper (A3 is a paper size, similar to an 11x17 in the U.S.). On the single sheet, we capture the problem description, the desired condition, analysis of the problem—including data showing the impact of the problem and a set of countermeasures to correct the problem—and, finally, a learning points section. These are widely available on the Internet, and a sample is also available on my Linkedin site.
Final Thoughts
The lesson I hope you take from this article is that moving toward a zero-defect development process is certainly possible. It is not some dreamed up, never going to happen scenario. A methodical approach using the tools and techniques already being used in many different industries is required.
It takes discipline, courage, and a level of professionalism that must be developed in your organization. The question is not whether it can be done, but do you want to do it? Do your customers expect this of you? If you don’t do something, how long do you expect to be able to satisfy your customers? Are you willing to go to battle for your very survival in an organization?
References
- The Lean Enterprise Memory Jogger, 2002, Richard L. Macinnes, et al., GOAL/QPC, ISBN 1576810453
- Implementing Lean Software Development, 2006, Mary and Tom Poppendieck, Addison Wesley, ISBN 0321437381
- Dynamics of Software Development, 1995, Jim McCarthy, Microsoft Press, ISBN 1556158238
