An Interview with Watts Humphrey, Part 29: The Task-Time Measure and Presenting the Plan to Teradyne Management
This interview was provided courtesy of the Computer History Museum.
The Task-Time Measure
Humphrey: So all of a sudden you have kind of an idealized plan that says if everybody was busy full time and could do any of the jobs, here are the total jobs that we've got and here are the times that people have got available and that works extremely well. Now one of the things that we found right away is that we're not talking about calendar time. Remember now I mention in the PSP that we measure the time and the size and the defects. And the time we measure is the time for tasks or process steps or phases. And so that's task time, it's not calendar time, and so the question now is, what's the relationship between task time and calendar time? Let me just ask you that. Suppose you have a project to do and you list all the tasks for that project and then you put against that how much time you're going to work and then you work and you do the job. At the end of the day or end of the week, what percentage of your time was task time and what was something else?
Booch: My guess is that your task time, if you're a code warrior, is probably something like 20 to 30 percent at best of your calendar time.
Humphrey: You're probably right.
Booch: There's this study I read by a sociologist from Berlin of all things, who did a study of how developers actually spend their time and he, through the study, enumerated a long list of things that cause friction, and he was amazed himself how little time the people actually had to do things because they were busy with meetings and things didn’t work and stuff like that.
Humphrey: Well the thing we found was that the task time in various organizations today without the PSP and TSP, in an 40 hour week an individual engineer will spend somewhere between three, five, ten maybe 12 hours a week doing project tasks. The rest is all kinds of other stuff. And people are very surprised at that. And what we find with the TSP is astounding because now instead of just sort of hoping you can get more time in, the engineers are actually measuring and managing their task time.
And they're tracking it every week. They look at it, they've got a tool, they can follow it. So we find that a team will begin at eight to ten task hours a week and after a period of weeks, it takes a while, they'll get up to 15 to 16 to 18. We have teams running over 20 but not many. Most of them are running in the 15 to 18 range. And what does that do to productivity? I mean, that's enormous. You double the task hours per week for the individual engineers and you discover that you have in fact doubled productivity. It's amazing and it's an extraordinary result.
Booch: I was trying to level set where we are in the time frame where the TSP really reaches this level of maturity. Because we're now talking around the turn of the millennium now -- would that be correct when your data gathering and such and your experience of the projects have reached this kind of fruition?
Humphrey: We were in about 1997 with Teradyne. And we basically come to most of these conclusions before we did the Teradyne launch. We learned a lot from the first couple of projects. It's amazing when you've got all this data and stuff and you look at it. You learn stuff real quick. So we, as I think I mentioned before, had a period of years in here where I learned more in the brief period than I ever really learned in my life. But it's an unbelievable education.
So in any event, the task time thing and what we did was evolving the process with the task management and all of that. We gradually evolved it, but that was there at the base starting at the very beginning. I went through with the team, they completed their overall plan, determined the available hours the people had -- remember now when the people lay in their time we have them actually look at the calendar. When are their holidays? When are you taking vacations? What's going on in your life?
So we actually had each of the engineers lay out his or her personal schedule for the whole period of the project. How many hours they were going to be able to have during Christmas breaks and Thanksgiving breaks and you name it and so they laid that out and then we spread it over the calendar and the calendar was 18 months, not nine months. And so the team was kind of shaken by that.
My God, they couldn't believe it. “What are we going to do about that?” So we had to make another step now because this is still an idealized calendar. And I said, "You've got to make a real schedule." And so we had the overall plan. Before we went to make the real schedule we made a quality plan. Remember these are all PSP-trained engineers. They knew how many defects they injected and found themselves, and what their yields had been in PSP training.
So making a quality plan was no big deal. They basically estimated how many defects would be injected and removed in each phase and how many would be left at each step and how many they'd find in test and how many would be found in the field and all that sort of stuff. And they had it all there and it was great, marvelous.
And so they put the quality plan together and they went into we call Meeting Six, where they put together the individual team plans. Now you take the plan that they've got, and they start to allocate tasks to engineers. They go through the allocation and the engineers each produce a personal plan, which is rolled up into a team plan. So now every engineer has a plan for what he or she is going to do to go through this project. But when they make the detailed plan they don't make it for the whole project. They make the overall plan for the whole project, then they make the detail plan for the next two, three, four months. And they don't go very far out because you can't. When you actually follow the plan lots of stuff will change and it's a waste of time to make detail plans beyond more than a few months. So we make it for the next few months only and they lay it out and then we do load balancing.
And you'll discover that when you put a team together there's the lead designer who has got, you know, hundreds of hours of work to do and you'll have somebody here who has just arrived who has a few dozen hours of work to do and so the team really has to work together to do load balancing and figure out how do we move this work around and unload the lead designers and the hot shots and get everybody else to work. And so we have to team people up and do all kinds of stuff. And this is a big team negotiation. Who can work with who and what can they do? And that's part of Meeting Six -- we go through load balancing and get that done. And that's enormously effective. I mean you really do end up with people thinking through how they're going to work together. And that doesn’t happen on most teams. But it's done and they have this plan. They know how they're going to do it. And then after Meeting Six they've now got a plan, they got a schedule, they know who's going to do what, and they're ready to go to work on Monday morning.
And then they go into Meeting Seven where they make a risk analysis. They go through what are the risks on this thing, and they go down the list and what are the problems and whose going to handle each risk? The team members pick up as owners and a lot of them the team leader owns, but there are others and they rate the risk as high, medium and low likelihood and high, medium and low impact. They put together mitigation plans for them.
So the team now has a big list of risks, and they have the top priority risks, and they have mitigation plans for them. Then we go into Meeting Eight, and the team now puts together the management presentation. And they've got an enormous amount of material. They know exactly what they're going to do. And it's a very impressive result. These guys have got a complete plan and it's really an amazing result. And they're committed to it, they believe it. This is a plan that they are committed to, they know what it is, they know how to go about it. And so we went back to the management meeting. Now remember management said, "We've got to have it in nine months, there's no alternative." And the team had a plan for 18 months. So there was a lot of nervousness when we started the morning meeting -- it was Friday morning. And the team was all there, and the general manager came in, and the marketing VP and that sort of thing.
Presenting the Plan to Teradyne Management
And so the team started. I introduced them briefly, and then I turned it over to the team leader, who went through the presentation of what they did, how they made the plan, and that sort of thing. And then they started to go through the plan. And when he hit the 18 months everything stopped. And the general manager started poking at him and asking all kinds of questions, and he was beginning to soften up, you know, all right it sounds like you’re right, and the marketing VP blew up. He said, "You're going to kill the company. We can't possibly wait 18 months."
He said, "The competitor is delivering a better product right now." And everybody was sort of stopped and stunned. How can we live for 18 months when we have a competitor that's got a better product out there today? So I asked him, "The competitor actually has a working product in the field right now?" And he said, "Yes." I said, "When did you think they started developing that product?" He said, "I don't know." I said, "Probably a year or two ago right?" And he said, "Well, yeah probably." I said, "Why didn't you start then?" He said, "What do you mean?" I said, "Your job is to anticipate the market. These guys can't fix that problem for you." And he kind of mumbled and sat down.
I really kind of beat
him up there. But the general manger then bought the plan. We came out of the
meeting, and the team turned to me and said, "
The teams win these arguments they've gotten better and better in terms of bringing in alternative plans. They'll come in and say, "Look, with this number of people it will take us this long." The first Microsoft team for instance, they came in with ten alternate plans. They said to management, "To meet your date we'll need two more people, and we've got to have them on this date, and they've got to be PSP-trained. With the team we've got it will take this long or if we reduce this function we can do this."
And so we guide them on having multiple plans to go in and give management various alternatives how they want to do the job. We also typically have the coach or the team leader go in and meet with the senior manager before the final management meeting so that we don't get him surprised. But we find the whole thing only works if we've had management training ahead of time. So we have an executive seminar where we put senior management through what this is all about and how it works and why. So you get them to understand the dynamics of what this process is all about. And then we have training for the team leaders and lower level managers, where they go through how do you manage projects like this?
The executive seminar is one day, very straightforward, no big deal, and typically top executives will go through that. We recommend that it's got to be top executives. Without senior enough management, the process won't stick, and that's the problem that we've had at Microsoft and several other places. The top person is the one that keeps it going. And so that's crucial. And then the managers, we like to put them through a four day course. If the managers have been through the exec seminars, it's only three days. And they learn it, they go through what it's all about. How do you manage teams? What's the launch process? How do you use the data and what do you do?
And then we don't train the engineers until their managers are trained. And during this whole cycle, typically in the executive seminar, the management team picks the first teams that they want to use the TSP, and they identify the chain of management and that sort of thing, and then they go ahead and train all of the managers in the management chain between the top executives and the team, and then we go to training the team members.
Our original PSP training took two weeks. Everybody spent two weeks, but managers typically just don’t want to have their developers take two weeks for training. They had to shut down for two weeks to get their teams trained. And so we found surprisingly that as people get more and more receptive to this. Initially, people objected. They couldn't believe that the PSP made any sense. By and large we're now running into lots of places where they're quite receptive. “The PSP, oh yeah, we heard about that, how that worked." And they're not fighting it anymore. And so we find that we can get the basics across in a week, enough to actually go through with the team launch.
Booch: So the initial times, it was you doing the training. Can you tell me the growth of how you developed SEI teams of people to go off and do this training? But was it in fact you primarily in the first? Tell me how it grew.
Humphrey: Well I did it at the very beginning. Remember there was some SEI people in the first PSP course that I taught that went into this.
Humphrey: One of the key guys there was Jim Over. Ever heard of Jim?
Booch: I have not.
Humphrey: Okay. Well Jim Over is the leader of the TSP group at the SEI. I work for Jim. I work with Jim. He laughs when I say he's my manager. But as you know I really don't work for anybody.