Home > Articles > Programming

An Interview with Watts Humphrey, Part 28: Early TSP Trials and the Teradyne Team Launch

In this transcript of an oral history, Grady Booch interviews SEI Fellow Watts Humphrey. In Part 28, Humphrey discusses his experiences with TSP trials, why business continuity is a real problem for the software community, and the difference between a team leader and a coach.

This interview was provided courtesy of the Computer History Museum.

See the entire interview.

Like this article? We recommend

Early TSP Trials

Humphrey: As I said, we’d gotten the PSP in place. It became clear that people really weren’t able to use it. So I had to build something that ordinary folk-- not zealots like me -- could actually use on the job. So that, I decided, was a TSP -- a team software process -- and I wanted to put something together. So starting in about January ’96 -- remember I talked about our process development process? I pulled out my process development process, and I started to develop a TSP process

I got it together during the spring and summer, and I was trying to figure out where to use it, and the people at Embry-Riddle said, “Hey, let’s us do it.” So what they wanted to do was to use it for a team of four or five of their graduate students who were going to do a team project. They’d all been PSP trained, now, so they were qualified.

I put together the process and had it all defined and ready to go, but unfortunately, in September, when the project was to start, I had to be in Australia to give a keynote at a conference. So I just packaged up the process and sent it to them at Embry-Riddle. So they basically went through it.

Our processes, by the way, have things called scripts. It’s what I call an operational process. The process isn’t a big document thing that has paragraphs. It has steps in a script which you follow. I’ve got copies or versions of them in my textbooks and stuff. But it’s got a series of steps, and if you read what it says in the steps -- let me pull up a couple here -- they’re very direct. They just tell you what to do, step by step. So it’s not complicated at all. Let me pull up a process: “Schedule planning template: Enter the following.” I mean, it starts off with a purpose. “The purpose is to record the estimate and actual hours expended by a calendar period, and relate the task plan value of the calendar schedule, plan value earned, value stuff, calculated adjusted planned and earned value.” And then, “General: Expand this template or use multiple pages as needed. Complete it in conjunction with the task planning template.” Then I go, “Enter your name, date, week number, when the project started. Enter a week number, typically starting with one. For very small projects, it may be more convenient to use days instead of weeks.” Then the next one.

So basically it goes through -- this is the instructions for the template, and then the actual process script starts with entry criteria, and then planning. “Step one: Produce or obtain a requirement statement. Use the probe method to estimate total new and changed lines of code, required time and the prediction interval. Complete the size estimate template. Use the probe method to estimate the development time required.” So it goes through steps, very straightforward, and we have scripts like that for all the steps. The reason I had to do that is kind of interesting.

And think about it this way: when you tell somebody to produce a plan for a program, most programmers won’t have the vaguest idea what you’re talking about. So they’ve got to go off and sit down and figure out, “How do I make a plan?” They don’t know. They have got to kind of figure it out. Even though it’s not very complicated, they don’t know; they don’t have a process; they don’t know the steps. So they’ve got to figure out step by step what to do, and then they do it. So that’s an enormous waste of time. It’s fairly obvious. We know how to do it, so we just give them a script and say, “Here, just do this.” So that’s what we’ve done, and it works extremely well. So that’s what I sent to the folks at Embry-Riddle. How do you do a TSP project, and that’s what I had done. When I developed the process, I developed all the forms, the form instructions and the scripts for every step of what they had to do.

 It took me several hundred hours of work. I mean, it’s a lot of work, and it is non-trivial. There’s a big, big pile of stuff. When I got back from Australia, I went over to meet with the team, and they’d been working on the job about three or four weeks. It was a good team, and I had this session with them, and they were kind of laughing, because what had happened was they had kicked it off, following the process, and as they were going along, they were getting kind of frustrated because they had to move faster. They were in a hurry. So they kind of skipped the process and just started doing what they had to do anyway. They just did the things they knew how to do like design, code, and test.

And this is sort of what you’d expect programmers to do. But they got a little bit along like that and they realized they were totally lost. They had no idea where they were. And that, by the way, is where most programmers are most of the time. They don’t know where they are on the project and what to do next. So they basically said, “Okay, we better go back.” And so they did. They basically said, “Okay, we are going to follow the process.” So they did, and they did a marvelous job. They went through and they produced a system. Unfortunately, it never got put in production because one thing or another happened over there. It was a system to manage the flight line at Embry-Riddle. They were going to develop a flight and instructor scheduling system, and they put together the requirements. They went through the design. They did the whole thing. But the process basically gave them an anchor, so they knew where they were, what they should do next.

It was quite helpful, but they had a problem getting started; their plan wasn’t very good; lots of stuff. It was pretty obvious from that that they needed guidance when they were starting the project. We couldn’t just send it to them and say, “Go start.” We decided to call it a “launch” of a project. And we needed to have somebody to coach the project. It occurred to me -- I talked about my wrestling coach -- really high performance teams need coaching. So we decided we were going to have TSP coaches. We originally thought of them as coaches for the launch, so they would basically launch the project, and then the team would just go do it. So we went and did a couple of industry teams. I think we did a couple up at Harris, up in upstate New York. Of course, they got reorganized and everything. So we got started, and then everything got canned. But we had a couple of project launches and some early experience there, although they never really finished the project.

