What is the payback period?
Most of the cost of introducing PSP/TSP is incurred on a project by project basis, so introduction costs can be managed on a project by project basis. The most significant cost is lost opportunity due to a one-time training cost of about 12 days per developer.
Any project of at least four months duration will pay for the cost of training the team. Once a developer has written about 1500 lines of code or equivalent, he or she will recover the training cost through improved productivity and fewer test defects.
What are the benefits of using the TSP?
The most significant benefit is improved productivity and/or schedule reduction resulting from early defect removal and improved planning and tracking. Early defect removal (a) reduces average time to remove a defect from hours to minutes, (b) reduces testing costs/schedules by 20% to 48%, (c) increases the non-test costs/schedules by 5% to 10%, and (d) yields net average savings of about 25%. Improved planning and tracking increases task hours per week by up to 50%. Task hour increases translate directly to productivity increases.
Beyond the benefits of productivity, team members generally enjoy their work much more when working in the TSP environment.
Isn't TSP hard to implement?
The TSP introduction strategy is based on years of experience in process improvement and organizational change. The transition strategy, the role-based training and textbooks, the mentoring and support, were all designed to simplify introduction and reduce resistance to change.
How will the TSP help staff do their jobs every day?
PSP/TSP changes the behavior of software developers. They plan their work, gather data, use the data for tracking and improvement, and manage the quality of the products they produce. As a consequence they are in control of their work and have a strong sense of empowerment, know where they stand and can defend their plans and status, and produce software of extremely high-quality and can take pride in what they built and how they built it. TSP may be the best antidote for “Death March Projects.”
How does the TSP help managers?
TSP implements a self-directed team approach to software development. The team makes their own commitments and are accountable for them. The recommended management style is a fact-based, rational management approach that relies on coaching to guide the team and involves observation, analysis, and mentoring using data. Although it involves just as much work for the manager, the results are consistently better and more rewarding.
I’m sold on TSP, but I need some data to use to convince my managers. Do you have anything that might help?
An SEI report, The Team Software Process (TSP) in Practice: A Summary of Recent Results, provides results and implementation data from projects and individuals that have adopted the TSP.
If you have access to the PSP/TSP area of the Software Engineering Information Repository (SEIR), you can read John Stark’s presentation titled Using Scrum to Enable TSP.
Also, the National Institute of Standards & Technology (NIST) had a study done for them in 2002 by the Research Triangle Institute on the costs of inadequate software testing. The study includes estimates of the dollar savings possible if all defects were detected in the same phase in which they were introduced, based on survey data from the aerospace and financial services industries. It also includes estimates of the savings possible from what they call “feasible improvement” in the percentage of defects found in the stage introduced.
Finally, perhaps the best way to convince someone is to have them contact someone else they respect. Contact the SEI for the latest set of references.