TSP(SM)-Coaching Development Teams

Hardcover (Print)
Buy Used
Buy Used from BN.com
(Save 41%)
Item is in good condition but packaging may have signs of shelf wear/aging or torn packaging.
Condition: Used – Good details
Used and New from Other Sellers
Used and New from Other Sellers
from $27.50
Usually ships in 1-2 business days
(Save 49%)
Other sellers (Hardcover)
  • All (8) from $27.50   
  • New (4) from $45.79   
  • Used (4) from $27.50   


Most modern software development projects require teams, and good teamwork largely determines a project’s success. The Team Software Process (TSP), created by Watts S. Humphrey, is a set of engineering practices and team concepts that produce effective teams, thereby helping developers deliver high-quality products on time and within budget. TSP bridges Humphrey’s seminal work on the Capability Maturity Model (CMM), an improvement framework for the entire software organization, and his Personal Software Process (PSP), practices designed to improve the work of individual developers.

Typical first-time TSP teams increase productivity by more than 50 percent while greatly increasing the quality of their delivered products. However, TSP teams only continue to improve under the guidance of a capable coach. One industrial-strength team, for example, increased its productivity by an additional 94 percent and reduced test defects by 85 percent through three consecutive TSP quarterly product release cycles. Without competent coaching, teams often do not progress much beyond the initial one-time improvement seen after the introduction of the TSP.

Humphrey distinguishes between TSP coaching and TSP leadership, explaining why the skillful performance of both functions is critical. In this practical guide, he shares coaching methods that have repeatedly inspired TSP teams and steered them toward success. With the help of a coach, TSP teams undergo a brief but intense project launch in which they define their own processes, make their own plans, and negotiate their commitments with management, resulting in dramatically enhanced performance.

Whether you are considering the TSP or are actively implementing it, TSPSM–Coaching Development Teams provides the invaluable examples, guidelines, and suggestions you need to get started and keep developing as a team coach. It’s meant to complement Humphrey’s other books, TSPSM–Leading a Development Team and PSPSM: A Self-Improvement Process for Software Engineers. Together, the three works offer a rich resource for improving your software development capabilities.

Read More Show Less

Product Details

  • ISBN-13: 9780201731132
  • Publisher: Addison-Wesley
  • Publication date: 4/14/2006
  • Series: SEI Series in Software Engineering Series
  • Edition description: New Edition
  • Pages: 448
  • Product dimensions: 6.55 (w) x 9.55 (h) x 1.26 (d)

Meet the Author

Known as “the father of software quality,” Watts S. Humphrey is the author of numerous influential books on the software-development process and software process improvement. Humphrey is a fellow of the Software Engineering Institute (SEI) at Carnegie Mellon University, where he founded the Software Process Program and provided the vision and early leadership for the original Capability Maturity Model (CMM). He also is the creator of the Personal Software Process (PSP) and Team Software Process (TSP). Recently, he was awarded the National Medal of Technology–the highest honor given by the president of the United States to America's leading innovators.

Read More Show Less

Table of Contents

Preface xv Part i: Team Formation 1Chapter 1: Development Teams 5

1.1. TSP Overview 5

1.2. Why Teams Are Needed 6

1.3. What Are Teams? 8

1.4. Kinds of Teams 9

1.5. The Nature of Self-Directed Teams 10

1.6. The Team Leader and Coach Roles 14

1.7. Coaching Workload 14

1.8. Summary 15 Chapter 2: Team Behavior 17

2.1. The Team Life Cycle 18

2.2. Kinds of Groups 22

2.3. Team Styles 25

2.4. Why Teams Fail 28

2.5. Summary 33 Chapter 3: The Coaching Job 35

3.1. Coaching Principles 35

3.2. Launching a TSP Team 37

3.3. Coaching the Team Members 38

3.4. Coaching Experienced Teams 39

3.5. Coaching the Team Leader 40

3.6. Coaching Management 46

3.7. Summary 47 Chapter 4: Teambuilding 49

4.1. What Makes Teams Successful? 49

4.2. Teambuilding Approaches 50

4.3. The TSP Teambuilding Strategy 51

