page 1
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University
Watts S. Humphrey
The Software Engineering Institute
Carnegie Mellon University
Coaching Development Teams
© 2006 by Carnegie Mellon University 2
AgendaSystems Problems
Teams – What and Why
Team Coaching
The Team Life Cycle
An Example Process – TSP
Example Coaching Results
© 2006 by Carnegie Mellon University 3
Systems Problems
The IRS system – finally started to use in 2005
• 5 years of delays• costs exploded to $2 B
FBI system killed• 3 years of work• $150 M• 5 CIOs, 9 program
managers
Britain’s child-support project• a year late• $844 M• didn’t pay 50% of cases
© 2006 by Carnegie Mellon University 4
Transportation
Automobiles• Mercedes Benz – batteries,
windows, temperature• automatic braking systems• Ford Explorer
Boeing 777• Malaysian Airlines• Singapore
© 2006 by Carnegie Mellon University 5
This Is No Joke!These are not new problems.
• CONFIRM system 20 years ago• Cancelled after 3 ½ years and $125 M
How long will society tolerate such performance?
Do we want government controls?• Methods standards and approval?• Pre-shipment reviews?• Legislated warranties?
We had better solve our own problems or others will solve them for us.
© 2006 by Carnegie Mellon University 6
Geopolitical Changes
While these technological challenges are significant, recent geopolitical changes are even more important.• fall of the Berlin Wall• opening of Eastern Europe• China’s transition to capitalism• India’s embrace of international trade
These changes mean that competition in our industry is world-wide.• Computing power is in everyone’s hands. • The world’s information is at our fingertips.• World-wide communication is nearly instantaneous.
© 2006 by Carnegie Mellon University 7
Workflow Changes
The flow of work has totally changed in five years.• Borders have disappeared.• Everybody can compete with everyone else.• Distributed teams capitalize on world-wide talent.• Open source cuts the cost of entry.
Work can now be done by the smartest, lowest cost, best informed, and best managed people – wherever they are.
As Thomas Friedman says: “The world is flat.”
© 2006 by Carnegie Mellon University 8
Challenges of the Future
Our priorities must change. Systems are now
• larger• distributed• integrated• pervasive• critical
The methods of the past are not suitable today.
In the future, they could be dangerous!
© 2006 by Carnegie Mellon University 9
Future Opportunities
While the challenges of the future are great, so are the opportunities.
Very few organizations know how to consistently and predictably develop large-scale software-intensive systems.
The methods are known and available.
Those who take the lead in this field will be ahead for a long time.
© 2006 by Carnegie Mellon University 10
Modern Software Engineering - 1
Truly great products are built by people who understand what these products are intended to do.
Engineers must find the proper balance among conflicting pressures.• customer needs• technological capability• business reality
© 2006 by Carnegie Mellon University 11
Modern Software Engineering - 2
Great software work requires working with• teammates• users• technologists• business professionals• managers and executives
This is not just building things; it is knowledge work.
© 2006 by Carnegie Mellon University 12
Knowledge Work
Knowledge work involves assimilating, relating, and integrating concepts and ideas.
Knowledge work produces intangible intellectual products.
Managing knowledge work fundamentally differs from managing the development of physical devices.
Essentially all software and systems work is knowledge work.
© 2006 by Carnegie Mellon University 13
Managing Knowledge Work
There is one key rule to managing knowledge work.
The rule: managers can’t manage knowledge workers; they must manage themselves.
The principal problem is that today few development professionals can manage themselves. They cannot• make accurate plans• negotiate commitments• track their work• consistently do what they agreed to do
This requires a new engineering paradigm.
© 2006 by Carnegie Mellon University 14
AgendaSystems Problems
Teams – What and Why
Team Coaching
The Team Life Cycle
An Example Process – TSP
Example Coaching Results
© 2006 by Carnegie Mellon University 15
Teams –What and Why
A team is a group • with two or more
members• that has a common goal• where each member has
a defined role• in which the members
cooperate to meet their goals
© 2006 by Carnegie Mellon University 16
Team Benefits
Teams provide important benefits.
• needed resources• a mix of talents and skills• a working structure• a support system
- membership – roles- technical support- task support- emotional support
Teams also provide a power base for negotiating commitments.
© 2006 by Carnegie Mellon University 17
The Engineering Problem
There is no secret to negotiating plans and meeting commitments.
The methods are known and can be taught to anyone.
Systems and software engineers today are bright people who should be consistently successful.
Yet most software-intensive projects are late, over cost, and of marginal quality.
Even routine software-intensive projects typically fail because the teams do not use proper methods.
© 2006 by Carnegie Mellon University 18
Self-Management Skills
The ability to make accurate and detailed plans.
The self-confidence to negotiate commitments with management.
The skill to consistently meet committed schedules.
The ability to use historical data to make accurate plans.
The skill and discipline to gather the data for accurate planning.
© 2006 by Carnegie Mellon University 19
Quality Commitment
Quality is the most fundamental single element of engineering work.
Software engineers must own the quality of the products they produce.
Engineers should learn how to produce quality work before they are even called engineers.
A personal commitment to quality should be an essential qualification for being an engineer.
© 2006 by Carnegie Mellon University 20
Building Commitment
A personal commitment to quality must be developed.• while growing up• during one’s education• from role models• through painful experience
Lifetime commitments take experience and knowledge.
These cannot be instilled in brief industrial training classes.
© 2006 by Carnegie Mellon University 21
Best Engineering Practices
The performance of an engineering organization is determined by the performance of its teams.
The performance of an engineering team is determined by the performance of the members.
The performance of the members is determined by their personal practices.
To perform at their best, members’ personal practices must be• defined• measured• tracked• managed
© 2006 by Carnegie Mellon University 22
Teamworking
The principles of sound teamworking are well understood and proven.
Why aren’t these practices more generally used?
• The developers lack skills, knowledge, and experience.
• Management does not support teamwork.
• No coaching support.
© 2006 by Carnegie Mellon University 23
The Need for Coaching
Development skills and management priority are essential, but not sufficient.
Without coaching resources and skills• it is almost impossible to get started• the teambuilding efforts will not be sustainable
© 2006 by Carnegie Mellon University 24
AgendaSystems Problems
Teams – What and Why
Team Coaching
The Team Life Cycle
An Example Process – TSP
Example Coaching Results
© 2006 by Carnegie Mellon University 25
Team Coaching
High-performing groups typically have professional guidance and support.
• sports teams• performing arts
- conductors- directors
A poor coach a poor team.• The coach forms, energizes, and motivates the team.• Development teams typically do not have coaches.
© 2006 by Carnegie Mellon University 26
The Coaching JobThe team leader uses the team to develop the product.
The coach uses the project to develop the team.
The coaching job has five parts.• building talent• setting and maintaining standards• building and sustaining motivation• focusing on improvement• celebrating and rewarding achievement
© 2006 by Carnegie Mellon University 27
Building Talent
People have latent talents that even they do not suspect.
People often produce extra-ordinary results when they are
• motivated• guided• supported
An important part of the coaching job is to • identify latent talent• guide, motivate, and develop that talent• sustain and enhance recognized talents
© 2006 by Carnegie Mellon University 28
Standards
Standards define job performance.• What is acceptable.• What is good work.• What is superior work.
Standards can be highly motivating when they
• are realistic• make business sense• are challenging• are owned by the team and team members
The coach’s job is to help teams set and manage to challenging standards.
© 2006 by Carnegie Mellon University 29
MotivationThe coaching focus must be on
• striving for success• establishing personal and team bests• future wins not past losses
If the team or team members miss some goals or standards, the coach helps them to
• learn from the experience• be motivated to do better the next time
© 2006 by Carnegie Mellon University 30
ImprovementArbitrary goals are rarely motivating. They are often
• unrealistic• unjustified• soon forgotten
Goals to surpass personal or team bests are motivating.
The coach helps the team and team members to• set their own improvement goals• strive to meet these goals• continue improving in small steps
© 2006 by Carnegie Mellon University 31
Celebrating Success
In engineering work, success is invisible.
Management expects teams to deliver quality products on schedule.
The coach must• identify superior work• ensure that superior work
is recognized• ensure that superior work
is rewarded
© 2006 by Carnegie Mellon University 32
A Coaching Example
Maurice Greene and coach John Smith
• videotaped sprint• measured each phase• guided improvement
June 16, 1999, Greene won the Gold Medal in Athens.
He was the fastest man alive.
© 2006 by Carnegie Mellon University 33
Coaching ResponsibilitiesMeet with each individual team member.
• Consider their interests and experiences.• Recognize their strengths and weaknesses.
Help the members to improve themselves.• Define personal processes.• Establish measures.• Set personal improvement goals.• Focus on small achievable steps.
© 2006 by Carnegie Mellon University 34
Coaching Relationships
Build and maintain personal relationships.
• personal trust• helpful attitude• coach with data• private personal data
Problem team members• guide and support where possible• be realistic• establish management partnership
© 2006 by Carnegie Mellon University 35
Team ResponsibilitiesWhile coaches have responsibilities, so do teams.
The key team responsibilities are to• strive to do superior work• follow defined and measured practices
© 2006 by Carnegie Mellon University 36
Importance of Measures
To improve, you must know performance.
To improve in small steps, you must know performance precisely.
Without measures, there is no way to know performance precisely.
Without measures, coaching is impossible.
© 2006 by Carnegie Mellon University 37
Development MeasuresIn development, the key measures are
• productivity• predictability• quality
The data required to calculate these derived measures are the
• size of the product produced• time spent in each process step• defects found in each process step
© 2006 by Carnegie Mellon University 38
Defect Measures
Developers usually feel that• quality is testing’s responsibility• testing should gather the data
Quality is a key development responsibility.
• Testing can only find a fraction of the defects in a product.
• Unless a quality product is put into testing, a quality product cannot come out of testing.
© 2006 by Carnegie Mellon University 39
Overload
Hardware failure
Operatorerror
Data error
Resourcecontention
Configuration
Safe region = tested
(shaded)
Unsafe region = untested
(unshaded)
Test Effectiveness
© 2006 by Carnegie Mellon University 40
AgendaSystems Problems
Teams – What and Why
Team Coaching
The Team Life Cycle
An Example Process – TSP
Example Coaching Results
© 2006 by Carnegie Mellon University 41
The Team Life Cycle
Group formation has four natural phases.
• forming• storming• norming• performing
© 2006 by Carnegie Mellon University 42
Teambuilding SupportTeams will naturally progress through the four phases of group formation.
However, these steps by themselves will not necessarily produce effective teams.
To consistently build effective teams, you must follow a defined and supported teambuilding process.
© 2006 by Carnegie Mellon University 43
TeambuildingSuccessful teams need
• a compelling mission• realistic and achievable commitments• suitably skilled resources• proper guidance and support
Unless these conditions are consciously established, they will not likely occur.
Producing these conditions is called teambuilding.
© 2006 by Carnegie Mellon University 44
Teambuilding Exercises
Typical teambuilding exercises are
• off site• not connected to the job• done with strangers• risky and stressful
They also typically require that all team members work cooperatively to meet their objectives.
While the results are often positive, they are generally temporary.
© 2006 by Carnegie Mellon University 45
Teambuilding ObjectivesAn effective teambuilding process accomplishes three things.
• Satisfies the conditions for effective teamwork.• Applies in the team’s working environment.• Guides the team in using effective working styles.
© 2006 by Carnegie Mellon University 46
Group Styles
RandomOpen
SynchronousClosed
More Directive Less Interactive
More Interactive Less Directive
© 2006 by Carnegie Mellon University 47
Teambuilding RequirementsTo actually improve a team’s performance, the teambuilding process must
• directly relate to the team’s work• include all the team members• involve the team leader• have the support of the team’s management• be competently coached
© 2006 by Carnegie Mellon University 48
AgendaSystems Problems
Teams – What and Why
Team Coaching
The Team Life Cycle
An Example Process – TSP
Example Coaching Results
© 2006 by Carnegie Mellon University 49
An Example Process - TSPThe Software Engineering Institute (SEI) has developed the Team Software Process (TSP).
The TSP objectives are to• improve the performance of engineering teams• guide qualified coaches through the teambuilding
process• provide the data and process structure required for
effective team coaching
SM
SMTeam Software Process and TSP are service marks of Carnegie Mellon University.
© 2006 by Carnegie Mellon University 50
TSP Overview
The TSP is usually used by teams of 3 to about 15 developers.
The TSP includes• a full set of process forms, scripts, and standards• standard team-member roles• a structured launch and tracking process• a team and developer support system
© 2006 by Carnegie Mellon University 51
TSP Structure and Flow
A 4-day TSP launch kicks off each major project phase.
The team builds a common understanding of • the process• the work • the plan
The members produce plans to guide their work.
Subsequent phases kick off with a TSP relaunch.
Launch
Development Phase A
Postmortem
Relaunch
Postmortem
DevelopmentPhase B
© 2006 by Carnegie Mellon University 52
The TSP Launch ProcessDay 1
1. Establish
product and business
goals
2. Assign roles
and define team goals
Day 2
4. Build overall
and near-term
plans
5. Develop
the quality plan
6. Buildindividual
and
consolidatedplans
Day 3
7. Conduct
riskassessment
8. Prepare
managementbriefing and
launch report
Launchpostmortem
Day 4
9. Hold
managementreview
3. Produce development
strategyand process
A qualified TSP team coach guides the team through a defined process to develop its plan and to negotiate that plan with management.
© 2006 by Carnegie Mellon University
TSP Launch Meeting 1
In launch meeting 1, management• describes what they want done• explains why the job is important • answers the team member’s questions
The objectives of meeting 1 are to• motivate the team members to do this job• ensure that the team understands management’s
criteria for success
© 2006 by Carnegie Mellon University 54
A TSP Industrial Project
The project was to develop communications test equipment.
Management described the product they wanted.• a new communication-line tester• required new hardware and
software• had to be available for first
customer shipment in nine months
© 2006 by Carnegie Mellon University
TSP Launch Meetings 2 - 8
During the TSP launch, the team members• define a process and strategy for doing the job• produce detailed team and personal plans• assess the risks of their plans• present their plans to management
Because the team and team leader have a great deal to do during the launch, they are coached through• building the plan• working without observers
© 2006 by Carnegie Mellon University
TSP Launch Meeting 9
In launch meeting 9, the team presents its plan.• best plan • alternative plans
Management’s responsibilities in meeting 9 are to• probe the team’s plan • assess the plan’s accuracy and completeness• approve the plan if it is suitable
© 2006 by Carnegie Mellon University
TSP Launch Meeting 9 (cont.)
Team plans rarely meet all of management’s objectives.
When the plan does not meet their needs, managers must • identify the most suitable alternate plan• suggest other choices if no suitable plan is available
At the meeting’s conclusion, management• decides how to proceed• tells the team its decision • explains why they made the decision• thanks the team members for their work
© 2006 by Carnegie Mellon University 58
A TSP Industrial Project
The project was to develop communications test equipment.
Plan
Size - KLOC 110 Effort - hours 16,000 Schedule - weeks 77 Defects per KLOC
Integration and system test 1.1 Field trial 0.0 Customer use 0.0
© 2006 by Carnegie Mellon University 59
TSP Team Operation
Following the launch, the team does the job.• follows its plans• tracks the work• regularly assesses project risks• reports to management on status and progress
For longer jobs, TSP teams periodically relaunch their projects.
© 2006 by Carnegie Mellon University 60
Managing to the Team’s Plan
These data show project status after 7 weeks.1. The team has completed 22.3% of the job. 2. The team is spending 20.54 hours per EV point
(458/22.3).3. At this rate, there are 1596 hours to go (77.7*20.54).4. At the rate of 126.7 hours, there are 12.6 weeks to go.5. This is 2.6 weeks behind the 17-week plan.
Plan/
Weekly Data Plan Actual Actual
Schedule hours for this week 121.0 126.7 0.95
Schedule hours this cycle to date 467.0 493.4 0.95
Earned value for this week 7.6 6.4 1.19
Earned value this cycle to date 28.2 22.3 1.26
To-date hours for tasks completed 354.3 458.0 0.77
To-date average hours per week
© 2006 by Carnegie Mellon University 61
Team Weekly Earned Value
Through Week 10
0
2
4
6
8
10
1 2 3 4 5 6 7 8 9 10
Week Number
Ea
rne
d V
alu
e f
or
We
ek
Actual
Plan
© 2006 by Carnegie Mellon University 62
Projected Week Complete
Through Week 10
0
10
20
30
40
50
60
70
1 2 3 4 5 6 7 8 9 10
Week Number
We
ek
Co
mp
lete
d
Average
Latest
Plan
© 2006 by Carnegie Mellon University 63
A TSP Industrial Project
The project was to develop communications test equipment.
Plan Actual
Size - KLOC 110 89.9Effort - hours 16,000 14,711Schedule - weeks 77 71Defects per KLOC
Integration and system test 1.1 0.6Field trial 0.0 0.02Customer use 0.0 0.0
© 2006 by Carnegie Mellon University 64
AgendaSystems Problems
Teams – What and Why
Team Coaching
The Team Life Cycle
An Example Process – TSP
Example Coaching Results
© 2006 by Carnegie Mellon University 65
Example Coaching Results
Many organizations have now used the TSP.
The results have been excellent.
There is no question that the TSP works.
© 2006 by Carnegie Mellon University 66
Cost and Schedule
With timely and precise data, TSP teams can manage their schedule performance.
1616N =
With TSPWithout TSP
Devia
tion
125
100
75
50
25
0
-25
-50
-75
1515N =
With TSPWithout TSP
Devia
tion
175
150
125
100
75
50
25
0
-25
-50
-75
Effort Schedule
© 2006 by Carnegie Mellon University 67
Cycle Time
1212N =
With TSPWithout TSP
da
ys/k
loc
8
7
6
5
4
3
2
1
0
With the TSP, teams find and fix defects early in the development process.
This sharply reduces test time.
With shorter testing, cycle time is cut.
Savings
Reqts Design Implement Test
Typical team
TSP team
Reqts Design Implement Test
Test Time per KLOC
© 2006 by Carnegie Mellon University
Product Quality
7.5
6.24
4.73
2.28
1.050.06
0
1
2
3
4
5
6
7
8
Defe
cts
/KL
OC
CMM
Level 1
CMM
Level 2
CMM
Level 3
CMM
Level 4
CMM
Level 5
TSP
Defect Density of Delivered Software
Ref: SEI Technical Report 2003-014
© 2006 by Carnegie Mellon University 69
The AIS CorporationSchedule Deviation Control Chart
-150
-100
-50
0
50
100
150
200
250
300
350
01/8801/89
01/9001/91
01/9201/93
01/9401/95
01/9601/97
01/98
Date of Project Start
% D
evia
tio
n
Individual Data Points Mean Upper Natural Process Limit
Lower Natural Process Limit One Standard Deviation
Pre-CMM CMM TSP
© 2006 by Carnegie Mellon University 71
Team Development
Team performance improves with experience. In 4 releases, one team• delivered on time• increased productivity by 81%
Defect Data - Five Releases of the Same Product
Non-TSP TSP TSP TSP TSP
Release number 1 2 3 4 5
Defects/1000 LOC
System Test 13.3 2.5 0.8 1.0 0.1
Acceptance Test 0.8 0.0 0.0 0.0 0.0
Customer Production 1.2 0.2 0.0 0.0 0.0
© 2006 by Carnegie Mellon University 72
An Industrial Study
A comparison of the performance of 80 traditional development teams with 15 first-time TSP teams
Non-TSP Projects TSP Projects
Released on Time 42% 66%
Average Days Late 25 6
Mean Schedule Error 10% 1%
Test Defects/KLOC 19.5 12.8
Production Defects/KLOC 1.8 0.5
Sample Size 80 15
© 2006 by Carnegie Mellon University 73
Messages to Remember
Modern engineering work is more challenging than ever before.
To meet the greater challenges of the future, we need high-performing engineering teams.
To capitalize on the opportunities ahead, development teams must be• properly trained• competently coached
Such teams are capable of extraordinary work.
© 2006 by Carnegie Mellon University 74
For More InformationVisit the PSP/TSP web site
http://www.sei.cmu.edu/tsp
Contact SEI customer relations
Phone, voice mail, and on-demand FAX: 412/268-5800E-mail: [email protected]
See the Watts Humphrey booksWinning with Software: an Executive Strategy, Addison-Wesley, 2002PSP: A Self-Improvement Process for Software Engineers, Addison-Wesley, 2005TSP: Leading a Development Team, Addison-Wesley, 2006TSP: Coaching Development Teams, Addison-Wesley, 2006
Top Related