Comparing SCRUM XP TSP V2

Document Sample
Comparing SCRUM XP TSP V2 Powered By Docstoc
					Gerard Manko
Introduction
 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‐
 managed teams.
Roles Matrix
                    XP         SCRUM              TSP
Management/         Tracker    Scrum Master       Team Leader
Leadership          Coach                         Planning Manager
                                                  Design Manager
                                                  Implementation Manager
Business Analysts   Customer   Product Owner      Customer Interface 
                                                  Manager
Development         Developer Team Member         Engineer
Quality             Customer   Product Owner      Quality Manager
Assurance                                         Process Manager
                                                  Test Manager
Other                          Senior             Support Manager
                               Management, Other 
                               Stakeholders
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 
 programmers. 
 Tracker – functions as the project manager
 Coach – Technical/Process mentor
Roles ‐ SCRUM
 “Pig” Roles
   Scrum Master – a project manager type role
   Product Owner – similar to XP customer role
   Team Member – again generalized, like XP
 “Chicken” Roles
   Senior Management
   Other Stakeholders
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 
 inspections
 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)
 Continuous Integration
 Design Improvement (refactoring)
 Small Releases (~2 week iterations, ~quarterly releases)
 Coding Standard
 Collective Code Ownership
 Simple Design (YAGNI)
 System Metaphor
 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)
 Timeboxing
 Daily Scrum (stand‐up meeting)
 Burndown Chart
 Demo (post‐sprint review, of working, tested 
 software)
 “Definition of Done”
 Retrospective (lessons learned)
 Team sits together (co‐location)
Practices ‐ TSP
 Launch
 Scripts (brief process descriptions)
 Template Forms
 More traditional approach to requirements, design, 
 and implementation, and testing
 Emphasis on Measurement (Time, Cost, Defects)
 Reviews and Inspections
 Postmortem
 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 
   ANY time.
   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)
     Verbal
     Face‐to‐Face
     “Shared Memory”
     Collaborative Environment (“Circle of Trust”)
   TSP
     Much of project communications are interpersonal
     However, necessary artifacts are retained in written form
     Data is collected on a continuous basis (hopefully automated)
   Traditional SDLCs
     Written
     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")
Potential Pitfalls
 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.
Recommendations
 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 
 parties.
 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)
Summary
 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.
Resources
 Introduction to the Team Software Process, Watts S. 
 Humphrey
 "Kill That Code!", IEEE Tutorial on Software 
 Restructuring, Gerald Weinberg
 http://en.wikipedia.org/wiki/Extreme_Programming_
 Practices
 http://en.wikipedia.org/wiki/Scrum_(development)
 http://www.crisp.se/scrum/checklist

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:2
posted:2/21/2013
language:English
pages:17