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.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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.
Booch: Yes.
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.
Booch: Okay.