4.4. How the Launch Builds Teams 51

4.5. Getting Involvement 55

4.6. Summary 63 Part Ii: Launching a TSP Team 65Chapter 5: Launch Preparation 67

5.1. When to Launch a Project 67

5.2. Team Scope 68

5.3. Team-Member Selection 70

5.4. Preparation Topics 71

5.5. Common Preparation Problems 75

5.6. Launch Preparation Steps 76

5.7. Weekly Launch Preparation Status Meeting 77

5.8. Summary 77 Chapter 6: The Team Charter 79

6.1. Establishing the Team Charter 80

6.2. The Opening Management Meeting 80

6.3. Start with a Positive Attitude 81

6.4. Issues and Considerations 82

6.5. Summary 83 Chapter 7: Team Goals 85

7.1. What Goals Are 85

7.2. The Importance of Feedback 87

7.3. Goal Priorities 87

7.4. Measurable Goals 88

7.5. Kinds of Goal Measures 89

7.6. The Problem with Measurements 91

7.7. Kinds of Goals 92

7.8. The TSPGoal-Setting Process 94

7.9. Goal Tracking 96

7.10. A Goal Measurement Example 97

7.11. Summary 98Chapter 8: Team-Member Roles 101

8.1. What Roles Are 101

8.2. Why Roles Are Needed 102

8.3. Selecting Team Roles 103

8.4. The TSP Roles 104

8.5. Other Team-Member Roles 110

8.6. Roles and Team Size 110

8.7. Coaching the Role Managers 112

8.8. The Role Manager Commitment 113

8.9. Summary 113Chapter 9: Team Planning 115

9.1. The TSP Planning Process 116

9.2. Launch Meeting 3 116

9.3. Product Conceptual Design 116

9.4. Team Strategy 118

9.5. The Products to Be Produced 121

9.6. The Development Process 121

9.7. Process and Support Plans 123

9.8. CCB Membership 124

9.9. Launch Meeting Documentation 124

9.10. Summary 124 Chapter 10: The Overall Plan 127

10.1. Launch Meeting 4 128

10.2. The Size Estimate 128

10.3. Determining Project Tasks 129

10.4. The Overall Resource Estimate 131

10.5. Resource Availability 131

10.6. Generating and Assessing the Overall Plan 132

10.7. Optimum Staffing 133

10.8. Summary 135 Chapter 11: The Quality Plan 137

11.1. The Importance of Quality 137

11.2. Quality Goals 139

11.3. The Cost of Defects 140

11.4. Measuring Software Quality 145

11.5. Percent Defect Free (PDF) 145

11.6. Making the Quality Plan 146

11.7. Summary 150 Chapter 12: Detailed Planning 153

12.1. How Far Out Should Teams Plan? 154

12.2. How Detailed Should Plans Be? 154

12.3. How Plans Can Improve Efficiency 155

12.4. Whether to Plan Now or to Plan Later 156

12.5. The Need for Balanced Plans 157

12.6. The TSP Detailed Planning Process 158

12.7. Summary 159 Chapter 13: Managing Risk 161

13.1. What Are Risks? 161

13.2. The Importance of Risk Management 162

13.3. The Principles of Risk Management 162

13.4. The TSP Risk Management Process 163

13.5. Risk Identification 163

13.6. Risk Evaluation 165

13.7. The Risk Evaluation Process 165

13.8. Assigning Risks 166

13.9. Risk Mitigation 166

13.10. Risk Management Examples 167

13.11. Risk Tracking and Management 168

13.12. Summary 169 Chapter 14: The Management Meeting 171

14.1. Preparing for the Management Meeting 172

14.2. Presenting the Team's Plan 173

14.3. Alternative Plans 174

14.4. Risks 174

14.5. Closing the Meeting 175

14.6. Presentation Suggestions 175

14.7. Summary 178 Chapter 15: The Launch Postmortem 181

15.1. The Postmortem Attitude 182

15.2. The Postmortem Process 184

15.3. Postmortem Coaching Strategies 186

15.4. Summary 187 Chapter 16: Relaunching a Team Project 189

