say, well, how could it be that this kind of a project turned out to be a debacle and a failure, and usually it's other matters at play. And so we tried it out, literally, on our guinea pig managers in the audience as a little half an hour session that Tom and I would actually stand up and do together, and we quickly discovered that we had hit a pressure point or something. And at lunch right after that session, people were full of stories to tell and things that they had seen that they weren't quite sure why things happened. And we literally started to collect ideas from all the developers and human developers and project managers who we got to meet, and discovered that we had a whole book on it before we knew it. And we ended up writing the book.
Carol: What do you think in terms of… publish the first book, based on a lot of stories that people gave you, a lot of information, primarily in the software development area, right?
Tim: Right. We're really talking about, well, the book is called PeopleWare, and it's subtitled Productive Projects and Teams. And we were looking at lots of different things. We were particularly interested in the phenomenon that we had seen firsthand, and I think everybody who's been in the industry can tell a story somewhere in their career, where a team somehow magically catches fire and it does an amazing job, where six or seven or eight or ten people were put together by the personnel department, and they never worked together, something clicks in and all of a sudden there's true synergy, and they do a remarkable job. And we started to talk to managers and people about how does that happen, and what's going on with that, and can you make it happen or can you increase your odds, or why is it some can gel, for lack of a better term, some can gel to really great, problem-solving groups, and others can use never much more than a gaggle of people.
Carol: And we've seen an awful lot of major software failures. There's the Department of Defense has billion dollar failures. Every software manager can recite 15 or 20 projects, and sometimes they'll go on and on about how projects failed and simply speaking, a lot of times they blame the teams. What kind of things did you see that were different, in particular, with the teams that had outstanding successes?
Tim: There are a couple of things that it turned out, it seemed to us. Teams that had great successes, well a couple things happened. One is the team itself kind of becomes a decision-making group. It almost looks like an elitist peer group. They'll decide all sorts of things. They start to take the project on in a way I don't think any manager can force them to do. They really bind to it. On a lot of projects, you'll see, if you really start to talk to people about what do they want to do on this project, they'll all talk to you about things they want to learn, new skills. Somebody says, well, this project's a Java project and I don't know Java very well at all, and I think it's really important with the new Web technology, and I really want to get my Java expertise up on this project. In second place is, we've got to the job on this project. On the gel teams, the goal on the project is, honest to goodness,
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
