Software Process Improvement: Team Software Process
Author: Brian Jarvis
September 2007
In his presentation “Using the Team Software ProcessSM (TSPSM) to Improve Performance,” Mr. Tim Chick provided an overview of key lessons learned in implementing and using the TSP for software or systems engineering. Mr. Chick is a Sr. Member of the Technical Staff at the Software Engineering Institute (SEISM) at Carnegie Mellon University.
Mr. Chick described the TSP as a process for high-performance engineering teams that produce software or software-intensive systems to ensure the quality of their product and to improve the process management of the organization.
TSP leverages off of the Personal Software ProcessSM (PSPSM), a process that helps software engineers build the skills necessary to improve estimates, meet commitments, reduce defects, and improve product quality. With its operational processes and measures, TSP is applicable to a broad range of applications and yet is easily integrated with an organization’s existing processes. A few basic principles that shape the design of TSP are 1) self-directed teams do the best work, 2) early defect removal is a cornerstone of a high-quality process, 3) processes must be measured to be managed and improved, 4) quality without numbers is just talk, and 5) TSP is introduced top-down but must be implemented from bottom-up.
TSP includes a well-defined structured process for planning, defined as the “TSP Launch.” Typically 3-4 months long, this process is used to plan the project, with each project cycle ending with a post-mortem and another “mini-launch” held to plan the next cycle. The post-mortem provides feedback to guide the rest of the project. TSP depends on data (e.g., time, defects, size, schedule, yield) collected by individuals on their own performance. A TSP Tool is used to both collect the data and to manage the project. (SEI offers an Excel tool to collect the data and manage the project.)
TSP has been found to accelerate CMMI®-based improvement due to the quality of products developed on cost and schedule as a result of the improved individual skills and discipline developed by the PSP. TSP shows how to change the day-to-day behavior of individuals, project teams, and the organization. Together, TSP and PSP provide a model for closed-loop corrective action at the individual and team levels.
Examples of TSP results on a number of programs and initiatives were provided: E-2C, AV-8B, P3-C, NAVAIR, and Level 5 (Continuous Improvement).
TSP and the people side of change were described, providing details of the typical reactions to change by software engineering professionals. These discussions included conscious and unconscious realizations of competence, the transition of self-confidence over time, reactions to change, managing change, and the impacts on TSP (or any process improvement approach) of not managing change.
In closing, Mr. Chick provided recommendations on getting TSP started at an organization, various TSP Introduction Strategies, and a description of the TSP Product Suite,
® CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University
SM SEI, Team Software Process, TSP, Personal Software Process, and PSP are service marks of Carnegie Mellon University
Primary Dayton SPIN Contact: Dave Malas
For more information regarding TSP contact: Mr. Tim Chick at
This e-mail address is being protected from spambots. You need JavaScript enabled to view it
.