16.1. What Is a Relaunch? 190

16.2. Why Do a Relaunch? 192

16.3. When to Relaunch 193

16.4. How to Do a Relaunch 195

16.5. The Relaunch Process 196

16.6. Revising the Quality Plan 200

16.7. A Quality Replanning Example 200

16.8. Concluding the Relaunch 204

16.9. Summary 204 Part IIi: Coaching a TSP Project 207Chapter 17: Post-Launch Coaching 209

17.1. Starting New Teams 210

17.2. The Coaching Process 210

17.3. The Post-Launch Briefing 210

17.4. The Weekly Team Meeting 211

17.5. The Daily Stand-Up Meeting 212

17.6. The Weekly Status Report 212

17.7. Coaching Inspections 214

17.8. Coaching Individuals 215

17.9. Coaching Role Managers 215

17.10. Coaching the Team Leader 216

17.11. The Project Notebook 217

17.12. The Team-Member Notebook 217

17.13. The Checkpoint Review 218

17.14. The Coaching Plan 220

17.15. Summary 223 Chapter 18: Maintaining the Plan 225

18.1. Plan Types 226

18.2. Plan Dynamics 227

18.3. Maintaining the Team's Plan 228

18.4. A Workload Imbalance Example 229

18.5. Facing Facts 231

18.6. When to Update the Plan 232

18.7. Updating Individual Plans 232

18.8. Dynamic Load Balancing 236

18.9. Interpreting Plan Data 237

18.10. Management Reporting 240

18.11. Summary 241 Chapter 19: Managing Quality 243

19.1. Principles of Quality Management 244

19.2. Why Manage Quality? 245

19.3. The Quality Journey 246

19.4. The Developer's Responsibility for Quality 247

19.5. The Team's Responsibility for Quality 248

19.6. Quality Management Methods 249

19.7. Interpreting Quality Data 259

19.8. Reporting Quality Data 261

19.9. Defect Reporting Considerations 266

19.10. Summary 267 Chapter 20: The Project Postmortem 269

20.1. The Purpose of the Postmortem 270

20.2. The Desired Data 270

20.3. Postmortem Preparation 272

20.4. The Postmortem Process 272

20.5. Teamwork Assessment 275

20.6. Coaching and Leadership Assessment 276

20.7. Coaching the Postmortem 276

20.8. The Team-Member Postmortem 277

20.9. Summary 278 Part Iv: TSP Extensions 279Chapter 21: Team Variations 281

21.1. Work Perspectives 282

21.2. Team Structure 285

21.3. Team Communication 286

21.4. Functional Teams 287

21.5. Distributed Teams 288

21.6. Multiple Teams 290

21.7. System-Wide Teams 291

21.8. Coaching Guidelines 292

21.9. Summary 293 Chapter 22: Functional Teams 295

22.1. Why Functional Teams Are Needed 296

22.2. The Functional-Team Strategy 296

22.3. Preparing for a Functional-Team Launch 298

22.4. Goal Setting 299

22.5. Launching Functional Teams 303

22.6. Coaching a Functional-Team Launch 308

22.7. Coaching a Functional Team 309

22.8. Summary 311 Chapter 23: Multiple Teams 313

23.1. What Is a Multi-Team? 314

23.2. The TSP Multi-Team Strategy 314

23.3. Forming a Multi-Team 315

23.4. The TSPm Launch Preparation Process 316

23.5. Launching a Multi-Team 321

23.6. Coaching a Multi-Team Launch 324

23.7. Launching a Distributed Multi-Team 325

23.8. Coaching Multi-Teams 328

23.9. Tracking and Reporting on Multi-Teams 330

23.10. Summary 330 Chapter 24: Integrated Development Teams 333

24.1. Process Principles for Large-Scale Teams 334

24.2. The Program-Initiation Team 339

24.3. The Program-Management Problem 341

24.4. Program Launching and Coaching Strategies 346

24.5. The Role-Manager Teams 347

24.6. Program Monitoring and Reporting 348

24.7. Summary 348 Part v: Maintaining a TSP Team 351Chapter 25: Developing Teamwork 353

