Review By: Harmon Avera, Jr.
07/08/2010In "TSP: Leading a Development Team," author Watts Humphrey describes his Team Software Process (TSP) for building high-quality software. He also emphasizes the team leader's role as a leader--not a manager--and as the interface between the team and management. The book is divided into five parts, plus appendices. The writing is clear and well organized in the style of a guest lecturer delivering a seminar. Humphrey poses a general question at the start of each section and then uses anecdotes from his extensive personal experience to explain his philosophy and answer the question.

Each section describes an aspect of software development teams, both from within the team and from the outside. The introduction lays the foundation for the rest of the book giving broad-brush definitions for terms like leadership, team, quality, and motivation. Next, "Building Teams" dives into the nitty-gritty of forming a team, having the team create the development plan and schedule, and launching the team and its work. Part three, “Teamworking,” develops Humphrey''''''''s Personal Software Process (see review on StickyMinds.com) into a team approach. Part four, “Relating to Management,” describes the need for management support of this process, how and what the team leader should report to management, and how to protect the team from external pressures such as feature creep and workspace quality. Finally, “Maintaining the Team” discusses developing the team and the individual team members, keeping a team together and improving its performance, and team leadership. The appendices provide Humphrey''s ideas of team roles and describe networking with typical corporate examples.

Many development methodologies promise high-quality software, delivered on time and within budget. Current favorites like extreme programming and agile development, which seem to minimize “process,” may appear to be on the other end of the development spectrum from Humphrey''s TSP practices. However, his studies and statistics indicate that teams using this process can achieve significant improvement in schedule estimates and software quality without much loss in productivity.

The book is laid out like a PowerPoint presentation, numbered bullet points within a chapter have a few paragraphs developing each point. This gives the pages a chopped-up look, but the text flows well and remains quite readable. It is a practical how-to manual for Humphrey’s TSP--definitely aimed at the development team leader--and Humphrey gives clear directions on how leaders can be successful within their teams, to their managers, and to themselves. Humphrey understands human nature as well as software development, and he explains how the team-leader can bind the team together through shared goals, plan and schedule ownership, delivery successes, and overcoming obstacles. Well aware of the difficulty in getting developers to follow a formal process, he spends several chapters laying out the team process and enumerating the advantages of following it. He tells readers which schedule and defect data to gather, how best to gather it, and how to use the data within the team to measure progress and motivate the desired team behavior.

In this age of distributed teams and outsourced development, Humphrey makes a strong case for creating a motivated, co-located, and self-directed team. I highly recommend the book for its content, presentation, and use of statistics and anecdotes to support using TSP.