This chapter is from the book
This chapter is from the book
This chapter is from the book
Frame 2: System Capability
Once you understand your customers and what it means to deliver value to those customers, the next step is to gain a clear understanding of your capability to deliver that value. What capabilities do you need to be successful in the marketplace, both now and in the future? It is important to have the capability to deliver what customers want today, but it is also necessary to look into the future and make sure that today's efforts are moving your organization toward tomorrow's success. Realistic long-term planning and risk assessment, along with understanding the current and future competitive environment, are essential ingredients of sustainable success. If people and teams are going to use their creative energy to decide what is important to do today, they need to understand both the immediate customer needs and the challenges of the future.
What Is Your System Predictably Achieving?
The starting point for improving your capability to satisfy customers is to understand how your current work methods actually work, what they are currently capable of delivering. You need to understand how your capability compares with the needs of your customers and the capability of your competitors, both now and in the future.
Understanding Capability
If you want to know how well your organization is performing, don't just look at a few data points; look at a sequence of data over time. All systems exhibit variation, and looking at an occasional data point does not tell you much about how much variation there is in your system. In fact, random data points give a distorted view of your current capability.
A good way to visualize capability is to create a time series chart. Let's say that you want to look at your capability to quickly respond to a particular type of demand, for example, small urgent requests from customers. When a request arrives, give it a date stamp; when the request is closed out, subtract the arrival date from the current date to get the end-to-end response time, then plot these times. A time series plot of response times for small urgent requests might look something like Figure 1-1.
)
Figure 1-1 Time series chart of end-to-end response time for small urgent requests
Your immediate reaction to a chart like this might be to look for the cause of the long delays for several of the requests. You don't have to look very far—your work methods are the cause. This is a chart showing what your work system is currently capable of delivering. You are not going to change things by looking for scapegoats or setting more aggressive targets. Your current way of working produces the results in the chart; if you don't like the results, you have to change the way the work is done.
W. Edwards Deming worked to spread an understanding of variation to industry leaders, but we think that his message is often distorted. We frequently see efforts aimed at removing variation from every process, without recognizing that such efforts usually make things worse. When you try to remove normal (common-cause) variation from a process, the process actually gets worse, not better. Deming pointed out that almost all variation (perhaps 95%) is common-cause variation—it is inherent in the system—and the only way to remove it is to change the way work is done. He concluded that most variation is a management problem. So if you are looking for scapegoats, start by looking in the mirror.
Positive or Negative Reinforcement?
A well-known approach to training is to give positive reinforcement when someone does something especially well, because this is supposed to lead to more of the same behavior.
We heard of a pilot training center that decided to test this theory. Careful records were kept of the results of positive and negative reinforcement of pilots in training. Much to the surprise of the researchers, they found that whenever a trainee pilot was given positive reinforcement, performance got worse, and whenever negative reinforcement was given, performance always improved! The training center concluded that giving negative feedback for poor performance was an effective training technique, and that positive feedback for good performance should be avoided.
What's wrong with this research? Consider a time series of the performance of a pilot in Figure 1-2.
)
Figure 1-2 Performance of a pilot in training
This time series shows expected variation in performance—variation due to random causes largely unrelated to pilot skill. Assume that the pilot is praised at the high points (circled). Of course, performance will appear to be lower the next time! If the pilot is reprimanded at the low points (boxed), performance would appear to improve.
The evidence shows very little about positive or negative reinforcement, but it clearly indicates that those gathering the data did not understand variation.
Tom Poppendieck
What Does Your System Need to Achieve?
The first step in changing the way work is done is to develop an understanding of what capabilities you need for both short- and long-term success. Do you have competitors who are better at delivering value to your customers than you are, or is there a threat that such competitors might emerge in the future? Could you attain a meaningful competitive advantage from significant improvements? Will your performance deteriorate over time if you proceed down your current path? Will your architecture support sustainable growth? Are you building up technical debt that will slow you down in the future?
Once you understand where you need to be in order to be successful, both now and in the future, you can create a long-term challenge that will make it clear to everyone what the organization needs to happen in order to be successful both now and over the long run. This will enable people and teams to balance short-term or narrowly focused decisions against long-term and system-wide imperatives.
Don't Set Targets
You should not set targets. Your current system is what it is; targets are not going to change its capability. You measure system capability; you do not prescribe it. As Deming once said, "If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. A goal beyond the capability of the system will not be reached. If you have not a stable system, then there is no point in setting a goal. There is no way to know what the system will produce: it has no capability." 15
Think of it this way. Let's say you set a target that is beyond the capability of your system, a goal that your current work processes cannot achieve. Since the target is a strong motivator (no argument there), people have three choices: (1) redesign the work, (2) distort the system (for instance, by ignoring defects), or (3) cheat (game the system) to hit the target.16 If people do not have the know-how to redesign the system, they are left with two options: distort or game the system.
Suppose the people do have the know-how to redesign the work. In our experience, redesigned work is likely to produce far better results than an arbitrary target—but where is the motivation to surpass the target? Similarly, if you set a target below the current system capability, you are likely to get less than the system is capable of delivering, because there is little motivation to surpass the target.
A target is a predetermined level of performance that people are expected to achieve; if there is significant variance from the target (or plan), explanations are usually required. Targets are generally associated with incentives; people are rewarded or punished based on their variance from the target.
Incentive systems based on performance targets make the assumption that if people would only try harder, they could achieve better results—hence targets communicate an implicit assumption that people are not currently contributing their best efforts. Wouldn't it be better to challenge people and teams to excel at delivering exceptional customer outcomes and communicate trust that they will do their best?
Use Relative Goals with Caution
Not all goals are based on predetermined targets; they can be based on relative measures. For example, goals can be based on performance relative to competitors, performance relative to peers, or performance compared to past performance. Relative performance goals do not attempt to set a fixed level of performance for the future; they look backward to see how actual performance compares against the performance of others. In most sports, winning or losing depends upon relative performance: A swimmer only has to swim faster than seven other swimmers in order to win; a baseball team has to score more runs than the other team.
Relative goals can be very motivating, and they have some advantages over targets or plans. Relative goals are not based on a prediction of the future, nor do they encourage people to distort or game the system; and finally, they don't act as a floor on performance. On the other hand, relative goals leave competitors with little motivation to help each other out—quite the contrary: Relative goals can motivate competitors to sabotage each other's performance. Thus ranking performance relative to peers can be damaging inside a company, especially if reward systems are based on this ranking. If, however, the competition is friendly and performance rewards are shared equally among all competitors, the destructive side effects of tracking performance against peers can be mitigated.
Challenge: Pull from the Future
Perhaps the best way to engage people in making the organization better is to create a long-term vision of where you want to be—where you need to be to survive—and challenge everyone to help move the organization from where it is now to where it needs to be. Challenge people and teams to improve the way work is done by redesigning their work methods. Challenge them to develop systems that provide clear business value. Challenge them to devise an architecture that will meet future growth projections. Challenge them to create new products that will be successful in the marketplace.
Let's say that you would like to decrease the "hardening" time at the end of a release cycle. A target might be "Cut the verification time in half!" Given enough emphasis on this target, the verification time will probably be cut in half, but often at the expense of more defects escaping to production.
A far better approach is to challenge teams to redesign the way development works so that defects are discovered and fixed as soon as possible after they are injected into the code. With this challenge, a team would quit focusing on how many features are delivered and start thinking about how to make sure that every delivered feature is defect-free. The team would introduce automated tests and continuous integration and adopt the practice of stopping to fix every defect as soon as it is detected. When done well, this approach has a track record of dramatically decreasing back-end testing time—by far more than half—at the same time as it increases quality and productivity. But these results are achieved only when a team works to improve the capability of its work methods to produce defect-free code. They are rarely achieved by a decree that system verification time must be cut in half.
Challenges are different from fixed performance targets:
- Challenges are not necessarily SMART;18 they are open-ended, customer-centric, and designed to elicit passion and pride.
- Challenges communicate confidence that people and teams are intelligent, innovative, capable of thinking for themselves, and trusted to do their best to further the purpose of the organization.
- Challenges flow from a long-term vision of what is necessary to be successful over time and contain enough information that people and teams can act independently and with confidence that their work will contribute to achieving the vision.
- Thus challenges are a pull from the future rather than a forecast of the future.