25.1. Team-Member Communication 354

25.2. Principled Negotiation 357

25.3. The TSP Communication Strategy 358

25.4. Maintaining Team Communication 359

25.5. Process Discipline 361

25.6. Summary 364 Chapter 26: Coaching Ethics 365

26.1. The Coach's Responsibilities 366

26.2. The Coaching Commitment 367

26.3. Handling Team and Individual Data 370

26.4. Measuring People 373

26.5. Relating to Management 375

26.6. Handling Difficult Team Members 375

26.7. Summary 376 Chapter 27: The Coaching Team 379

27.1. Coaching in Organizations 379

27.2. Why Use a Coaching Team? 380

27.3. Forming a Coaching Team 381

27.4. Launching a Coaching Team 382

27.5. Managing and Tracking Coaching Teams 384

27.6. Coaching a Coaching Team 385

27.7. Being on a Coaching Team 385

27.8. Summary 386 Chapter 28: Being a Team Coach 387

28.1. Building Understanding and Motivation 388

28.2. Building a Coaching Team 388

28.3. Success Is Invisible 389

28.4. Reporting to Management 390

28.5. Coaching Yourself 393

28.6. Summary 396 Index 397

Read More Show Less


Teamwork is required for most development projects. Although some small jobs can be handled by individuals, the scale of modern systems is such and the demand for short schedules is so great, it is physically impossible for one person to do the entire job. Development work is a team activity, and the effectiveness of this teamwork largely determines the quality of the team’s work. The quality of the team’s work, in turn, largely determines the success of the entire project.

A team is more than just a group of people who happen to work together. Teamwork takes practice and it involves special skills. Teams require common processes and agreed-upon goals, they need effective leadership, and to be most effective, they must have coaching. Since development teams need as much guidance and support as any other kind of team, the Software Engineering Institute (SEI) has developed a framework and a process for building and guiding development teams. We call this the Team Software Process (TSP).1

While the book title refers to development teams, the material is much more general than this would suggest. Except for a few of the examples and some of the discussion about quality management, all of the material in this book can be applied to almost any kind of professional team. For example, the TSP process has been used by testing teams, for requirements work, by a senior management group to run a business, and to guide a process improvement effort.

In describing various coaching situations, I use many examples throughout the book. While I don’t name any organizations or people, these examples are all based on real situations with practicing TSP teams. These cases are drawn from the hundreds of teams the SEI has worked with while researching, developing, and deploying the TSP methods into industrial practice. It is my hope that, as more people gain experience coaching such development teams, they will publish their experiences and findings so that we can build the base of reference literature needed to properly grow and enrich the field of coaching for development teams.

Who Should Use This Book

This book is designed to be used by several kinds of readers. Senior managers and executives could find the four chapters in Part I a brief but complete overview of the issues involved in modern system development teamwork. Managers who are considering using the TSP to improve their development organizations should review Parts I and II. Those aspiring to be TSP coaches should read the entire book. It addresses many of the issues you will face in assembling and building development teams, in motivating and guiding these teams, and in helping the team leader and team members do superior work.

Even though the book’s principal focus is on TSP teams, knowledge of the TSP and Personal Software Process (PSP) is not required. The methods are quite general and can be understood without prior knowledge of any process or method. However, to gain full advantage of the methods described, it is suggested that you and your teams learn the PSP and use the full set of TSP process materials to guide the development work. You can get additional information on the PSP and TSP from SEI’s Web site (www.sei.cmu.edu/tsp).

What You Will Learn from This Book

In developing modern complex systems, any single mistake can have devastating consequences. Thus, everyone on the development team must do high-quality work. Such levels of consistently high performance are possible only with effective coaching and leadership. This book describes how to recognize quality work and how to guide teams in consistently doing such work. It also discusses how to recognize when the team’s work does not measure up and how to motivate the developers to improve.

The team coach monitors team performance and assists the team members to improve. This book also shows coaches how to cooperatively support the team leader and how to work with that leader to build, guide, and motivate the entire team.

The Contents of This Book

