7
Building Motivated Teams

My PSP experiences led to the development of the Team Software Process (TSP). The purpose of the TSP was to build an environment where everybody planned and tracked their work and measured and managed the quality of their products. The TSP was also needed to provide a management environment where the engineers are encouraged and rewarded for doing quality work. This would motivate them to use the PSP methods on the job. The experiences of the BrokerNet team of EBS show how effective this approach can be.

The EBS Brokernet Team

When we launched the BrokerNet team at EBS, Peter Bartko, the CEO, agreed to talk at the opening meeting. EBS operates an on-line worldwide currency-trading network for international banks. This system runs on EBS-owned computers and is controlled by EBS-developed software. On a typical day, it handles about $80 to $100 billion of currency trades. Since this system is updated frequently, EBS is continually modifying and enhancing the software. Before, the EBS engineers typically had spent many months testing each new product version.

In the fall of 1998, EBS management decided that they had to upgrade the entire system to a new technology called BrokerNet. Peter Bartko, the CEO, decided to use the TSP to improve the quality of their software. Otherwise, he felt that the amount of testing required for a new system would be impractical. When he talked at the opening launch meeting, he described the company’s business strategy and where this product fit in. He then discussed business opportunities and the date when the BrokerNet product was needed. He explained that the company was introducing the Team Software Process (TSP) because quality was critical and that the TSP process would help them to meet the company’s quality goals. Although the delivery date was important, he said that the team’s first priority was to follow the TSP process; speed was important, but if the team truly followed the TSP process and did high-quality work, they would end up with the fastest schedule.

At the end of the week, the team presented a plan with a much later date than Peter had wanted. The engineers explained that this was a large product and they did not see how to develop it any faster. Even though there were 47 engineers on the team, they needed 5 more to meet this date. While marketing was upset, Peter accepted the team’s plan. He later told me that he would have liked the product earlier, but if this was the best the engineers could do, that was all he could ask. He didn’t want this team to fail.

Most managers would say that Peter Bartko was crazy, that the only way to get software engineers to meet any kind of date is to push them. Peter was not being soft, however; he knew that he would get the best results if the team knew what he wanted and why. He trusted them to do their best. As our TSP results show, this is the most effective way to manage engineering teams. The way we learned this is the story of how we developed the TSP.

Developing the TSP

By the summer of 1996, we had found that PSP-trained engineers could produce higher-quality products more predictably than ever before. However, we were dismayed to find that few engineers continued to use the PSP on the job after they were trained. Part of the problem was that no one else on their teams was trained and using the PSP. Another reason was that the organization’s culture actually prevented them from doing quality work. All management ever asked about was the schedule, and quality was viewed as the testers’ job. Since nobody else seemed to care about quality work and since their managers objected to their taking time to plan and review their work, few engineers were able to use the PSP after completing the training.

The obvious need was to build the proper kind of team-working environment. While I did not know exactly how to build a team process, I knew that I would never learn without building one. Therefore, my first step was to develop an initial version. Then I lined up two teams to use it. Unfortunately, these projects had to start in September 1996, when I had to be in Australia and New Zealand. Since I could not help the teams get started, I sent them a detailed process description.

After returning from the trip, I visited both teams. I found that the TSP had worked pretty much as planned. Both teams had made detailed plans and they were still tracking progress against these plans. However, I also found that these teams did not have the energy and motivation I had hoped for. The problem appeared to be in how we had started the projects.

How to Build Motivated Teams

Numerous studies have been made of team building and team motivation. The common thread is a teambuilding experience where the team works as a unit to accomplish some important and demanding task. The task we decided to use to build motivated software teams was the TSP team launch. The objective of the launch was both to excite the engineers about the job and to establish a mutual team and management commitment to the plan the team developed. To ensure that the launch worked properly, we defined a four-day launch process, used only PSP-trained team members, and had a trained and experienced TSP coach lead the team through that process.

The TSP launch starts with an opening meeting in which the entire team meets with marketing and senior management. These managers explain why the project is important and why the customers need the product. The team then makes a detailed project plan. At the end of the launch, the engineers present their plan to management, explaining how they plan to do the job and answering management’s questions.

The best way to explain how this launch works is with the example of the first Teradyne team.

