Winning with Software: An Executive Strategy

MESSAGE / CONCEPT The message here is that if you wish to develop good software, particularly of any significant size, you need a robust process and a team of disciplined programmers/engineers. The operative words here are robust and disciplined. These two terms, particularly the discipline one, resonate particularly well with us, because one of the significant causes of a problem project is the lack of discipline to follow a defined process. The further message is that "quality counts" - even more so than schedule. This is particularly relevant to any business that uses software. When the project starts to "go off the track", the project team might go back to what they are comfortable with which often is the "lazy" approach. A bit like a football team - when things go pear shaped and they are on the back foot, bad habits sneak in .....tackles get missed, individuals don't get into position in defence, the ball gets dropped, the pass goes astray.....discipline goes out the window! His personal software process (PSP) and team software process (TSP) aren't incompatible with the extreme programming (XP) or agile software development movement, although the XP crowd may disagree. I don't think Humphrey would disagree even though he is coming from the Software Engineering Institute (SEI) angle and was a significant player in the SEI Capability Maturity Model (CMM) development which is often held up as the antithesis of XP. Having said all that and noting that the focus is on software development, the messages are equally applicable regardless of what is being developed. Overall, it is a good read with some excellent advice and practical examples. So don't be put off by the title and the fact it can be a bit dry in places, insert for software, your particular technology (missile, bridge, network, satellite, communications system, etc) and it will still make sense and provide you with some useful insights. WHAT WE LEARNT It more confirmed our present approach rather than taught us something new. BUT, it did enlighten us on a number of techniques we can use to show the value of taking a robust and disciplined approach to project management. So much so, we are getting another copy of the book and giving it to the manager of the project portfolio in one of our client organisations. This confirms for us that this is a book for executives.

This book is targeted at executives, but it's also useful for developers who might be curious about what Humphrey's been talking about for the last few years in his PSP and TSP processes. Value comes in this book from understanding what many problems in software development are, why you have to address them, and at what level they need to be addressed. That said, it was difficult to really 'close the loop' and get the end-to-end on how one would go from having recognized the problems to organizing people to solving it, to actually rolling out solutions. Still, a good book nonetheless, and more than worth reading, especially if you don't feel like sitting through one of the PSP/TSP books.

Mr. Humphery has produced another winner. Every example is easy to relate to real world environments. The Summary and Conclusions at the end of every chapter are real jems. I have raved about the book to everyone at my company and I am trying to get sponsership from executive management for the processes defined in the book.

The first point of the book is one that still must be made to many, but in reality should have been obvious some time ago. Namely, that software is a critical component of the structure of the modern business. Humphrey makes the case clearly, concisely, and convincingly for the need for all executives to learn the basics of how software can be used to improve their business. That alone makes the book worth reading. His next step is to explain how to create a team of software developers that can build a quality product on time, on budget and where the team is still functional after the product is built. That part is hard and Humphrey outlines what he calls the Team Software Process (TSP), which is designed to build and manage quality software teams. With a small set of basic principles and a complete set of charts, the TSP is easily understandable and is presented at the non-technical level of most managers. The problem is of course that managers often follow paths based on their personal beliefs or insecurities and not those of impersonal realities. For this reason, Humphries book suffers from the unavoidable weakness of all such books in that readers have the option to ignore it. This book is packed with sound advice for managers of software development teams. It shows you how to create the process and provide the appropriate combination of cuddling and clubbing. However, whether it works or not is up to the practitioners, all too few of which will be willing or able to apply the advice.

This book is well written and makes a compelling case for the author's personal and team software processes (PSP and TSP respectively). Whereas the first four books by Humphrey, published between 1989 and 1999, were aimed at individual software engineers and technical managers, this one is for higher level decision makers who are probably wondering why software development seems to be a money pit while other enterprise business units manage to operate with some degree of efficiency. The case that is made in the book remains focused on business. More importantly, it shows how to apply productivity accounting and quality techniques defined in both the PSP and TSP can introduce controls to software development. What I like about the book is Humphrey's complete change of tone from his previous books, which were written for technical professionals, to appeal to business executives. He addresses all of the key points: why projects fail and how to prevent the failures, the need for leadership instead of mere management, and the importance of not only building a team approach, but in changing the culture in the development organization. These are points that business managers understand in practice, and it shows that development can be a controlled process much like manufacturing or service processes that are likely to be the company's core business. They also dispell the fallacy that software development is different.Although the book stays focused on business aspects, Humphrey does drift off into technical territory at times, sometimes to the point of risking the attention of the business reader. He also misses an opportunity to show how PSP and TSP are natural fits into organizations that are using Extreme Programming, which would have given the business audience some leverage when dealing with their technical counterparts. However, that is probably beyond the scope of the book. If you want to trace the evolution of PSP and TSP it's documented in the author's earlier books: Managing the Software Process (1989), A Discipline for Software Engineering [and one of the best in my opinion for its completeness and approach] (1995), Introduction to the Personal Software Process (1996), and Introduction to the Team Software Process (1999). If you are exploring either the PSP or TSP with a goal of building a business case this book is ideal. Also note that there are open source tools developed by the Process Dashboard Initiative and distributed at no cost that will greatly aid in implementing the recommendations that are made in this book.