© 2010 Carnegie Mellon University Team Software Process

2 © 2010 Carnegie Mellon University Team Software Process (TSP) The TSP is a process-focused strategy for helping organization’s improve their ability to produce high- quality software to committed costs and schedules. TSP improves organizational performance by improving individual and project team performance. The TSP deployment strategy works on a single project or an entire organization. each project has immediate measurable benefits each project fully recovers the investment in 3 to 6 months

3 Team Software Process © 2010 Carnegie Mellon University TSP – A Process for Teams TSP is a process that is specifically designed for software teams. It’s purpose is to help teams plan their work negotiate their commitments with management manage and track projects to a successful conclusion produce quality products in less time achieve their best performance without the “death march” ending

4 Team Software Process © 2010 Carnegie Mellon University Team Software Process Benefits Unlike other solutions, the TSP uses a self-directed team management style with a coaching model to build high-performance teams that routinely meet planned commitments. includes comprehensive quality management practices that dramatically reduce testing and development costs. is a tactical solution to improvement that can be deployed in weeks, not months or years. is a fully operational approach with all of the processes, measures, training, and tools needed for deployment. adapts to existing practice rather than replacing it.

5 Team Software Process © 2010 Carnegie Mellon University TSP Cost and Schedule Performance Summary Project cost and schedule predictability improvements are dramatic. Typical team results: all planned functionality delivered cost and schedule variance is within +/-10% variance is reduced and error is balanced around zero Sources: CMU/SEI-TR ; CMU/SEI-TR

6 Team Software Process © 2010 Carnegie Mellon University TSP Improves Product and Process Quality Delivered product quality is among the best in the industry. From a study of 20+ projects in 13 organizations: Average post-release defects was 60 per million lines of new and modified code. One-third of the products from this study were defect free for at least the first six months These results compare favorably with published results at all maturity levels. Sources: CMU/SEI-TR ; CMU/SEI-TR

7 Team Software Process © 2010 Carnegie Mellon University Improved Quality Reduces Rework The cost and duration of system test are reduced by eliminating rework and avoiding the typical software “test-in quality” strategy.

8 Team Software Process © 2010 Carnegie Mellon University TSP Improves Productivity All organizations report improvements in productivity or cycle time. Examples include Intuit, Northrop Grumman, Allied Signal, Teradyne. 1,2 Increases in the range of 25% to 40% were common. 1. CMU/SEI-TR CMU/SEI-TR

9 Team Software Process © 2010 Carnegie Mellon University TSP Meets the Needs of Both Managers and Developers Source: CMU/SEI-TR

10 Team Software Process © 2010 Carnegie Mellon University TSP is a Software Engineering Best Practice 1. Software Engineering Best Practices, C. Jones, 2010 Start Size Methods 1)Agile 2)TSP/PSP 3)Waterfall 4)CMMI 1, 2 Methods 1)Agile 2)TSP/PSP 3)Waterfall 4)CMMI 1, 2 Methods 1)TSP/PSP 2)Agile 3)CMMI 3 4)RUP Methods 1)TSP/PSP 2)Agile 3)CMMI 3 4)RUP Methods 1)TSP/PSP 2)CMMI 3, 4, 5 3)RUP 4)Hybrid Methods 1)TSP/PSP 2)CMMI 3, 4, 5 3)RUP 4)Hybrid SmallLargeMedium Development practices by size of application [1]

11 Team Software Process © 2010 Carnegie Mellon University TSP Implements CMMI -1 Unrated - out of scope for TSP. Not addressed - project practice that TSP does not cover. Partially addressed - project practices that TSP addresses with some weakness of omission Supported - organizational practices that TSP supports. Directly Addressed - TSP practices meet the intent of the CMMI specific practice (SP) without significant reservations. Based on a SCAMPI C of the latest version of TSP

12 Team Software Process © 2010 Carnegie Mellon University TSP Implements CMMI -2 TSP has implements most CMMI v1.2 specific practices. 85% of SPs at ML2 78% of SPs at ML3 54% of SPs at ML4 25% of SPs at ML5 80% of ML2 and ML3 SPs 75% of SPs through ML5 Most generic practices are also addressed except for GP2.1 Based on a SCAMPI C of the latest version of TSP

