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.