I kept running into this, by the way, in organizations. You get halfway through and they get a re-organization, and you get a new manager. The continuity in business is so appalling that you literally can’t keep stuff going. In most of the places where we worked -- a fairly high percentage -- you get something started and then the sponsor moves on and something else happens, and it’s dead. It’s gone. You’ve wasted an enormous amount of effort. And it happens all the time. It’s just astounding. And it can’t be just us. It’s got to happen on everything going on in industry. So it’s kind of frustrating. I don’t know if it’s just the U.S. or not, but the dynamics of the management system we’ve got and the ability to have any continuity for improvement in business is awful. I certainly run into that. It’s a real problem with the software community.

The Teradyne Team Launch

But in any event, I was the launch coach for a number of projects that we launched. I remember doing one at Teradyne out in Chicago, and that was a marvelous project. It went extremely well. Bob Musson was the lead process guy there. I launched a team, and had nine software people and five hardware engineers. This was a very early team, and we had no problem using hardware engineers on it. They were designing a little special purpose machine -- it was to be a line tester for telephone networks.

And they were basically trying to find line failures, and it was for the telcos in Europe, and it was the new version of the program that they had or the product that the company had previously been selling over there. This was to replace that, and it was supposed to have some new technology and AI logic for analyzing line failures and all that sort of stuff. So it was a pretty aggressive program. We started the launch with a meeting with the management team. And this turned out to be a fascinating experience because most of the teams that we've worked with have never had a meeting with management when management says what they want the team to do. We start the launch that way.

The opening meeting is with senior management. We bring in marketing people who will describe what the customer wants, the customer situation. And the reason for this is interesting and that is that a lot of the decisions you make when you're producing a system are tradeoffs. And they're tradeoffs of what you can do technically and what the business can afford and what the customer wants. And so the people who are really making those tradeoffs in very many cases are the programmers. Nobody else is involved in enough of the detail to understand it. So the programmers are making these very sophisticated business tradeoffs without the vaguest idea of what's going on in the business.

So we start the launch by bringing in management to give the team the business perspective and bringing in the marketing or customer people. And we bring in customer people if we can, who will tell them what they want and why. And then the programmers have a perspective for making decisions. And what's interesting is during the launch we open the launch with management and then we basically close the door and have a meeting with the team. And I'll come back to that one on a later team launch we had with Boeing, which was fascinating.

But in any event we close the door, and the team goes off and puts together the plan. So we went through the opening meeting with this team at Teradyne, and the management was absolutely firm it had to have the product in nine months. I poked at that a little bit. In the opening meeting the team is supposed to ask questions but they practically never do. The team leader may ask a couple, but by and large management says what they want and nobody says “boo.” So I asked a couple of sort of quick questions. I didn't want to say too much because you don't want to tell management that they're crazy and that sort of thing – at least not until you have a plan.

The team doesn't know enough to argue yet. So basically the team is in listening mode and the management was really very firm. When the meeting broke I went out to the washroom and then I joined them in the meeting room and they were in turmoil. They were irate. You have heard of the storming phase? Well they were storming. They were saying, "This is impossible. We can't possibly do it in nine months. This is crazy. The last project took two years and it was a disaster and this is more complicated than that."

And so I asked them I said, "Whose date is the nine months?" They said, "It's their date, management’s date." I said, "Okay. So what do you want to do?" And they said, "We ought to go back and tell them it's crazy." I said, "If you do what will happen?" They said, "Well they'll beat us up and we'll, you know." they kind of mumbled around and they finally concluded, "Yeah we'll end up that we will try if you insist but it's a very tight date we don't think that we can make it."

I said, "Okay if you do that now who owns the nine months?" They said, "Oh we do." And I said, "Do you want to own the nine months?" And they said, "No." I said, "Okay. So here's what you can do". I said, "You've got to make a plan and do your utmost to make a plan that will end in nine months. If you can't do that then you'll know why and you'll have various alternatives you can say with some evidence that you can do the following. But at least you'll be able to understand in some detail exactly what it'll take to do the job and you'll have a foundation for debating the subject with your management." So they bought it. So we went and made a plan.

And the launch process goes through starting there. We later added stuff to the launch, but we didn't do all of this at the Teradyne because we kept learning as we went ahead. But the process fundamentally is, we come out of the management meeting, you go into a meeting on basically goals and roles. What is it we're trying to do and how are we going to divvy up the work among team members? Now this wasn't divvying up the project work; it's divvying up the management of the job.

And so the TSP actually has role managers, and so we have a planning manager and a design manager and a quality manager and a process manger and a test manager et cetera. And these are people who have specific responsibilities for aspects of the job. The test manager, for instance, doesn’t run all the testing. But the test manager is the person, if there is any issue with testing, you give it to the test manager, and he or she will take care of it. Make sure the test tools are ready in time, that they're thinking about testing when they're doing requirements work, et cetera. Same on design: what methods are we going to use? Make sure everyone is using the same design approach and deciding what is the notation we are going to use and what are our standards? The quality manager is looking at the quality data with the process manager and deciding how to do inspections and this sort of thing. So these are the jobs these role managers do. And what's interesting is that on most projects today, no one does them. They're all left for the project leader to handle. And the project leaders are handling all these mechanics. They're trying to track the plan and this other stuff and they don’t do it very well. They don’t have time.