13 Team Software Process © 2010 Carnegie Mellon University Complete Product: Process, Measures, Training, Tools Process Notebook Process scripts Forms Guidelines and standards Training and Textbooks Executives Project Managers Engineering TSP Coach TSP Trainers Tools TSP Workbook PSP Workbook Coach/Trainer Workbook

14 Team Software Process © 2010 Carnegie Mellon University Getting Started TSP has a team-based improvement strategy and is introduced on a project- by-project or team-by-team basis Like any change management activity TSP requires sponsorship and planning. Start with two or three teams. Train senior management, project management, and the team members. Launch these teams with TSP. Gather data, evaluate the results, and fine tune the approach. Repeat on several more teams, increasing scope at a sustainable pace. For full deployment organizations should develop their own internal capability. SEI-authorized trainers SEI-certified TSP coaches

15 Team Software Process © 2010 Carnegie Mellon University TSP Deployment Timeline TaskJanFebMarAprMayJunJulAugSepOctNovDec Training Phase TSP Executive Strategy Seminar Leading Development Teams PSP Fundamentals ♦♦♦♦♦♦ Launch Initial pilot projects Launch and re-launch teams every 1 to 3 months. ♦♦♦♦ ♦♦♦♦ ♦♦♦♦ Evaluate and fine tune the approach Train internal TSP Coaches/instructors ♦♦ Train and launch additional projects and teams at a pace set by the organization.

16 Team Software Process © 2010 Carnegie Mellon University Organizations Using TSP

17 Team Software Process © 2010 Carnegie Mellon University TSP at Microsoft TSP was initially introduced in Microsoft IT to address a work-life balance issue. Schedule and quality issues were affecting morale. Within one year morale was improved and these problems were resolved. An internal study reported that first-time TSP projects at Microsoft had a 10 times better mean schedule error than non-TSP projects. Equally important, TSP teams met their commitments without the “death march”. Microsoft Schedule Results Projects not using TSP TSP Projects Released on Time42%66% Average Days Late256 Mean Schedule Error10%1% Sample Size8015 Source: Microsoft

18 Team Software Process © 2010 Carnegie Mellon University TSP Quality Improvements at Microsoft Background information two consecutive releases of the same system same six month schedule same seven member team similar functionality produced TSP used on release 2.5 Post code complete defects Phase Version 2.4 Version 2.5 Integration Test 2374 System Test47310 User Acceptance Test 1533 Total107217

19 Team Software Process © 2010 Carnegie Mellon University Quality and Productivity Improvements at Intuit From data on over 40 TSP teams, Intuit has found that sixty percent fewer defects after code-complete post code-complete effort is 8% instead of 33% of the project standard test times are cut from 4 months to 1 month or less Development Test Non-TSP TSP Source: Intuit

20 Team Software Process © 2010 Carnegie Mellon University Work-Life Balance at Intuit Finding and retaining good people is critical to long-term success. Intuit found that TSP improved work-life balance, a key factor in job satisfaction. Source: Intuit

21 Team Software Process © 2010 Carnegie Mellon University Impact of TSP at Adobe

22 Team Software Process © 2010 Carnegie Mellon University TSP Quality Improvements at Adobe

23 Team Software Process © 2010 Carnegie Mellon University Contact Information For more information: Edgar Fernández, TSP Coach

24 Team Software Process © 2010 Carnegie Mellon University NO WARRANTY THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. Use of any trademarks in this presentation is not intended in any way to infringe on the rights of the trademark holder. This Presentation may be reproduced in its entirety, without modification, and freely distributed in written or electronic form without requesting formal permission. Permission is required for any other use. Requests for permission should be directed to the Software Engineering Institute at This work was created in the performance of Federal Government Contract Number FA C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The Government of the United States has a royalty-free government-purpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or permit others to do so, for government purposes pursuant to the copyright license under the clause at