Problem Solving

We often have our hotel bill paid by companies we visit. The interesting part comes when we arrive at the hotel desk and they ask for a credit card. "This will be billed to company XZY, won't it?" Mary will say. Half the time the answer is, "Oh yes, your credit card is just for incidentals." And the other half of the time the answer is, "No, I don't see any information about XYZ paying for your room." Then comes the familiar hassle of getting the hotel to direct bill company XYZ before we check out. The most frustrating part about this hassle comes when the person at the hotel desk says, "Oh, yes, we have this problem all the time." And Mary inevitably responds, "If you have this problem all the timewhy don't you do something about it?"

The mark of an excellent organization is not that they are without problems; it is that they are without systemic problems. In an excellent organization, everyone, at all levels, has a regular, reliable channel to address problems that they encounter in their everyday work. More than once we have been wrongly billed by a top-rated hotel, which signals to us that the hotel, despite its high rating, lacks a systematic improvement process.

It does no good to have a software development process if it is not accompanied by a way for those who struggle with its idiosyncrasies to fix them. Every team should have a regular time to systematically find and fix the things that make their lives difficult. Rally, for example, takes time out at the end of each iteration to discuss problems and commit to specific changes, and then it follows up on these commitments one by one.

The first rule of process improvement is not to try to do everything at once. When process improvement efforts are sporadic, people have a tendency to want to solve every problem at once. This is reminiscent of big projects and long release cycles, which have a similar tendency to create large batches of work. The idea is to establish a cadence of continuous improvement.

Frequent, regular meetings allow a team to find its biggest annoyance, get rid of it, and then move on to the next one. Usually the biggest annoyance can be described in sweeping terms, for example, "Our life would be so much easier if we had enough time to do all the stuff that everyone wants us to do." But such a broad statement doesn't provide much traction for actionable problem resolution.

A Disciplined Approach

A disciplined approach to problem solving moves a team from wishful thinking to new knowledge, specific countermeasures, and permanent results. The scientific method discussed earlier in this chapter provides a good outline of how to proceed:

1. Define the problem.

2. Analyze the situation.

3. Create a hypothesis.

4. Perform experiments.

5. Verify results.

6. Follow-up/standardize.

1. Define the Problem

It's nice for a team to say "we want to be more responsive to customers," but how, exactly, does a team go about doing this? Let's follow a team through the problem-solving process. This team's biggest problem was a long list of complaints from customers who said their requests were being ignored, so the team decided to take a closer look at the problem.

2. Analyze the Situation

First the team looked at the features that had been deployed in the last four releases and plotted the feature cycle time on a Pareto chart. The data (Figure 7.3) looked fairly goodmore than three-quarters of the features were deployed within six weeks of receiving the request.

Figure 7.3. Pareto chart: cycle time of deployed features

However, the team members knew that there were a lot of items in their request queue that they were ignoring, especially since new features kept on being added all the time. So they plotted a Pareto chart of the age of the features that were currently in the queue (Figure 7.4).

Figure 7.4. Pareto chart: age of active customer requests

The data showed that more than 60 percent of the requests in the queue were more than eight weeks old. Yet in the previous graph they saw that only nine requests they actually delivered were more than eight weeks old. They seemed to be working only on the most recent requests, not the older ones.

The data also showed that the team had closed a total of 76 requests in the last four releases, or an average of 19 per release. The releases were two weeks apart, so their current rate was about ten requests a week. Since there were 568 requests in the queue, at the rate they were going it would take them more than a year (5560 weeks) to work off the current queue, even without new requests.

The team next plotted the request input rate by priority category (Figure 7.5).

Figure 7.5. Request arrival rate

3. Create a Hypothesis

A critical part of the scientific method, and one which is often overlooked by teams racing to solve problems, is to form a hypothesis that can be tested. The team members noted that the average input rate of the three highest priority request categories (emergency, urgent, and important) was ten per week, which was approximately the same as their current output rate. So their hypothesis was that if they could reduce the queue to 4050 requests, stop accepting "normal" and "minor" requests, and increase their request completion rate slightly, they could complete new requests in four weeks 90 percent of the time.

4. Perform Experiments

The team members decided to see if they could reduce the backlog by sending an e-mail to everyone who had requests older than eight weeks. The e-mail said they were trying to reevaluate the request backlog and would like confirmation that the person would like their request to stay in the queue. If they didn't get confirmation in a week, they would assume that the request could be canceled. Table 7.1 shows the response to the e-mail:

Table 7.1. Response to Request for Confirmation of Need for Request

Age Category	Total		Withdraw		Confirm		No Response
816 weeks	112	1	1%	26	23%	85	76%
>16 weeks	248	20	8%	3	1%	225	91%

The team members noted that 99 percent of requests more than 16 weeks old were no longer desired, 77 percent of requests more than 8 weeks old were no longer valid. They looked at the 29 requests that were confirmed and discovered that they all had "important" priority. Next they looked at the remaining items in the queue and sent a similar e-mail, but this time they sent it to only those whose requests were "normal" or "minor." This further reduced the queue to 100 requests; however, customers were still submitting requests with "normal" or "minor" priorities, and the team felt that if they removed this designation, customers would simply assign a higher priority. So they experimented with ways to deal with the lower priority requests. The experiment that worked the best was to have the customer support member of the team call initiators of lower priority requests and work with them to see if there was another way to solve the problem. Sixty-five percent of the time there was a relatively quick alternative solution. Ten percent of the time the requestor was convinced that the request was not justified based on the effort involved. Thus three quarters of the lower priority requests were withdrawn through this personal contact.

