Transcript Team Software Project (TSP) July 10, 2007 Peopleware & Post Mortem 7/10/2007 SE 652- 2007_7_10_peopleware.

Team Software Project (TSP)
July 10, 2007
Peopleware &
Post Mortem
7/10/2007
SE 652- 2007_7_10_peopleware
1
Due Today
Cycle 1 Reports / Post-Mortem (including Peer & Team evaluations)
Cycle 1 Results Presentation
Final Cycle 1 Work Products (Project documents, quality records & source code)
7/10/2007
SE 652- 2007_7_10_peopleware
2
Remaining Lectures Plan/Discussion
July 10 – Cycle 1 Test Complete & Post-Mortem
Cycle 1 Results Presentation & Discussion
Cycle 1 Reports & Post-Mortem
Team audits (Maxigon complete, Greg’s team 3p today, Steve’s team 7p Thurs)
July 17 – Cycle 2 Launch
Cycle 2 Launch, Project & Measurement Planning
Peopleware Topics: Management, Teams, Open Kimono, Quality, Hiring/Morale, …
July 24 – Cycle 2 Requirements Complete
Cycle 2 Requirements
Death March Projects:
July 31 – Cycle 2 Implementation Complete
System Test Plan Baselined
Cycle 2 Design & Implementation
Process topics – CMMI, TL-9000, ISO
August 7 – Cycle 2 Test Complete
Cycle 2 Test Complete
Cycle 2 Post-Mortem Complete??
August 14 - Course Review
Course Review
Class exercise
Final
7/10/2007
SE 652- 2007_7_10_peopleware
3
Class Outline
Post-Mortem Presentations
Peopleware topics
Mythical Man Month
7/10/2007
SE 652- 2007_7_10_peopleware
4
Team Post Mortem Presentations
Peopleware
The software industry has a “notorious” reputation for being out of control in
terms of schedule accuracy, cost accuracy & quality control. A majority
of large systems run late, exceed budgets & many are cancelled.
Capers Jones
The average project is:
6 – 12 months behind schedule
50 – 100% over budget
Edward Yourdon
Project Success Study – 500 projects
15% cancelled, aborted, postponed
For projects > 25 staff years, 25% fail
Tom DeMarco & Timothy Lister
7/10/2007
SE 652- 2007_7_10_peopleware
6
Project Failures
What is the root cause of failures:
Technology?
No. Politics!
Communication
Staffing
Lack of Motivation
High turnover
Conclusion:
“major problems are not so much technological as sociological”
7/10/2007
SE 652- 2007_7_10_peopleware
7
Management
Managers concede that people issues exist, but tend to manage technical
issues.
Why?
7/10/2007
SE 652- 2007_7_10_peopleware
8
Mythical Man Month
Frederick Brooks, 1974
Why do projects fail?
“More software project have gone awry for lack of calendar time than for all
other causes”
So when projects get into schedule trouble, how do most Project
Managers try to recover?
Add staff!
7/10/2007
SE 652- 2007_7_10_peopleware
9
Mythical Man Month
Example
Assume:
1200 staff day project
10 team members
120 working days
80 days into project:
Only 50% complete (PV=800/1200=.67, EV=.50, SPI=.75)
Therefore, have completed 600 staff days of work
Assuming original estimate valid, 600 staff days remaining
Solution:
Add 5 additional team members to the project
(10+5) team members x 40 days = 600 staff days
Reasonable?
7/10/2007
SE 652- 2007_7_10_peopleware
10
Not!
Fallacy of man-month
Assumes resources are interchangeable
Assumes tasks are partitioned & requires no inter-person communication
Neglects to take into account ramp costs (e.g. training)
The truth . . .
“Adding staff to a late project, only makes it later!”
7/10/2007
SE 652- 2007_7_10_peopleware
11
How do projects get into schedule trouble?
Project Planning Process is Very flawed!
Optimism
Agree to unachievable schedule to meet customer’s/patron’s desired date
Poor estimation techniques
Confusion on the effort & process
Poor risk mitigation and monitoring
Result
Slip typically not evident until late in the project
Absolute worst time:
Project fully staffed
Consumers & downstream teams geared up to proceed
7/10/2007
SE 652- 2007_7_10_peopleware
12
Production vs. Development Objectives
Production
Development
Squeeze out errors
Occasional mistakes natural & healthy
No goofing on the job
Self motivation, want creativity, …
Interchangeable workers
Not interchangeable, want uniqueness
Optimize steady state
Project always in a state of flux
Standardize procedures
Some standardization, but …
Eliminate experimentation
Selective experimentation is good
7/10/2007
SE 652- 2007_7_10_peopleware
13
Thinking Time
Brainstorming
Investigating new methods
Avoiding tasks
Reading
Training
Goofing off
When time pressure is greatest, need to learn to do work less of the time and think
about the work more…why?
Industry tends to focus on doing something …. Anything!
Development stat: 5% of project staff time spent on planning, investigating, new
methods, training, reading books, estimating, budgeting, scheduling &
allocating personnel combined!
7/10/2007
SE 652- 2007_7_10_peopleware
14
View of Management
Management about getting people to work harder
Even (especially) at expense of personal lives
Management is about “kicking ass”
Parkinson’s Law:
“work expands to fill the time allotted to it”
Software Development Corollary:
Only way to get work done is to set an impossibly optimistic delivery date
Development workers tend to be self motivated
Treating people as Parkinsonian workers only demeans & demotivates
In fact, bad estimates are a major source of demotivation
7/10/2007
SE 652- 2007_7_10_peopleware
15
Management’s True Role
If management’s role is not to look over people’s shoulders & kick …
What is it’s role?
A manager’s function is not to make people work, but to make it possible
for people to work.
What about leadership?
7/10/2007
SE 652- 2007_7_10_peopleware
16
Overtime
Productivity improvement methods
Work associates harder
Mechanize product development
Compromise quality
Standardize procedures
Side effects:
Reduces job satisfaction
Increases turnover
Example: Data General Eagle project (Soul of a new machine)
Incredible achievement, entire team quit afterwards
Assertion: people under time pressure don’t work better, they just work faster!
7/10/2007
SE 652- 2007_7_10_peopleware
17
Quality
Associate self-esteem
Quantity vs. quality?
Workers under extreme time pressure sacrifice quality
Lack of trying?
No! Lack of options!
Myth: some markets don’t give a damn about high quality
Truth: quality, far beyond that required by the end user is a means to higher
productivity
Crosby – “letting builder set a satisfying quality standard will result in a
productivity gain sufficient to offset the cost of the improved quality.”
Note: “quality – if time permits”, assures no quality at all will sneak into product
7/10/2007
SE 652- 2007_7_10_peopleware
18
Silver Bullet Myths
New trick will send productivity soaring!
Other projects seeing gains of 100% - 200%!
Technology moving so swiftly that you are being passed by!
New languages can give you huge gains!
Due to incoming project backlog, need to double productivity ASAP!
Isn’t it time to automate the software development?
People will work better under a lot of pressure!
7/10/2007
SE 652- 2007_7_10_peopleware
19
Growing Productive Teams
Teams typically don’t get work done, individuals do.
So why form teams?
– Diversity of skills, knowledge, abilities & experience
– Manpower
– Positive aspects of group dynamics
e.g. Increased creative flow
– Help get everyone pulling in the same direction
7/10/2007
SE 652- 2007_7_10_peopleware
20
Jelled Teams
What is a jelled team?
Group of people so closely knit that the whole is greater than the sum
of the parts.
Why do we want a jelled team?
Once a team jells, probability of success goes up dramatically!
7/10/2007
SE 652- 2007_7_10_peopleware
21
Characteristics of Jelled Teams
Self-motivated
Low-turnover
Strong sense of identity (e.g. team names, social interactions)
Joint ownership of the product
Sense of pride
High morale
Sense of eliteness
No one ever forgets the experience of being part of a jelled team!
7/10/2007
SE 652- 2007_7_10_peopleware
22
Characteristics of Jelled Team Environment
Work is fun
People energized
They blow past deadlines & milestones
Incredible loyalty to team and environment that allows team to exist
7/10/2007
SE 652- 2007_7_10_peopleware
23
IBM’s Black Team
Born of realization that testing viewed as unimportant & undesirable
Result, poor test quality = poor product quality
Pulled people with slightly better testing skills
Initial results okay, but ….
Sense of pride & team grew
Created a team personality (name, dress, appearance, socially)
Delighted in finding defects
Came to be feared
7/10/2007
SE 652- 2007_7_10_peopleware
24
How Do I Get One?
Common goals
Hope &
Don’t practice behaviors that kill the seedling
7/10/2007
SE 652- 2007_7_10_peopleware
25
Teamicide!
How to kill team growth
Bureaucracy
Paperwork
Decision Making
Communication
Physical Separation
Posters & Plaques
Time Fragmentation
Quality Reduction
Phony Deadlines
Clique Control
Overtime
Defensive Management
7/10/2007
SE 652- 2007_7_10_peopleware
26
“Most organizations don’t set out consciously to kill teams …
They just act that way.”
7/10/2007
SE 652- 2007_7_10_peopleware
27
Open Kimono
Trust
7/10/2007
SE 652- 2007_7_10_peopleware
28
Team Exercise
Prisoner’s Dilemma
Two people have been arrested separately, and are held in separate cells. They are not allowed to communicate.
Each is told the following:
We have arrested you and another person for committing this crime together.
If you confess, and the other person confesses, we will reward your assistance to us, and your sparing us the
expense of a trial, by sentencing you both fairly lightly: 2 years of prison.
If you don't confess, and the other person also doesn't confess, we will not be able to convict you, but we will
be able to hold you here and make you as uncomfortable as we can for 30 days.
If you confess, and the other person does not, we will show our appreciation to you by letting you go free. We
will then take your testimony, in which you will implicate the other person as your accomplice, and put that
person in prison for 40 years.
If you don't confess, and the other person does, that person's testimony will be used to put you in prison for 40
years; your accomplice will go free in exchange for the testimony.
Each of you is being given the same deal. Think about it.
7/10/2007
SE 652- 2007_7_10_peopleware
29
Exercise
Objective: Maximize your winnings
Rules:
Two teams (3 people each)
Each Round:
Each team decides to Collude or Denounce (2 minutes to decide)
Writes result on index card & hand in
Round scoring:
Both teams collude:
One team colludes, one denounces:
Both teams denounce:
+2 each
-1 Colluder, +4 denouncer
0 each
Random # of Rounds
7/10/2007
SE 652- 2007_7_10_peopleware
30
Exercise
Round 4+
Objective: Maximize your winnings
Rules:
Each team decides to Collude or Denounce (2 minutes to decide)
Writes result on index card & hand in
Round scoring:
Both teams collude:
One team colludes, one denounces:
Both teams denounce:
+1 each
-1 Colluder, +4 denouncer
0 each
Random # of Rounds
7/10/2007
SE 652- 2007_7_10_peopleware
31
Open Kimono Management
Take no steps to defend against people you put into positions of trust
& all of the people working for you are in positions of trust
Response: teams typically respond by living up to that trust
Non-Open Kimono
Check-up / Parkinsonian patrol
Open Kimono
Off-premise development meetings w/o supervision
The best managers take chances on their people
7/10/2007
SE 652- 2007_7_10_peopleware
32
Growing & Maintaining Team Chemistry
Make a cult of quality
Provide lots of closure opportunities
Allow team to feel unique or elite
Preserve & protect
Network model of leadership
Individuals provide occasional leadership in their strength areas
Manager outside team, occasional direction, clear obstacles
Allow & encourage diversity (skills & other elements)
Provide strategic, not tactical direction
7/10/2007
SE 652- 2007_7_10_peopleware
33
Due July 17 Class
Cycle 2 Launch:
Cycle 2 Project Plan
Cycle 2 Measurement Plan
Updated Cycle 2 Project & Process docs based on Cycle 1 experience & audit
7/10/2007
SE 652- 2007_7_10_peopleware
34