TSP(SM)-Leading a Development Team
Leaders of software-development projects face many challenges. First, you must produce a quality product on schedule and on budget. Second, you must foster and encourage a cohesive, motivated, and smoothly operating team. And third, you must maintain a clear and consistent focus on short- and long-term goals, while exemplifying quality standards and showing confidence and enthusiasm for your team and its efforts. Most importantly, as a leader, you need to feel and act responsible for your team and everything that it does.
Accomplishing all these goals in a way that is rewarding for the leader and the team—while producing the results that management wants—is the motivation behind the Team Software Process (TSP). Developed by renowned quality expert Watts S. Humphrey, TSP is a set of new practices and team concepts that helps developers take the CMM and CMMI Capability Maturity Models to the next level. Not only does TSP help make software more secure, it results in an average production gain of 68 percent per project. Because of their quality, timeliness, and security, TSP-produced products can be ten to hundreds of times better than other hardware or software.
In this essential guide to TSP, Humphrey uses his vast industry experience to show leaders precisely how to lead teams of software engineers trained in the Personal Software Process (PSP). He explores all aspects of effective leadership and teamwork, including building the right team for the job, the TSP launch process, following the process to produce a quality product, project reviews, and capitalizing on both the leader's and team's capabilities. Humphrey also illuminates the differences between an ineffective leader and a superb one with the objective of helping you understand, anticipate, and correct the most common leadership failings before they undermine the team.
An extensive set of appendices provides additional detail on TSP team roles and shows you how to use an organization's communication and command networks to achieve team objectives.
Whether you are a new or an experienced team leader, TSPSM: Leading a Development Team provides invaluable examples, guidelines, and suggestions on how to handle the many issues you and your team face together.
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.