5. Verify Results

The team was able to increase its average complete rate to 25 requests per release (every two weeks). Over the next several weeks the queue was gradually reduced to about 50 requests through a combination of canceling older requests and completing higher priority requests slightly faster than they came in. The team measured its ability to provide reliable turnaround. The data showed that the queue length was the determining factor in request response time, so team members were confident that with the queue at 50 requests, they could promise a four-week turnaround on requests 90 percent of the time.

6. Follow Up/Standardize

The team members announced to their customers that they would complete most requests within four weeks, but they found that this encouraged more customers to submit requests, so they had a second team member assist with the customer service calls aimed at limiting the rate of request arrival and finding alternative solutions for low-priority requests. In addition, they were able to increase their average completion rate to 28 requests per release, due in part to the shortened turnaround time. Within a month the queue stabilized at four weeks of work. The team prepared a report on their experiences and presented it to other teams at an internal company seminar.

Kaizen Events

We have just followed a work team through a typical problem-solving process, something that should be embedded in the everyday activity of existing work teams. Sometimes it is a good idea for teams to take a step back from everyday activities and focus solely on improving a key aspect of their process. This is particularly useful if the change will affect multiple areas of the company, and thus members from several different functions or different teams need to get involved.

Consider an organization that has determined that its key problem is deployment, so it decides that the most important thing it needs to do right now is automate deployment of software to customers. This will take a lot more than writing scripts. It will involve changing jobs and processes, interactions with other departments, customer expectations of what they will receive on deployment, and so on. This is a good opportunity to hold a Kaizen event.

The word Kaizen means "change for the better" in Japanese. Kaizen events are a well-known lean tool that brings together representatives from different functional areas to work intensely for a few days or a week to solve a well-defined, critical problem. During the event, all of the processes necessary to solve the problem are actually changed by the Kaizen team. After the event, the Kaizen team disbands and members go back to their ordinary jobs, with the improved process in place.

Large Group Improvement Events

Sometimes a change is too momentous for a small team to be formed and chartered to implement it in a few days. For example, a value stream map may have shown that the biggest opportunity lies in moving testing much further forward in the process, which might mean a complete rethinking of many jobs and some organizational structures. This is a much bigger problem, so big in fact that it will probably languish unless it is addressed head on. For such a problem, a large group event may be the answer.

Large group improvement events are often modeled on the GE Workout,^[17] arguably a key force behind GE's remarkable success in the 1990s. Implemented by Jack Welch long beforeand, at first, instead ofSix Sigma, the GE Workout was designed to cut through bureaucracy and solve organizational problems that no one seemed to have the time to address in the newly downsized company. Similar techniques have been widely used in other organizations to enable ordinary employees to initiate and carry out both small and large cross-functional changes.

^[17] See The GE Workout, by Dave Ulrich, Steve Kerr, and Ron Ashkenas, McGraw-Hill, 2002.

In a large group improvement event, a large, cross-functional and multilevel group of people is assembled and challenged to come up with solutions to a specific and critical organizational problem. These solutions should be based on lean principles and should be practical enough to be implemented in the near futurein, perhaps, 90 days. This kind of event is usually a facilitated meeting that lasts about three days. After a clear charter by a sponsoring executive, small groups brainstorm ideas for solving the problems, come up with recommendations, meet with each other to consolidate ideas, and gather supporting information for the recommendations. By the end of the event, those attending have put together a set of recommendations with supporting material. Each recommendation is championed by someone who will inherit the responsibility to implement the recommendation immediately, should it be approved. Toward the end of the meeting the sponsor returns, the recommendations are presented and discussed, and the sponsor (hopefully) approves or rejects each one. The champions of approved recommendations are chartered to implement them and can expect to receive both the time and support to do so.

That's the theory. And quite often it works in practice. But quite often large group improvement events fail for a variety of reasons:

1. A lack of focus on core business processes leads to:

   • Random improvements

   • Local rather than global optimization

   This can also be a problem with small group Kaizen events; improvements should address the most critical outstanding business problem.

2. Many ideas are approved, few are implemented, because:

   • No one "owns" responsibility for implementing each idea.

   • There is no charter to make changes across boundaries.

   • No time is allocated for people to make the changes.

   • There is no follow-up by the sponsor.

   Lack of follow-up is particularly a problem with large group events, and leads to broad discouragement. It is better not to hold such an event than to let it fail. Failure to follow-up shows a lack of respect for the people who were involved.

Kaizen events and large group events are good places for people to learn problem-solving skills, attack cross-functional problems, and make dramatic changes in a short time. But generally, improvement should fall to the natural work teams, which should constantly and in a disciplined manner identify and remove the largest current constraint that keeps their process from making the maximum possible contribution to the improvement of overall business results.