© 2010 carnegie mellon university team software process

© 2010 Carnegie Mellon University

Team Software Process

2Team Software Process


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



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



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.



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

Effort Deviation Range

-40%

-20%

0%

20%

40%

60%

80%

100%

Pre-TSP With TSP

Pe

rce

nt

Err

or

Schedule Deviation Range

-20%

0%

20%

40%

60%

80%

100%

120%

Pre-TSP With TSP

Pe

rce

nt

Err

or

Sources: CMU/SEI-TR-2000-015; CMU/SEI-TR-2003-014



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.

7.5

6.24

4.73

2.28

1.05

0.060

1

2

3

4

5

6

7

8

Level 1 Level 2 Level 3 Level 4 Level 5 TSP

Defects/KLOC

Sources: CMU/SEI-TR-2000-015; CMU/SEI-TR-2003-014



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.



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-2000-015

2. CMU/SEI-TR-2003-014



TSP Meets the Needs of Both Managers and Developers

Source: CMU/SEI-TR-2003-014



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) TSP/PSP

2) Agile

3) CMMI 3

4) RUP

Methods

1) TSP/PSP2) CMMI 3, 4,

5

3) RUP

4) Hybrid

Small LargeMedium

Development practices by size of application[1]



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.

CMMI Process Categories

0%

25%

50%

75%

100%

Process Category

Perc

enta

ge o

f SPs Unrated

Not Addressed

Partially Addressed

Supported

Directly Addressed

Based on a SCAMPI C of the latest version of TSP



TSP Implements CMMI -2

TSP has implements most CMMI v1.2 specific practices.

• 85% of SPs at ML2




• 80% of ML2 and ML3 SPs

• 75% of SPs through ML5

Most generic practices are also addressed except for GP2.1

0%

20%

40%

60%

80%

100%

Level 2 Level 3 Level 4 Level 5 All Levels

CMMI Maturity Level

Perc

enta

ge o

f SP

s

Based on a SCAMPI C of the latest version of TSP



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



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



TSP Deployment Timeline

Task Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec

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.



Organizations Using TSP



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 Time 42% 66%

Average Days Late 25 6

Mean Schedule Error 10% 1%

Sample Size 80 15

Source: Microsoft



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 237 4

System Test 473 10

User Acceptance

Test153 3

Total 1072 17



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

Development Test

Test Non-TSP

TSP

Source: Intuit



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

Source: Intuit



Impact of TSP at Adobe



TSP Quality Improvements at Adobe



Contact Information

For more information:

• Edgar Fernández, TSP Coach [email protected]+52 492 111 7915

mailto:[email protected]



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 [email protected].

This work was created in the performance of Federal Government Contract Number FA8721-05-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 252.227-7013.

mailto:[email protected]

© 2010 carnegie mellon university team software process

Documents

process quality

software teams

project team performance

teams tsp

high quality software

typical team results

processfocused strategy

typical software test