Home > Articles > Software Development & Management

An Interview with Watts Humphrey, Part 32: International TSP Use and the Trouble with Knowledge Work

  • Print
  • + Share This
In this transcript of an oral history, Grady Booch interviews SEI Fellow Watts Humphrey. In Part 32, Humphrey discusses the use of TSP and PSP in other countries, why knowledge workers need to learn to manage themselves, and how TSP can give engineers the power and credibility to negotiate with management.

This interview was provided courtesy of the Computer History Museum.

See the entire interview.

From the author of

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. South Africa, actually, it's quite an effort there. There's a major effort under way in Colombia, South America. They had our folks down there and they want to launch a big effort. We've got something in Mauritius, I mean, so it's kind of popping up in a lot of places, and a lot of these countries want to get in on the act. The software industry is a very attractive industry and, by and large, most of them know that you literally can't undercut the cost of labor. If people really want to buy by the hour, India and China are probably lower than most everybody else. Some of the African countries may be able to get lower rates at some point, but I think everybody's beginning to realize that the Toyota strategy is a hell of a lot better than the China strategy in terms of really getting in there and building an industry. Build a quality business, build on performing and doing what the customer wants. As you probably know, Toyota got way ahead of U.S. industries from a quality perspective, and it took a U.S. industry about 20 years to wake up, and once they got started, they still haven't caught up. Toyota keeps improving, and the other people can't catch them, and that's why GM is now a smaller company than Toyota, which is kind of astounding. These people, basically, that's a history that they see and they say, "Hey, maybe we can do that here." That's what we’re beginning to see.

As I say, I'm terribly frustrated that there is essentially no interest in that in the U.S. Even the academic side, the government side, industries are all looking at it very narrowly. And I had some experiences with a couple of big companies, one of which we know well. The big software contracting companies that go out, and they do body shop work -- contract software work. They run facilities. And basically, I talked to them, and the reaction that I got was -- these are from senior executives in both companies -- basically, they asked me, “You mean you want me to spend profit dollars to cut revenue?” And that's staggering. Well obviously, when you do quality work, you do it right the first time, people don't pay you for doing it wrong and then fixing it. So it actually does reduce revenue, there's no question

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 Toyota. And I think the choice is pretty clear cut, unless you've really got very short-term vision. And so that is, as I say, terribly frustrating, and what's most frustrating is, I get that from DOD contractors as well, these great big companies. I've gotten this from several of them. They basically say, “We can't afford to do it.” I think the lower level managers, that's true. The lower level management really can't afford to take money out of their profit pocket and actually end up better controlling their costs, cutting their revenue stream and that sort of thing. Even though it would improve their competitiveness and certainly help the national economy, and certainly the defense business, they just aren't willing to go into it, and they don't feel they can fight it through their own management. And that's a real risk and a real problem for the future of our country.

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 India, one of the Microsoft projects. They'd done a great job and I was there reviewing their results. And it turned out when they'd launched the project, they had just come off a previous project which was an absolute disaster. They worked 70-hour weeks, they were late. The project had all kinds of problems in test. It was a mess. And so they decided to learn the PSP and do the TSP on the next project. So this was the first TSP project that they'd done, the very first one.

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.

  • + Share This
  • 🔖 Save To Your Account