While a great deal could be said about teamwork in general, this book concentrates on the coach’s role in guiding a development team. It is organized in five parts.

Part I—Team Formation

The four chapters in Part I provide overall background and context for the entire book. The principal topics in Part I are development teams, team behavior, coaching principles and methods, and teambuilding. The sample LAU script in Chapter 4 illustrates TSP process concepts and methods. However, like all useful processes, the TSP process changes as we learn more about teams and as we evolve the TSP process to capitalize on this knowledge. Therefore, it is suggested that you get updated copies of the TSP scripts when you need them. For information about obtaining these scripts, contact the SEI or its transition partners (www.sei.cmu.edu/tsp).

Part II—Launching a TSP Team

Part II describes how the TSP builds effective, productive, self-directed development teams. Such teams are especially well suited for creative development work. The 12 chapters in Part II review the TSP launch process and suggest how to coach and support the team and team leader in conducting an efficient and effective team launch.

Part III—Coaching a TSP Project

Part III concerns guiding the team through the many problems commonly faced in doing development work. Its four chapters describe how to coach the team after the TSP launch and how the team can maintain its plan, manage quality, and conduct a project postmortem.

Part IV—TSP Extensions

There are many types of teams and it is important to adapt the TSP process to the particular project and team involved. The four chapters in Part IV discuss the issues of team type and size and explain how the TSP can be adapted to handle them. Functional teams typically support a functional activity such as product maintenance or system test. The developers in such teams typically work alone or in groups of two or three. Multiple and distributed TSP teams are used either for large projects or where a project includes multiple different disciplines like hardware, software, systems, or test. It is also used when the work is performed in multiple locations. Very large projects generally have unique needs and require customized processes. The final chapter in this section discusses ways to adapt the TSP to address the needs of very large integrated development projects.

Part V—Maintaining a TSP Team

The final four chapters of the book deal with the more subtle topics of teambuilding and the nature and rewards of coaching development teams.

TSP Prerequisites

Before developers can practice the TSP, they must be properly trained. They need to know how to plan and track their work, how to measure and manage quality, and how to follow a defined process. They must understand the importance of quality work, and they must have learned the discipline of recording their task time and the defects they inject and remove. These methods are all taught in the PSP course.2 Because there is so much material to cover, the PSP course is typically offered in universities at the senior or graduate level and it usually takes a full quarter or semester. The industrial PSP course requires about 100 to 120 hours of a developer’s time, generally spread over two weeks with some homework.

Although PSP training is intensive and takes considerable time, competent software professionals have no trouble completing it. Many developers receive PSP training during their college education and many others have been PSP trained by their organizations as part of TSP introduction. Since the PSP and TSP methods are language- and tool-independent, they have long-term value and can be used with any of the languages or tools that developers typically use. Many thousands of developers have now been PSP trained, and the data from these courses show that this training substantially improves their ability to deliver quality products on their planned schedules. The SEI has established a PSP certification program to assist organizations in identifying qualified PSP professionals.


1. Team Software Process and TSP are service marks of Carnegie Mellon University.
2. This course is described in the book PSPSM: A Self-Improvement Process for Software Engineers, Watts S. Humphrey, Addison-Wesley, 2005.

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted April 24, 2006

    extends earlier TSP book

    This book is a follow up on Humphrey's 2005 'TSP - Leading a Development Team'. There is an overlap. I was unable to draw a clear conceptual distinction between them. Though this Coaching book goes into more examples, carrying the coaching metaphor from sports a long way into the TSP development cycle. If you found the first TSP book to be helpful, then this book may be of further help, in part by fleshing out points raised in that book. Note though that there is certainly plenty of new material in Coaching. One example is an explanation of team styles, which was not covered earlier. Humphrey quotes Constantine as defining four types of styles - closed, open, random and synchronous. Of these, random may be the most interesting. It refers to a brainstorming approach, where the group meetings are deliberately chaotic, to encourage input from all members. If you want to make a new product that is qualitatively different from anything already existing, then this group style is the most likely to engender genuinely innovative results. The other group styles are perhaps better suited to a kaizen type situation, where you are making incremental improvements in an existing product.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)