Book Review: Leadership, Teamwork, and Trust
The late Watts S. Humphrey has been an important personality of the software development world. He led the development of the Software Capability Maturity Model (CMMI), an internationally recognized standard in the field of software process improvement. The title of his last book “Leadership, Teamwork, and Trust – Building a Competitive Software Capability.” is a little bit misleading as it is mainly focused on the Team Software Process (TSP) than presenting a broader perspective on software development management or leadership. If you are interested in these topics, you should rather read Humphrey’s book “Reflections on Management”.
The goal of the Team Software Process is to improve the levels of quality and productivity of a software development project team. In its first half, the book provides a global presentation of the TSP with the help of many real cases and examples. The second half consist of five appendixes that present detailed information on how to get started with the TSP and how to use it within software development organizations. In this section, I particularly liked the guidelines for the pilot project selection and the project launch review.
The information in the book is well-structured and the mix between the theory and practice parts is fairly balanced. I will recommend this book to every software development manager and project manager who is interested in getting an additional perspective on how to improve its projects results.
Reference: Leadership, Teamwork, and Trust – Building a Competitive Software Capability, Watts S. Humphrey and James W. Over, Addison-Wesley, 309 pages
Quotes
With few exceptions, software organizations rarely make firm product delivery commitments, write fixed-price development contracts, or provide meaningful product quality warranties. This has led to a general industry attitude that defective software is a fact of life and that the customers must bear the cost, expense and inconvenience of recovering from the poor quality of the software product they buy.
The reason that most software developers don’t seem to get excited about meeting cost and schedule commitments is that these usually are not team goals. Although management may think that cost and schedule are important, typically no one ever tells the team why these goals are important, and the team isn’t involved in making the commitments. As far as typical software teams are concerned, management makes the cost and schedule commitments, and the team meet them if they can. In fact, the team often think that management’s requested commitments are totally unreasonable, but because they are paid to do what management asks, they give it the old school try.
Typical software teams get excited about delivering great products and having a cohesive team experience because these are the tacit goals of every member, and the team doesn’t even have to discuss them. In fact, teams rarely discuss goals at all; most knowledge-working teams just start working. There is no team-building effort, no discussion of team goals, and in fact no real discussion of management goals.
When people perform even a simple task, they tend to forget or skip steps, and their results are often substandard. As processes become more complex, process discipline is generally poor, so it is not surprising that for larger and more extensive processes like software development, poor process compliance is almost inevitable. That is, it is inevitable unless the practitioners know precisely what to do, have well-designed operational processes to guide them, and are motivated and supported to precisely follow this process.
