BN.com Gift Guide

TSP(SM): Leading a Development Team / Edition 1

Hardcover (Print)
Buy Used
Buy Used from BN.com
$38.23
Used and New from Other Sellers
Used and New from Other Sellers
from $8.60
Usually ships in 1-2 business days
(Save 86%)
Other sellers (Hardcover)
  • All (15) from $8.60   
  • New (4) from $46.94   
  • Used (11) from $8.60   

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.

Read More Show Less

Product Details

  • ISBN-13: 9780321349620
  • Publisher: Addison-Wesley
  • Publication date: 9/9/2005
  • Series: SEI Series in Software Engineering Series
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 336
  • Product dimensions: 6.32 (w) x 11.66 (h) x 1.02 (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

Read an Excerpt

In the fifty-plus years since I started doing development work, I have worked on, led, managed, directed, assessed, or coached literally hundreds of creative development teams. While I have drawn many lessons and guidelines from this experience, the one clearest message is that leadership makes the greatest difference. Without exception, truly creative work is done by teams with very capable leaders. What is most interesting, however, is that these great leaders are generally ordinary developers like you and me, but when thrust into a leadership position, they do an outstanding job.

What is equally interesting is the converse. When development projects fail, it is almost always because of poor leadership. In this book, I describe the differences between an ineffective leader and one who does a superb job. The objective is to help you understand, anticipate, and correct the most common leadership failings before they cause you or your team problems. I wrote this book because I have seen many smart and dedicated developers make basic leadership mistakes. This is a shame, because it is totally unnecessary. Leadership is not a complex subject and anyone can be a great leader.

When I was first made team leader, I had just joined a development group at my first job and did not know any of the team members or have the vaguest idea what they were doing or why. I didn't even understand the organization or the technology. While things worked out well in the end, it was due more to the marvelous people on my team than to any special insight or skill on my part.

However, I have found that this is not unusual. Given half a chance, your people will be very helpful, even when you are the new boss and they know much more about the job than you do. While there will be occasional exceptions, people want to like and respect you and they want you to succeed. They will tolerate your dumb questions and silly mistakes as long as you are willing to admit your mistakes and laugh at your goofs. Be honest about what you know and don't know, and assume that management had a good reason to make you the team leader.

After I had worked for a few years, I was asked to lead a larger group in another department. I knew the people pretty well and also knew a great deal about the job. This time, however, my reception was not nearly as smooth. One of the more experienced members of the new group was older than I, and he and several team members thought that he should have been the team leader instead. While this situation took a bit longer to straighten out, the team finally came to terms with my new role and we established a good and productive working relationship.

The way teams perform depends to a great extent on how they relate to their leadership. However, I have found that the way your team relates to you will depend on a host of factors, many of which you can influence but some you cannot. In this book, I describe these factors and suggest ways to deal with them. These guidelines have helped me and I hope they will help you.

Who This Book Is ForThis book is for people who are now leading or would like to lead a development team. It describes the team leader's job, the essential elements of leadership, and the many issues and problems you are likely to face. While I can't pretend to have all of the answers, I have had a lot of experience leading teams, and I have worked with a great many teams and team leaders. Since every team is different, and most teams grow and evolve over time, there is no magic formula for being an effective leader. However, there are some principles and guidelines. Whether you are a new or an experienced team leader, this book discusses many of the issues you will likely face and has examples, guidelines, and suggestions on how to handle them. It summarizes my observations and experiences in a form that will help you to address almost any kind of team and team leadership situation. The Kinds of Teams AddressedWhile there are many kinds of teams, this book concerns leading development teams. A lot has been written about sports, military, and production teams, but little material is available on development teams and even less is written about leading such teams. Since many of the teams I have worked with have had leadership problems, I have concluded that this book is needed. My intent is to talk about leading any kind of development team, but most of my recent work has concerned teams that were developing software-intensive systems. Therefore, my examples and much of the process discussion concerns these types of teams. In my work at the Software Engineering Institute (SEI) at Carnegie Mellon University, we have developed the Team Software Process (TSP). As the name implies, this process is designed to guide software development teams. The TSP has been used by many teams that included hardware, software, systems, requirements, test, and other professionals. It has also been used by some teams that have done little or no software development. So while the book mentions TSP in many places, you will find that the concepts and much of the guidance applies to any kind of development team. Few things that are worthwhile are free, however, and your people will need new skills to use the TSP. These skills are taught in Personal Software Process (PSP) training.How This Book Is Organized

The five parts of this book address the principal aspects of teams and team leadership. Part I discusses what management and the team expect from you. It then describes the conditions for team success and the kinds of teams needed to do development work. Following the discussion of what and why in Part I, Parts II through V and the appendices deal with how: how to do what it takes to be a great leader.

Part II starts with a brief overview of the Team Software Process and how it can help you to build the kind of team you need, even if your team doesn't do software development or even any kind of development. It then describes how to form teams and the TSP launch process. Part III discusses teamworking. It concerns following the plan, maintaining focus, and following the process to produce a quality product. Part IV discusses management reporting, project reviews, and your obligation to support and protect your team. Part V concludes the book with a description of how to develop the team and its members and how to best capitalize on your capabilities and your team's capabilities. The book's appendices then provide more detail on the TSP team roles and how to use them. They also discuss the communication and command networks in your organization and how to use them to accomplish your team's objectives.

Read More Show Less

Table of Contents

Preface.

I. INTRODUCTION.

1. The Team Leader.

What Management Expects

What the Team Expects

Management Priorities Versus Team Interests

The Team's Goals

Setting an Example

Standards

The Leadership Attitude

Taking Responsibility

The Team Leader's Job

Summary

2. Leadership.

Leadership Problems

Symptoms of Poor Leadership

The Fundamental Leadership Problem

Leading Versus Managing

Leaders Have Followers

The Leader's Vision and Commitment

The Leadership Attitude

Transformational and Transactional Leadership

Becoming a Leader

Acting Like a Leader

Leading from Below

Summary

3. Teams.

What Is a Team?

The Power of Teams

Why Teams Are Needed

The Nature of Self-Directed Teams

Membership and Belonging

Commitment to a Common Goal

Owning the Process and Plan

Skill and Discipline

A Dedication to Excellence

The Need for Leadership

Summary

4. Team Motivation.

What Is Motivation?

Goals and Motivation

Feedback

Sustaining Motivation

Motivation and the Job

Kinds of Motivation

Commitment

Building Motivation

Sustaining Motivation

Summary

II. BUILDING TEAMS.

5. TSP Overview.

The Team Leader's Objectives

Meeting the Team Leader's Objectives

Forming the Team

Launching the Team

Teamwork

Training

Team Ownership

Summary

6. Team Formation.

The Selection Process

Inheriting Formed Teams

Selection Criteria

Training

Team Players

Potential Leaders

Summary

7. The TSP Team Launch.

Launch Objectives

Teambuilding

TSP Launch Overview

Launch Support

Launch Preparation

Leading a TSP Launch

Summary

III. TEAMWORKING.

8. Managing to the Plan.

Following the Plan

The First Crisis

Dynamic Planning

Changing Requirements

Maintaining the Plan

Workload Balancing

Tracking Progress

Assessing Status

Getting Help

Summary

9. Maintaining Product Focus.

Defining Success

Setting and Maintaining Priorities

Establishing Short-Term Goals

Overcoming Obstacles

Changing Direction

Involving the Customer

Summary

10. Following the Process.

Why It Is Important to Follow the Process

The Logic for the PSP

The Logic for the TSP

Why It Is Hard to Follow a Process

Starting to Use the Process

Gathering and Recording Data

Handling Process Problems

Data-Related Problems

Motivating Teams to Follow Their Defined Processes

The Benefits of Following the Process

Summary

11. Managing Quality.

What Is Quality?

Why Is Quality Important?

Why Manage Quality?

The Principles of Quality Management

The Quality Journey

The TSP Quality Strategy

Gathering Quality Data

The Developer's Responsibility for Quality

The Team's Responsibility for Quality

Quality Management Methods

Quality Reporting Considerations

Quality Reviews

Summary

IV. RELATING TO MANAGEMENT.

12. Management Support.

Management Resistance

Project Control

Inadequate Resources

PSP Training

Networking

Defining Team Goals

Team Planning

Summary

13. Reporting to Management.

The Logic for Reporting

What to Report

Report Contents

When to Report

A Report Example

Asking for Help

Summary

14. Protecting the Team.

The Manager's Job

Handling Requests

Frequent Changes

Staffing

Training

Workspace

Data Confidentiality

Balancing Priorities

Summary

V. MAINTAINING THE TEAM.

15. Developing the Team.

Assessing the Team

Team Membership

Team Goals

Team Ownership

Team Planning

The Team Quality Commitment

Summary

16. Developing Team Members.

Interests, Competence, and Motivation

Challenging Work

Task and Relationship Maturity

Measuring and Evaluating People

Handling Difficult Team Members

Handling Poor Performers

Summary

17. Improving Team Performance.

Motivating Improvement

Improvement Goals

Improvement Strategy and Process

Improvement Plans and Resources

Improvement Measures and Feedback

The Elements of Benchmarking

Benchmark Measures

Dynamic Benchmarking

Benchmarking Yourself

Summary

18. Being a Team Leader.

What Is Leadership?

Being a Leader or a Manager

The Leadership Role

Coaching While Leading

The Challenges Ahead

Summary

Appendix A: Team Roles.

What Roles Are

Why Roles Are Needed

Assigning Role Responsibilities

The TSP Team-Member Roles

Other Team-Member Roles

Selecting Team Roles

Coaching the Role Managers

Role Manager Responsibilities

Summary

Appendix B: Networking.

Organizational Networks

Executive Style

Working with the Coach

Working with the SEPG

Quality Assurance

Configuration Management

Independent Testing

Staff and Support Groups

Multi-Team Networks

Summary

Index.

Read More Show Less

Preface

In the fifty-plus years since I started doing development work, I have worked on, led, managed, directed, assessed, or coached literally hundreds of creative development teams. While I have drawn many lessons and guidelines from this experience, the one clearest message is that leadership makes the greatest difference. Without exception, truly creative work is done by teams with very capable leaders. What is most interesting, however, is that these great leaders are generally ordinary developers like you and me, but when thrust into a leadership position, they do an outstanding job.

What is equally interesting is the converse. When development projects fail, it is almost always because of poor leadership. In this book, I describe the differences between an ineffective leader and one who does a superb job. The objective is to help you understand, anticipate, and correct the most common leadership failings before they cause you or your team problems. I wrote this book because I have seen many smart and dedicated developers make basic leadership mistakes. This is a shame, because it is totally unnecessary. Leadership is not a complex subject and anyone can be a great leader.

When I was first made team leader, I had just joined a development group at my first job and did not know any of the team members or have the vaguest idea what they were doing or why. I didn't even understand the organization or the technology. While things worked out well in the end, it was due more to the marvelous people on my team than to any special insight or skill on my part.

However, I have found that this is not unusual. Given half a chance, your people will be very helpful, even when you are the new boss and they know much more about the job than you do. While there will be occasional exceptions, people want to like and respect you and they want you to succeed. They will tolerate your dumb questions and silly mistakes as long as you are willing to admit your mistakes and laugh at your goofs. Be honest about what you know and don't know, and assume that management had a good reason to make you the team leader.

After I had worked for a few years, I was asked to lead a larger group in another department. I knew the people pretty well and also knew a great deal about the job. This time, however, my reception was not nearly as smooth. One of the more experienced members of the new group was older than I, and he and several team members thought that he should have been the team leader instead. While this situation took a bit longer to straighten out, the team finally came to terms with my new role and we established a good and productive working relationship.

The way teams perform depends to a great extent on how they relate to their leadership. However, I have found that the way your team relates to you will depend on a host of factors, many of which you can influence but some you cannot. In this book, I describe these factors and suggest ways to deal with them. These guidelines have helped me and I hope they will help you.

Who This Book Is For

This book is for people who are now leading or would like to lead a development team. It describes the team leader's job, the essential elements of leadership, and the many issues and problems you are likely to face. While I can't pretend to have all of the answers, I have had a lot of experience leading teams, and I have worked with a great many teams and team leaders. Since every team is different, and most teams grow and evolve over time, there is no magic formula for being an effective leader. However, there are some principles and guidelines. Whether you are a new or an experienced team leader, this book discusses many of the issues you will likely face and has examples, guidelines, and suggestions on how to handle them. It summarizes my observations and experiences in a form that will help you to address almost any kind of team and team leadership situation.

The Kinds of Teams Addressed

While there are many kinds of teams, this book concerns leading development teams. A lot has been written about sports, military, and production teams, but little material is available on development teams and even less is written about leading such teams. Since many of the teams I have worked with have had leadership problems, I have concluded that this book is needed. My intent is to talk about leading any kind of development team, but most of my recent work has concerned teams that were developing software-intensive systems. Therefore, my examples and much of the process discussion concerns these types of teams. In my work at the Software Engineering Institute (SEI) at Carnegie Mellon University, we have developed the Team Software Process (TSP). As the name implies, this process is designed to guide software development teams. The TSP has been used by many teams that included hardware, software, systems, requirements, test, and other professionals. It has also been used by some teams that have done little or no software development. So while the book mentions TSP in many places, you will find that the concepts and much of the guidance applies to any kind of development team. Few things that are worthwhile are free, however, and your people will need new skills to use the TSP. These skills are taught in Personal Software Process (PSP) training.

How This Book Is Organized

The five parts of this book address the principal aspects of teams and team leadership. Part I discusses what management and the team expect from you. It then describes the conditions for team success and the kinds of teams needed to do development work. Following the discussion of what and why in Part I, Parts II through V and the appendices deal with how: how to do what it takes to be a great leader.

Part II starts with a brief overview of the Team Software Process and how it can help you to build the kind of team you need, even if your team doesn't do software development or even any kind of development. It then describes how to form teams and the TSP launch process. Part III discusses teamworking. It concerns following the plan, maintaining focus, and following the process to produce a quality product. Part IV discusses management reporting, project reviews, and your obligation to support and protect your team. Part V concludes the book with a description of how to develop the team and its members and how to best capitalize on your capabilities and your team's capabilities. The book's appendices then provide more detail on the TSP team roles and how to use them. They also discuss the communication and command networks in your organization and how to use them to accomplish your team's objectives.

Read More Show Less

Customer Reviews

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

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

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

Reminder:

  • - 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 November 30, 2005

    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.

    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)