XP, SCRUM, and the TSP are processes designed for
relatively small software development teams.
XP and SCRUM are Agile methods
The TSP was created by the SEI
Any of these methods have situations in which they
may be applicable.
All of these methods incorporate the concept of self‐
XP SCRUM TSP
Management/ Tracker Scrum Master Team Leader
Leadership Coach Planning Manager
Business Analysts Customer Product Owner Customer Interface
Development Developer Team Member Engineer
Quality Customer Product Owner Quality Manager
Assurance Process Manager
Other Senior Support Manager
Roles – Extreme Programming
Customer – end user or representative (for example, a
Business Analyst or Product Manager for commercial
software product development)
Developer – technical team member, generally no
specialized roles such as DBAs or HTML vs. Java
Tracker – functions as the project manager
Coach – Technical/Process mentor
Roles ‐ SCRUM
Scrum Master – a project manager type role
Product Owner – similar to XP customer role
Team Member – again generalized, like XP
Roles ‐ TSP
Team Leader – General management
Implementation Manager – Technical manager
Customer Interface Manager – Responsible for requirements
and customer communications
Planning Manager – Project management
Design Manager – an “Architect” type role
Test Manager – Test planning, coordinates testing process
Quality Manager ‐ Software Quality Assurance, coordinates
Process Manager ‐ Process Quality Assurance/Improvement
Support Manager – Configuration manager, “tool master”
Engineers – Developers, again generalized
Practices – Extreme Programming
Pair Programming (continuous reviews)
The Planning Game (user stories, story points, project velocity)
Test‐driven development (test cases as requirements)
Whole team (onsite customer, co‐located team)
Design Improvement (refactoring)
Small Releases (~2 week iterations, ~quarterly releases)
Collective Code Ownership
Simple Design (YAGNI)
Sustainable Pace (previously named “40 hour workweek”)
Practices ‐ SCRUM
Product Backlog (product inventory)
Sprint Planning Meetings (Story points, Sprint Plan)
Sprint Backlog (to‐do list)
Daily Scrum (stand‐up meeting)
Demo (post‐sprint review, of working, tested
“Definition of Done”
Retrospective (lessons learned)
Team sits together (co‐location)
Practices ‐ TSP
Scripts (brief process descriptions)
More traditional approach to requirements, design,
and implementation, and testing
Emphasis on Measurement (Time, Cost, Defects)
Reviews and Inspections
Teamwork/Team Building built in to process
Estimates are in LOC or using a proxy‐based method
The Big Picture
“Process Risk” increases as move along the continuum
from traditional software development to XP.
Scrum and Extreme Programming require more
personal discipline in order to be successful, as there
are fewer checks and balances built into the process.
Although SCRUM and XP are complete SDLCs, there
are few project artifacts other than the code and
automated test cases to use as evidence.
The Big Picture ‐ continued
Differing Approaches to Change:
XP – Since change is cheap, ANYTHING can change, at
SCRUM – Changes will happen frequently, but Sprint
contents are fixed.
TSP – Changes will be managed
“Traditional” – Change is expensive
The bottom line ‐ while any individual change may be
cheap, don’t make up for it with volume!
The Big Picture ‐ Continued
Differing Approaches to Communication
Agile (SCRUM, XP)
Collaborative Environment (“Circle of Trust”)
Much of project communications are interpersonal
However, necessary artifacts are retained in written form
Data is collected on a continuous basis (hopefully automated)
Long‐Distance (especially customer communication)
Large Documents and Many Forms
Can be Confrontational (especially when a contract is involved)
Some Humorous Quotes
“75% of those organizations using Scrum will not
succeed in getting the benefits they hoped for from it”
(Ken Schwaber, one of the creators of Scrum)
"XP is like a ring of poisonous snakes, daisy‐chained
together. All it takes is for one of them to wriggle
loose, and you've got a very angry, poisonous snake
heading your way." ("The Case Against Extreme
Programming: A Self‐Referential Safety Net")
When practicing XP, be sure to document your
requirements (and don’t rip them up when coded)
If you’re going to do pair programming, be sure to do
it all the time (a one‐line change has a 50% chance of
injecting a new defect, per Weinberg)
For SCRUM and XP, you may need to have more than
one customer representative, to be able to handle all
of the requirements and testing work.
SCRUM and XP require stable, co‐located teams.
If your engineers don’t like collecting data, the TSP
will be a tough sell.
For internal, departmental projects, either XP or
SCRUM may be OK.
For internal, cross‐departmental projects, XP or
SCRUM may be OK if there is buy‐in from all involved
For projects with an external customer, be wary of
using XP or SCRUM if a contract is involved.
For commercial software projects, TSP is
recommended over SCRUM and XP
The TSP is always a viable option (the organization
needs to ensure that engineers are properly trained)
Agile methods have their time and place.
Pure “eXtreme Programming” as it was originally
described is rarely practiced today.
SCRUM can be a viable process, although not as
rigorous as the TSP.
The TSP has a steeper learning curve, but provides
greater transparency into the process for stakeholders
outside of the team.
Introduction to the Team Software Process, Watts S.
"Kill That Code!", IEEE Tutorial on Software
Restructuring, Gerald Weinberg