The Teradyne Team

When I launched the first TSP team at the Teradyne laboratory outside of Chicago, the general manager and the marketing manager attended the opening meeting. The general manager made some brief opening comments about the importance of the product and why it was needed in nine months. Then the marketing manager explained why the customers needed this product, and what the competitors offered. He concluded by stressing the importance of the nine-month schedule.

After the opening meeting, I met with the engineers and their team leader in a small conference room. This was an integrated team of hardware and software engineers. They were all in revolt. “Nine months! He’s crazy! The last job took two years and it was a disaster. How can we meet this ridiculous date?”

After they had calmed down, I asked the engineers what management had said. They all answered, “We have to finish in nine months.”

While I agreed that those were management’s words, what did they mean? Again, the engineers said they had to finish in nine months. So I asked them, “Suppose you finished in seven months, would management take it then?” They all agreed that they would.

“So,” I said, “management really meant that they wanted the job done as fast as possible, but that the fastest they thought you could do it was nine months, right?” They agreed. So I next asked them, “Do you always accept the first bid? How long do you think the job will take?” Next I asked them, “Whose date is the nine months?” They agreed it was management’s. Then I asked, “Suppose you go to the general manager and say, ‘Boss that’s a terribly tight date, I don’t see how we can make it,’ but he insists and keeps on insisting on nine months. At the end of the meeting you say, ‘OK, boss, if you insist, we’ll give it our best shot.’ Whose date is it now? It’s yours, and don’t you forget it!”

“So what do we do?” they asked. “You can’t just guess,” I replied. “Then management will prefer their guess to yours. Your best bet is to do your utmost to make a plan that meets management’s objectives. When you have a plan you believe in, you will know if you can meet management’s date or not. Then you can go back to management and convince them that it’s a sound plan. You will have a date you believe in, and you will have a shot at making it.”

The team got right to work. The engineers did a marvelous job. They followed the TSP process, laid out a system conceptual design, produced a development strategy, defined the process that they would use, and estimated the sizes of the system’s parts. Next they defined the tasks for the entire job, estimated how long each task would take, and produced an overall plan and schedule. Their quality plan gave target defect levels for each phase and at delivery, and their detailed plans showed what every engineer would do every week for the next three months. Finally, they analyzed the project risks and prepared a presentation for the final launch meeting with management.

When the engineers completed the plan, they were dismayed to find that the schedule was 18 months, not the 9 months that management had required. However, they knew it was an aggressive plan and the best they knew how to do. Going into the final launch meeting with management, the engineers were understandably nervous about management’s reaction.

In the management meeting, the team leader explained what the team had done. When he got to the schedule, the general manager started asking questions. The team leader explained the size of the system and the amount of work they had to do. He compared this job with other projects and showed that the schedule was actually shorter than other similar jobs. The general manager was about to agree when the marketing manager exploded. “You’ll destroy the business,” he yelled. “The competitor has a better product on the market right now! We can’t possibly hold the line for 18 months.”

So I asked him, “You mean that the competitor is delivering a better product today?” He said yes. “Well, when do you think this competitor started developing this better product?” I continued. “It wasn’t last week, was it?” Since he didn’t know, I told him that the competitor probably started developing their better product a year or two ago. Then I asked, “Why didn’t you start then? In the development business, if you can’t anticipate the market, the engineers can’t recover for you.” The marketing manager subsided and the general manager accepted the team’s date.

The following week, the marketing manager brought reinforcements to a meeting with the engineers. They spent a full day probing the schedule and trying to find any fat. The team answered every question by showing the work they had to do. The engineers went through each of their tasks and reviewed the estimated sizes of all of the system components. They described how long it would take to specify and design each product element. In the end, the marketing manager said, “You really do have a lot of work to do, don’t you?” He then accepted the 18-month schedule.

The Final Result

These engineers did a remarkable job. They produced such a comprehensive and impressive design that, when marketing described it, the leading customers all waited for the new product. In the end, Teradyne didn’t lose a single account. This team actually delivered the product six weeks ahead of the 18-month schedule, and the costs were below the plan. The product had higher quality than anything the company had previously delivered. It had only two defects in customer acceptance testing and none thereafter. Table 7.1 shows the team’s original plan and what the engineers actually did.

