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.
Notes:
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.
