An Interview with Watts Humphrey, Part 32: International TSP Use and the Trouble with Knowledge Work
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
International TSP Use
Humphrey: So there's no
question this stuff [PSP] works and, as I say, what's frustrating to me is with
all of that data and all the absolutely rock solid evidence we've got, why is
it that people aren't just saying, "Oh, yeah, we've gotta
do this and we're not." And so that gets me to another one of the things I
wanted to talk about.
Some of the other countries, by the way,
we're working with: we've got interest from Turkey, some companies and the
national government there is starting to work with us.
As I say, I'm terribly frustrated that
there is essentially no interest in that in the
But I contend that any executive worth
his salt, or any business that wants to look at the
future, the choice they've got is whether they want to be the GM down the road,
or the
Knowledge Work
Humphrey:
The question of why the TSP works is an interesting one. You've, I'm sure,
heard of Peter Drucker.
Booch:
Oh yes.
Humphrey:
Died a couple of years ago. I've heard him talk on a number of occasions. I've
thoroughly enjoyed his books and papers. One of the things he has said, and
he's talked about it for a number of years now, is knowledge work. He talks
about the knowledge workers, and he makes a point, which I think is enormously
perceptive. He fundamentally says you can't manage knowledge workers. They have
to manage themselves.
Well, what's
astounding to me is, first, that's a terribly perceptive point, and second, no
one has picked up on it anywhere. Everywhere you turn someone says, “Sure,
that's true. They've got to manage themselves. Let's have them manage
themselves. Great!” But the knowledge workers don’t know how to do that. So
it's a fundamental change in the whole management system to do that. And Peter Drucker clearly thought through that, but he wasn't in a
position to go do it and make it happen. And so that's the question that I have
been struggling with regarding the TSP and the PSP. The question I had, and I
think I mentioned when I started with the CMM and then moved on to the PSP and
TSP, was to look at how would individual developers really do software if they
did it right? And a big part of that was learning to be a personal manager,
learning to make your own schedule, track your own progress, to manage the
quality of your own work, to make commitments and to consistently meet them.
How could individuals
do that? That's the framework on which the TSP and PSP are built, giving people
the tools to do that. And as you probably know, most software folk, you tell
them to do something, unless they really know how to do it, they'll probably
put it off. As I think I mentioned in my IBM story, the software people had an
enormous number of things they had to do, but there were only two they really
must do before they could ship a product. That was code and test. So they never
got around to anything else. That's exactly true of the software community. You
tell them, “What you really need to do is get your requirements nailed down and
do inspections and do all this and that.” And the question most of them have
is, “Well how do I do that?” They by and large don't know. They've never gone
through that. They don't have a framework to do that. They don't have a process
or guidance on how to do it. Hard to find people who can.
So they start off coding. I mean, they start off trying to put together a
design. They start doing what they know how to do. They don't have time to play
around.
And that's the issue
we run into in the software business. The people really are so busy, they're under such enormous pressure, that they just
can't take the time to figure out how to do something. And that's very obvious.
I mean, I sit down and I've got all kinds of data on how long it takes to
develop a process, and the TSP process that I developed, with all the
guidelines and the scripts and stuff like that, was several hundred hours of
work. And I'd been developing processes for years. Software developers just
don't have the time to do that. They'll use what they can get their hands on. They're
very pragmatic. They'll use my process if they know about it, and they're
convinced it will work.
Every time I wrote a
program with [PSP], I would sort of modify it and update it, so when I write
programs, I want to change the instruction set. When I work and use a process,
I like to fix it and adjust it. I don't change it on that particular project,
but I'll make notes and I'll go back and fix it.
And so I'm constantly
evolving my process, but I find engineers don't do that. By and large, they use
whatever process they have got. If it works, they're happy and they use it. So
we learn from it when people use our processes, and we update them to make them
more convenient. But the developers won't do it. They aren't willing to take
the time. They don't have the time. And so fundamentally, this whole idea that
“just tell the developers to manage themselves,” managing themselves takes a
lot of work. People have got to be able to find out what their requirements
are. They've got to understand what management's goals are. They've got to put
together an overall plan and strategy for how they're going to do it. They've
got to negotiate their schedules and commitments with management, all of that
stuff. Then they've got to do the work and they've got to track their progress,
they've got to handle it.
There's an enormous
number of things, and without guidance on how to do that stuff, they can't do
it. And by the way, they also need room from management. Management has got to
really take the time to meet with these people and say, “Here's what we want
and why.” That's what the launch process does. It's extraordinarily effective.
The whole idea of it is to actually give the developers and their teams the
power to figure out what it takes to do the job. And so when management assigns
a project to a team, the team goes off and takes several days to put together a
plan to do it, and they really crawl through it and they do a thorough job. They've
got historical data, either on their work or other teams, and stuff like that. And
they'll go through and make a plan.
More Example Projects
And when they've
finished, they know what it'll take to do the job, and they have so much
confidence in what they've done, and so much conviction, that when they present
their story to management, management doesn't argue with them. I mean,
basically, these people know. They've got the conviction. Management is
universally impressed with the teams when they come back. They've got
credibility, so they negotiate with management. The teams always end up
winning, and they've done that time and again. I remember one case, this was a
good many years ago now, it was a team at Ford, the
Ford Motor Company. It was a small team. I don't know if they're still doing it
or not. I think they've got some people that may be, but I'm not sure. But I
haven't been in touch with them for years.
But in any event, this
team had started a project. I think there were five engineers on it. Management
had gone through with them and given them the goals, the goals where you had to
get this done in a year. Well, it turned out to be an enormously ambitious
project, and the team basically went through it. The management reason you had to have it in a
year was, they had a market window and they had cost limitations. And the team
went through this thing and came back and presented the story to management and
said, “Look, with this team, this will take five years. If you want to put
twenty-some people on it, we can probably bring it in a lot closer, but no way
we can get to a year, and here's what we've got to do.”
And they went through
the story and that sort of thing, and so management said, “Let's think about
that,” and then they canceled the project. Well, that's an enormous success.
What teams typically do is management tells them they've got to do it in a
year. “Okay, chief.” Then the team will say: We'll try.” And they'll break
their hump for about eight or nine months, and the management says, “Where are
you?” and they'll come back, “Oh, it'll be another six or eight months.” And so
the delay will keep going and they'll lengthen the schedule. After about two
and a half years, they will have gotten where they're working under enormous
pressure. They don't do the work right. There are all kinds of problems. Then
they kill the project, and they waste a lot of money, they waste a lot of the
engineers' time. Nobody wants to do that.
So having reality on
the table right away, by and large, with very few exceptions, that works. We do run into a few cases. I remember one case in
one company, which I won't name, the senior vice
president had basically given a directive: “You'll get this project out by this
date.” I was there talking to the management team. And they were scared to
death, because this VP was unwilling to come to the lab and talk to the team. He
was unwilling to listen to what they were doing. It was all done remotely. And
the last time somebody had gone back to him and told him they couldn't do it,
they fired him.
So they finally
concluded there was no way they were going to do this. This guy was dealing
through a pipe. He didn’t have the guts or self-confidence or something to deal
with his people directly and he was totally unreasonable. And so they did. They
basically did not use the TSP, and about a year and a half later, the lab
director was fired, and so was the VP. I mean, this sort of thing goes on all
the time. It's crazy. And so you do get a few nuts like that in the management
chain, but not too many. Most of them are smart enough to know that when the
team really says they can't do it on this schedule, that's probably true. The
problem is that few teams know enough to say they can’t do it on management’s
schedule. If they did, then we wouldn’t have so many disasters.
So the point I'm
making here is that the teams discover that when they have data and they have
facts, they can talk to anybody. I mean, we've had cases where brand new
engineers, with a year or two of experience, going through this stuff, will
explain to a senior vice president something, and the senior VP buys it,
because the engineers have the data and they understand what they're talking
about, and they've got conviction. And so what these engineers discover is,
they've got enormous power that they never had before, and they're able to
actually negotiate schedules that make sense. Their work is a hell of a lot
more fun. They work at a reasonable schedule, and it works. It works
extraordinarily well.
Let me talk about one
case in
And so in the launch,
the team had gone through and said, “We've got a team goal of working 40-hour
weeks. We're also obviously going to meet the schedule and all that sort of
stuff.” I was reviewing the results of the project. They said, “We didn't quite
make our goal. We worked 45-hour weeks on average, but it was a hell of an
improvement over 70.” They were home for dinner. It was an experience they
enjoyed. It was great. They delivered on schedule to test. The product sailed
through test without any particular problems at all, and the team was just
terribly excited about it.
And so we see
engineers, software folk, all of a sudden becoming heroes instead of bums. And
these people deserve to be heroes. They're bright, they're capable. They do
marvelous work, but at the moment, they are suffering under this cloud, because
they really don't have the skills to manage themselves.
And the reason this
is an important issue is because -- this is back to Peter Drucker
-- the first real large-scale knowledge work was in software. And I'd always
wondered, years and years ago, when I started, I'd done all the hardware stuff.
I could manage 30, 40, 50 people doing hardware work. I could walk around. I
knew where things were. I didn't have any problems. But even with a team of ten
software people, unless I was really willing to take the time and really sit
down and go through with each one what was going on, there's no way I could
know what they were doing.
And furthermore, as
Fred Brooks once said, they're 90 percent through coding most of the time. The
software people have no idea where they are typically today. So you go ask them
where you are, and they'll go, “Oh yeah, I'm on schedule. I'll be in to test
shortly,” and that sort of thing, and they literally don't know when they'll be
done. So all of that, the lack of skills and all of that, we end up with people
who have no credibility with their management. They end up getting pushed into
commitments they can't meet, they're failures. They'll work god-awful hours and
we see that throughout the field. It is not the kind of industry that is going
to be healthy and growing over time, the way it's being run today.
Booch:
I do have one question, and that is, you spoke about not really being able to
know when they're going to be done. That triggers a thought with regard to
Barry Boehm and his work on economics. I'm wondering what connection you might
have with Barry's work.
Humphrey:
Oh, I've been involved with Barry. I know him well. Certainly his book on
software economics, I've used that. At the beginning, I used it in writing my Managing the Software Process book 20
years ago when I first joined SEI. So I've enormous regard for Barry, and
actually, he has had some people teach the PSP in his program. I'm told he's
familiar with it, although again, the same thing, they don't have the same kind
of commitment to it that we do, because they don't have that experience. So Barry has been a supporter, but as I say, he's not really on the
inside making it go. He's got other things he's committed to. Okay?
Booch:
Got it. Very good, thanks.