Leadership, Teamwork, and Trust

Published August 8th, 2011 Under Project | Leave a Comment

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 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 your interested in these topics, you should rather read Humphrey’s “Reflections on Management“.

The goal of the Team Software Process is to improve the levels of quality and productivity of a team’s software development project. 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 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”, Watts S. Humphrey and James W. Over, Addison-Wesley, 309 pages, IBSN 978-0-321-62450-5

Get more details on this book or buy it on amazon.com
Get more details on this book or buy it on amazon.co.uk

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 the 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.

Management 3.0

Published March 11th, 2011 Under Project | 1 Comment

In his foreword, Robert C. Martin wrote that he hates management book, but “this book is smart”. I think that this book might be smart because Jurgen is smart. To start with a full disclosure, I have to say that I know Jurgen Appelo since the beginning of 2008 when he wrote is first article for the Summer 2008 issue of Methods & Tools ” We Increment to Adapt, We Iterate to Improve”. You will already enjoy in this article the distinctive style that Jurgen adopt to investigate software development problem, although he was perhaps less tempted to put some grains of humor in his writing at that time. Read more

Succeeding with Agile

Published September 7th, 2010 Under Process | Leave a Comment

Now that Agile has established itself as the dominant new trend in software development, the number of books that deal with this topic is increasing every day. Besides the fact that Mike Cohn is a recognized expert in the area of agile project management, why should you buy his book rather any other book published on the same topic? After reading it, I will say that not only you should buy it, but rather you HAD to buy it. Read more

Reflections on Management

Published August 17th, 2010 Under Project | 2 Comments

This book is composed of papers previously written by Watts Humphrey. The people and management aspects of software development are often neglected in books and this one is a good source to start thinking about them… and improving our practice. The book is structured in four parts: managing your projects, managing your teams, managing your boss and managing yourself. In each part, it presents both general principles and real life examples or stories taken from Watts Humphrey career. This makes the book very easy to read as we can connect the theory to situations that we have met in our professional life. Read more

The Economics of Iterative Software Development

Published June 14th, 2010 Under Process | Leave a Comment

When you start reading this book, you will quickly understand that the authors are affiliated with IBM. This is nothing wrong per se, but this seems to influence too much the vision that the book proposes, ignoring approaches proposed by others. Including “iterative” in the title seems here to be only a marketing trick used to make it catchy. They don’t give you a precise definition of “iterative”, saying rather than it is a “modern method” (Tom Gilb was talking about evolutionary development 30 years ago) and that iterative management is result-based rather than activity-based. The difference between iteration and increment is not discussed. The IBM bias is visible when they state for instance that RUP is a “well accepted benchmark of modern iterative process”. Read more

keep looking »