And so fundamentally most of the stuff that these role managers do doesn’t get done on a typical project. And so the basic rule we use on the TSP is that team leader's job is to make sure every definable task is given to somebody on the team. The team leader's job is to do all the indefinable tasks. He or she handles the motivation, the tracking, protecting the team from management.  Staffing is a constant problem -- the minute you launch a team, management wants to borrow somebody. And you've seen that before.

Booch: Oh yes.

Humphrey: And so the team leader's job is to protect the team to make sure issues get handled, to work on risks, and I mean a whole bunch of stuff and motivation and measurement, evaluation, process discipline, reporting. Team leaders are very busy people and they are the ones who actually make the difference between whether the project succeeds or not -- the team leader and the coach. What's interesting -- you think about like a ball team that is in the cellar, who do you get rid of to fix the team? You don’t get rid of the players; you replace the coach or the manager. And we don't normally have coaches in the software community. Coaches are extraordinarily important.

This is one of the issues I keep running into -- what's the difference between a team leader and a coach? Why can't the team leaders be coaches? Well, we're probably going to have to come to more manager-coaches just because coaches get laid off and team leaders don't. We're running into that now in the in the economic squeeze. Unfortunately, management doesn’t recognize the enormous value of coaches.

Booch: This reminds me of the story that you told me earlier in your wrestling career -- how under the one Olympics quality coach you guys performed very differently than with the subsequent coach.

Humphrey: Exactly. Exactly. And we don't see that in the software… We don't see it with development teams at all. And I've not so far talked about my experience with my early teams in engineering. When I was managing development teams I was really acting more like a coach. If you remember, I was asking people what they were doing and focusing on why you're doing that and this sort of thing. I wasn’t really saying do this, do that, do that. We had a lot of things that we had to do, and we had to put together a plan, but I was amazed at how motivating that was. People love it and it worked like a dream. And it worked extremely well here in Teradyne.

So to continue with the Teradyne team: First they went through goals and roles and set that up, and then we get into a strategy session where we figure out what's the process we're going to use. What's the strategy -- well we do the strategy first. What's the strategy for developing this product? And people aren't sure what the strategy is, but there is an enormous range of strategies you can have as you well know. And that is, you can build the whole thing in one big bang, you can decide to build versions of it. You can use all kinds of cyclic processes, you can prototype stuff. There are lots of different ways to build a system. And you may not make every part following the same strategy; you may have several strategies depending on what are the tough problems You want to identify the real nuts that will have complex technical issues and get them on the table early. And maybe you want to prototype them. All kinds of stuff. And so they work out the strategy first. You have quite a bit of discussion on that. What is it? How are you going to do this and why? And you think about the risks and what are the problems and exposures you've got.

So we think through alternatives -- you may want to just build it the way you did the last one. And then once they lay out a strategy then we say, "Okay well now what's the process you're going to use?" And notice we have all these unit processes that they've got. They know how to do configuration management work, how you write modulus and test them and all that sort of stuff. But then you have to weave that together into an overall process that you can use for actually making a plan. And so we have the team do that before they make a plan. And the purpose of this is to make sure you don't confuse people, you don't confuse how to do the job with how long it'll take. Because when you start right away to make a plan and you're thinking about how you're going to finish it in time while you're planning. It's amazing how often people came up and say we don't have time to do that.

And the contention that we follow with the TSP is that you want to do it the right way, and the issue is to figure out what the right way is and lay out your plan based on that. And what you'll discover is if you’re really doing it the right way it is the fastest, and cheapest and highest quality way to do it. And so we have the team start by figuring out what's the right way to do it, and only then do they estimate how long it'll take and the resources. And that turns out to be a very powerful way to do it because now the team has something to defend that they believe it.

And so the team has a big debate about the process flow and how do you want to do that? Do you really want to do this? Do we want to inspect every module? And the guys, you know, once they've got data and quality information they realize: yes, we're going to inspect every module and yes, we're going to do this and we're going to do that, et cetera. And you get the teams to buy that they're going to have personal reviews and that sort of thing. So they went through all of that and I talked about goals earlier, the goals they put together; management goals and team goals.

And in the second meeting, they actually set goals for the yields (% of defects found) they want to find in their reviews and what they're going to accomplish in terms of various things. There are a whole series of goals that they've already made when they're going through a lot of this planning, and so when they finish that they finally have got a process defined, they've got a list of all the products they've got the build. They put all that together and then they make a team plan. And so in the next meeting, the whole team works through how big are the parts, how long will they take to do each step, and they lay that out. They're not talking about who's going to do any of the steps yet. They're just laying out the whole job, and how much time it'll take, and what the effort is, and they also lay out how much time the individuals are going to have.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020