Tsp(sm) Leading a Development Team

by Watts S. Humphrey

Book Overview

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.

• Format: Hardcover
• Language: English
• ISBN: 0321349628
• ISBN13: 9780321349620
• Release Date: September 2005
• Publisher: Addison-Wesley Professional
• Length: 307 Pages
• Weight: 1.70 lbs.
• Dimensions: 0.9" x 6.7" x 9.8"

Customer Reviews

Excellent book

Excelente obra que nos muestra la forma en como sacar provecho de los equipos de trabajo en el desarrollo de proyectos de software. Felicito al Sr. Watts. S. Humprey por su visión en el tema.

cogent analysis of team issues

TSP is a sequel to Humphrey's earlier book, PSP. That text concentrated on the actions of a single programmer or designer. Now in TSP, Humphrey expands the scope, to discuss what it means to lead and motivate a team of programmers. The acronym TSP stands for Team Software Process. But a close reading of the text suggests that you do not have to take "Software" literally. Your team might be a bunch of engineers or architects or financial analysts. Though, to be sure, the examples in the text and several of the guidelines pertain explicitly to code development. Yet if you are a flexible enough manager and team leader, you might be able to generalise those guidelines to your situation. Humphrey makes several remarks that some readers might cheer. He suggests that knowledge of specific tools and methods, while useful, is secondary to amassing an experienced and capable team. If you can do this, then they will surely be able to quickly pick up expertise in those tools or methods. If you have looked at job postings, you have undoubtedly come across those with a laundry list of detailed required skills. Some of which are mundane and low level. But try convincing that company's HR department of this! On the subject of team building, he dumps on commercial team building exercises. You know. Where some consulting firm charges your company a huge amount for taking your team to an offsite location for a day of artificial exercises. While these may indeed build some espirit de corps, typically these is no relation to the actual work environment and real issues facing your team. But because team building is such an intangible thing, and impossible to quantify, the team wastes a day and the consulting firm makes money. These two examples are actually minor parts of the text. But they really struck me (and perhaps you) as being very cogent analysis. Somewhat cynical maybe, but Humphrey has his wits about him.