I met with this team several times during the project and what most impressed me was the engineers’ energy and enthusiasm. They were working hard, but they were having the time of their lives. They were winners, and they obviously enjoyed it. This was a highly motivated team.

Table 7.1 The Teradyne Team Results

How do you Motivate Teams?

Motivated teams clearly do the best work—so how do you motivate them? In a business context, there are only three ways to motivate people: fear, greed, and commitment. While fear is an effective way to get action, it often engenders unthinking behavior. Fear-induced work tends to be unimaginative, slap-dash, and not very creative. The appeal to greed—paying big bonuses or commissions—works for some activities, but it has one big disadvantage: the need for precise measures. For example, sales quotas motivate increased sales volumes. However, depending on how quota performance is calculated, this may not produce higher profits. This is the “faster, better, cheaper” problem in another context. When performance is unmeasured or improperly measured, the results are often disappointing and can even be disastrous.

Unless your measures cover all important aspects, you will likely motivate counterproductive action [1]. For example, before the collapse of communism, the Soviet Union used five-year plans and production quotas to micromanage the economy. The Trans-Siberian Railway had goals for the number of cars crossing the continent. When the commissars found that the railway was sending empty cars, they required that the cars be loaded—the railroad filled the cars with water. Again, a simple measure motivated counterproductive behavior. For any but the simplest work, fear and greed are not effective motivators. That leaves you with commitment.

Building Committed Teams

To build a committed team, Teradyne first trained all the engineers in the PSP. This showed them how to plan their work and manage the quality of the product they produced. This action told the engineers that management was serious. Next, the general manager and marketing manager met personally with the team. This told the team that the job was important. Management also showed that they respected the engineers and wanted them to understand both the business and technical needs. In the process, they convinced the engineers that this was an exciting and important job that warranted their personal commitment.

Management also gave the team an aggressive date—so aggressive that the engineers didn’t see how to meet it. Although overly aggressive goals can be demotivating, that need not be the case. Goals are demotivating when they appear unachievable as well as when they are too easy. To do their best, engineers need a challenge and they need a plan to meet that challenge. That is the key: an aggressive challenge is fine as long as the engineers can make a plan to meet it. But if the engineers feel that a schedule is impossible, they will either get discouraged or panic. When they panic, they throw all their good practices aside and start banging out code. Then they invariably take longer than they would have with a rational plan.

At Teradyne, instead of complaining about an impossible date or slapping out a poor-quality product, the engineers planned to do the job properly. They put in four grueling days and evenings to produce the best plan that they could. When the team leader presented the plan to management, all of the engineers were in the room and helped defend the plan. The managers asked many questions, but the engineers explained the plan and convinced them it was sound. This wasn’t the team leader’s plan; they all owned it, believed in it, and would do their utmost to meet it.

If you want committed teams, give them aggressive goals, but also have them make plans for meeting these goals. Ensure that every member is involved and that everyone knows how to make plans. Whether or not the plan meets your goals, have the engineers describe it and why they believe it is right. Show that you need this product and that the date is important, but also demonstrate your need for a meaningful commitment. Look for any fat in the plan, but also look for holes or omissions. You don’t just want a promise; you want a realistic commitment that the team will meet.

If, as is often the case, the plan does not meet your needs, negotiate with the team. Add resources if needed, reduce product functions, or deliver in increments. Keep examining alternatives until you get a plan that the team will commit to and that you can accept. Then you will have a committed team.

The EBS Results

To protect themselves from teams that are habitually late, managers often set more aggressive dates than they really need. When you can count on your teams to meet their commitments, you get better results by being honest. At the EBS launch described at the beginning of this chapter, Peter Bartko, the CEO, told the engineers what he really needed. Even though their original date was not what he wanted, he was willing to wait to see what they could do.

After a couple of months, the EBS team completed the requirements and the preliminary design. The lead designer then saw how to deliver a simpler initial version of the product on Peter’s originally requested date. The team agreed with the idea, so he talked with the marketing and technology people, who also agreed. The team then made a new plan to deliver this first product version the following August.

