Transcript Team Software Project (TSP) July 17, 2007 Cycle 2 Launch Teams, Leadership & Death Marches 7/17/2007 SE 652- 2007_7_17_Peopleware_DeathMarch.

Team Software Project (TSP)
July 17, 2007
Cycle 2 Launch
Teams, Leadership &
Death Marches
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
1
Due today
Cycle 2 Launch:
Cycle 2 Project Plan
Cycle 2 Measurement Plan
Updated Cycle 2 Project & Process docs based on Cycle 1 experience & audit
Presentation of Features & Measurement Constructs
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
2
Remaining Lectures Plan/Discussion
July 17 – Cycle 2 Launch
Cycle 2 Launch, Project & Measurement Planning
Peopleware Topics: Management, Teams, Open Kimono, Quality, Hiring/Morale,
Death March Projects (time permitting)
July 24 – Cycle 2 Requirements Complete
Cycle 2 Requirements
Death March Projects continued
Process topics – CMMI, TL-9000, ISO
July 31 – Cycle 2 Implementation Complete
System Test Plan Baselined
Cycle 2 Design & Implementation
Process topics – CMMI Details
August 7 – Cycle 2 Test Complete
Cycle 2 Test Complete
Other topics TBD
August 14 - Course Review
Cycle 2 Post-Mortem Complete
Course Review
Final
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
3
Team Cycle 2 Presentations
Peopleware
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
6
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
7
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
8
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
9
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
10
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
11
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
12
Open Kimono
Trust
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
13
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
14
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/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
15
“Most organizations don’t set out consciously to kill teams …
They just act that way.”
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
17
Death March Projects
From Death March by Edward Yourdon
Death March
Odds of a software project delivering on its committed schedule, budget &
capabilities is extremely poor
Average Project
6-12 months behind schedule
50-100% over budget
But Why?
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
19
How Do We Get Here?
Start:
High risk factors:
• Optimism
• Wishful thinking
Unrealistic schedule & budget
Realistic plan, but then it goes downhill
e.g. user adds requirements
Results:
Overtime
Wasted weekends
Emotional & physical burnout before the end
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
20
Key Takeaway
Confronted with joining a Death March project,
Recognize & understand your own motivations, so
you can make a rational decision to join the team or look elsewhere for
your next job.
You always have options!
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
21
Death March Defined
Project where an unbiased objective risk assessment (including technical,
interpersonal & legal risks) determines the likelihood of failure at
greater than 50%.
Death March projects are the norm, not the exception!
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
22
Common Root Causes
Compressed schedule (e.g. < ½ time estimated by a rational process)
½ Staff of what a comparable project typically requires
½ Budget & associated resources
Twice the functionality, feature & performance requirements given
schedule, staff & budget constraints
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
23
Types of Death March Projects
Size
Small
< 10 people
3-6 months
Most common & greatest chance of success
How: small, tight knit, motivated group can totally sacrifice their personal lives, provided …
They know the hardships (nights & weekends) will end in a few months
Medium
20-30 people
1-2 years
Little chance of success
Large
100-300 people
3-5 years
No chance of success
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
24
Reasons
Politics … ugly politics!
Naïve promises
Hysterical Optimism
e.g. Everyone in organization desperately wants to believe that a complex project, never
before completed in < 3 years, can somehow be finished in 9 months.
Naïve optimism of youth
No problem, we can do it in a weekend!
Start-up mentality of fledgling, entrepreneurial companies
Intense competition
Markets
Technologies
Government regulations
Unexpected &/or unplanned crises
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
25
Questions?
Why would anyone in his/her right mind agree to work on a death march
project?
If a colleague of yours was to take on the task of managing a death march
project, what is the one thing you would advise him/her to do?
To not do?
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
26
Reasons for signing up
High Risk / High Reward (e.g. Microsoft example)
“Mt Everest” syndrome
For the challenge!
Noble failures may promise glory even if not successful (e.g. Go)
But watch for … pre-determined failures and “so what” value props
Unemployment
Pre-requisite of promotion or future advancement
Bankruptcy
Revenge!
Escape normal company bureaucracy (e.g. skunkworks, Apple’s Mac)*
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
27
Politics
The often internally conflicting interrelationships among people in a society.
Intrigue or maneuvering within a political unit or group in order to gain
control.
Source: The American Heritage® Dictionary of the English Language, Fourth Edition
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
28
Politics
Politics are normal
Death March politics tend to be more intensive & unhealthy
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
29
Identifying Stakeholders
Why?
Need to know friend from foe
Owner (potential friend)
Customer
Shareholders
Stakeholders
Champions
Probably more important to project’s success than any technology or methodology
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
30
Happiness
Death March Project Types
Kamikaze
Mission
Impossible
Suicide
Ugly
Success Probability
Happiness Gauge
Would you do this again?
Mission Impossible
High team morale, thrive on challenge, dream of rewards of success
Kamikaze
Go type project, happiness derived from technology or team dynamics
Ugly
Low team morale, heavy duty politics
Suicide
Everyone doomed, everyone miserable
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
31
Negotiations
Negotiations at start of projects tend to be irrational
Why?
Negotiations at 1-2 months prior to deadline tend to be more rational
Customer realizes original deadline, budget & functionality won’t be achieved
But, it’s too late for some project members (e.g. project leader)
“You need to understand your own management’s negotiating stance, if they
love to play roll over, you have to keep them well away from the project.”
Doug Scott
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
32
Mitigation Tactics
Commercial Estimation Tools
50+ available (e.g. SLIM, Checkpoint, Estimacs)
Best estimates, +/- 10%, but Death March projects typically off by 1000%!
Systems Dynamics Models
Prediction of impact from constraint changes
e.g. Overtime: initially output increases, then errors increase & output decreases
Prototyping & Timeboxing
Acceptable Trade-offs
Pose alternatives
80/20 rule
“everybody wants things good, wants them fast & wants them cheap … pick two”
Balancing Time, Resources, Capability
10% change in one variable, change another variable 10%
What happens if greater than 10% change?
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
33
Negotiation Games
Negotiation is a game
Safety factor in most projects is?
But, for Death March projects …
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
34
Basic Negotiation Games
Doubling & add some
Bosses know this one, so they halve it.
But, actually sound logic behind this one
Reverse Doubling
Client / customer gets one estimate
Development team another
Price is Right? (or Guess the # I’m thinking of)
Benefits for boss?
Double Dummy Spit
The X Plus Game
Spanish Inquisition
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
35
Advanced Negotiation Games
Low Bid / What are they prepared to pay
Gotcha!
Smoke & Mirrors / Blinding with science (GIGO rule)
False Precision
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
36
Tactics
Not playing along is risky, but negotiation games can be countered
First, recognize the game
e.g. Price is Right, response “what do you think is a good estimate”
Delay
Use data, sound estimation practices & comparable examples
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
37
You are leading a Death March Project
How do you survive?
People
Choose your own team (if possible)
Superstars?
Well honed Mission Impossible team
Well prepared mere mortals
Pot luck
Prepare for some overtime
Preferably short sprints
Reward the team well if project succeeds
Focus on building a loyal, cohesive & cooperative team
Commitment
Motivation
Rewards
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
39
Teams
Open & honest Communication
Assume no secrets & you won’t get burned
Share everything you can
For stuff you can’t share, say so!
Remember the Peopleware lessons
You need every productivity improving factor you can get
Overall,
Talented people,
Cohesive teams &
Decent working conditions give you the greatest chance of success
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
40
Death March Approaches
Key:
You can’t do everything, so …
Don’t put together a plan or processes that assume you can
(e.g. waterfall)
Solution:
Triage!
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
41
Requirements Management
Ultimately a crisis will occur & reality will hit
Several scenarios could occur:
Fire project manager
Renegotiate schedule
Renegotiate functionality (at which point most WIP gets thrown away)
Alternatively, plan at start
80/20 Rule
Key is to choose the “right” 20%
Approach:
Prioritize (subtly) requirements into must do, should do, could do
At start, identify what will ultimately be thrown away & avoid spending energy on those
items
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
42
Death March Processes
Back to basics
Manage requirements
Initial baseline
Changes – high threshold & very visible
Don’t try out new tools & processes
Agree on & formalize some important processes, then follow them
e.g. source code control, change management, requirements management
Leave other processes ad hoc
Pay careful attention to risk management
e.g. Top 10 list
7/17/2007
SE 652- 2007_7_17_Peopleware_DeathMarch
43