For the next ten months, the team followed this new plan and delivered the initial product version within three weeks of the committed date. While testing took about a month longer than expected, the product had higher quality than anything else they had ever developed. The BrokerNet system has now been installed and used in over a dozen international banks, with no reported problems.

A Trusting Environment

The EBS BrokerNet team voluntarily accelerated a schedule that management had already accepted. This is directly counter to the “give them an inch and they’ll take a mile” view of traditional management. Many managers feel that if you don’t demand an aggressive date, you will get a relaxed schedule that the engineers will still miss. I have never had a team give me a relaxed plan. In fact, teams generally make more aggressive plans than management would dare to make for them.

Engineers are smart people. They can quickly sense a lack of trust. When you don’t trust them, they are not likely to trust you. Then they will never propose a more aggressive schedule than you have requested. Think of it this way: who truly understands the job and is in the best position to make an aggressive plan? Make sure that the engineers know what you need and, once they have done enough work to understand the job, they will often get better ideas. If you do trust them, they will keep thinking and, once they better understand the job, they are likely to devise creative ways to accelerate their work. They might even come up with a solution that no one could have imagined at the beginning. Peter Bartko demonstrated a great way to do this; he knew that the important question was when the product was delivered, not when it was promised.

The Consequences of Impossible Dates

Since the Teradyne team had originally been given an “impossible” date and still did a great job, why not set an impossible date? With an aggressive date, the argument goes, the team just might meet it. I debated this question with the Teradyne team. I felt that, with PSP training and the TSP process, they could have resisted unreasonable management pressure even if I hadn’t been there. They did not think so. Management had insisted on a 9-month schedule and they did not believe they would have had the nerve to present an 18-month plan. Experience shows however, that when properly coached, TSP teams create realistic plans and defend their plans to management. To date, of dozens of TSP teams, not one has caved in and committed to a date that the engineers did not believe in. Then, with few exceptions, these teams met their commitments.

If you push a team to meet an unrealistic schedule, you will likely get a disaster, regardless of the process your teams follow. Without strong support and a great deal of experience, teams rarely have the self-confidence to challenge their management. When the engineers start with a flaky plan, they don’t have a prayer of meeting it. From a motivational perspective, this is the worst possible result: the engineers are working to your date rather than to a commitment of their own.

With an unrealistic date, teams take longer to produce poor-quality products that do not meet the user’s needs. Then they spend more time fixing the product than it would have taken to do the job properly in the first place. Not only won’t you have a motivated and committed team, you will be right back where you started: wondering how to get faster, better, and cheaper work from your software teams.

Maintaining Team Commitment

Once managers have trained their engineers and followed the TSP process to launch their teams, they have just begun. Getting engineers excited about building advanced and sophisticated products is easy. However, the team generally will have many months of hard work and face dozens of unexpected challenges. Management’s job is to keep the teams motivated and to ensure that they consistently do disciplined work.

In one organization, management supported an early TSP team through the launch process. Then the team began the job. Within a couple of weeks, however, management pulled one engineer off the job. Since he was needed permanently on the new job, they replaced him with another engineer who had not been PSP trained. This new engineer did not understand the plan or the process that the other engineers were following. Soon, management made another change and the team had another untrained engineer. Now the engineers started to argue about how to do the work. Soon, team discipline collapsed and the engineers reverted to their prior software methods. The project was a disaster.

Once you have trained and launched a TSP team, you must protect and nurture it. Add only PSP-trained engineers, and do not change membership unless absolutely necessary. Review team performance monthly or at least quarterly and have management follow project progress every week. Show continued interest in the work and regularly ask about quality. This book’s appendices provide further guidance on how to launch and support TSP teams.

Summary and Conclusions

The following six principal points are made in this chapter:

1. To build a committed team, give its members aggressive goals and have them make a plan for meeting these goals.

2. Review the team’s plan and have the engineers defend it.

3. If the team’s plan does not meet your needs, negotiate with the team.

4. Once you have a plan that you can accept and that the team has agreed to meet, you will have a committed team.

5. With motivated and committed teams, projects will consistently deliver quality products on their committed schedules and for their planned costs.

6. The Team Software Process (TSP) shows you and your organization how to build and maintain committed teams.

Reference

1. Robert D. Austin. Measuring and Managing Performance in Organizations. New York: Dorset House, 1996.