7/17/2007se 652- 2007_7_17_peopleware_deathmarch1 team software project (tsp) july 17, 2007 cycle 2...

7/17/2007 SE 652- 2007_7_17_Peopleware_DeathMarch 1

Team Software Project (TSP)

July 17, 2007

Cycle 2 Launch

Teams, Leadership &

Death Marches


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


Remaining Lectures Plan/Discussion

July 17 – Cycle 2 LaunchCycle 2 Launch, Project & Measurement PlanningPeopleware Topics: Management, Teams, Open Kimono, Quality, Hiring/Morale,

Death March Projects (time permitting)July 24 – Cycle 2 Requirements Complete

Cycle 2 RequirementsDeath March Projects continuedProcess topics – CMMI, TL-9000, ISO

July 31 – Cycle 2 Implementation CompleteSystem Test Plan BaselinedCycle 2 Design & ImplementationProcess topics – CMMI Details

August 7 – Cycle 2 Test CompleteCycle 2 Test CompleteOther topics TBD

August 14 - Course ReviewCycle 2 Post-Mortem CompleteCourse ReviewFinal

Team Cycle 2 Presentations

Peopleware


Production vs. Development Objectives

Squeeze out errors

Production Development

No goofing on the job

Interchangeable workers

Optimize steady state

Standardize procedures

Eliminate experimentation

Occasional mistakes natural & healthy

Self motivation, want creativity, …

Not interchangeable, want uniqueness

Project always in a state of flux

Some standardization, but …

Selective experimentation is good


Thinking Time

BrainstormingInvestigating new methodsAvoiding tasksReadingTrainingGoofing 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!


View of Management

Management about getting people to work harderEven (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 motivatedTreating people as Parkinsonian workers only demeans & demotivates

In fact, bad estimates are a major source of demotivation


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?


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!


Quality

Associate self-esteemQuantity vs. quality?

Workers under extreme time pressure sacrifice qualityLack of trying?No! Lack of options!

Myth: some markets don’t give a damn about high qualityTruth: 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


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!


Open Kimono

Trust


Team ExercisePrisoner’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.


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 KimonoCheck-up / Parkinsonian patrol

Open KimonoOff-premise development meetings w/o supervision

The best managers take chances on their people


“Most organizations don’t set out consciously to kill teams …

They just act that way.”

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?


How Do We Get Here?

Start:

High risk factors:• Optimism

• Wishful thinking

Unrealistic schedule & budget

Realistic plan, but then it goes downhille.g. user adds requirements

Results:

Overtime

Wasted weekends

Emotional & physical burnout before the end


Key Takeaway

Confronted with joining a Death March project,Recognize & understand your own motivations, soyou can make a rational decision to join the team or look elsewhere for your next job.

You always have options!


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!


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


Types of Death March ProjectsSize

Small< 10 people

3-6 months

Most common & greatest chance of successHow: small, tight knit, motivated group can totally sacrifice their personal lives, provided …

They know the hardships (nights & weekends) will end in a few months

Medium20-30 people

1-2 years

Little chance of success

Large100-300 people

3-5 years

No chance of success


Reasons

Politics … ugly politics!

Naïve promises

Hysterical Optimisme.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 youthNo problem, we can do it in a weekend!

Start-up mentality of fledgling, entrepreneurial companies

Intense competitionMarkets

Technologies

Government regulations

Unexpected &/or unplanned crises


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?


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)*


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


Politics

Politics are normal

Death March politics tend to be more intensive & unhealthy


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


Death March Project Types

Happiness GaugeWould you do this again?

Mission ImpossibleHigh team morale, thrive on challenge, dream of rewards of success

KamikazeGo type project, happiness derived from technology or team dynamics

UglyLow team morale, heavy duty politics

SuicideEveryone doomed, everyone miserable

UglySuicide

MissionImpossible

Kamikaze

Hap

pine

ss

Success ProbabilityLow


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


Mitigation Tactics

Commercial Estimation Tools50+ available (e.g. SLIM, Checkpoint, Estimacs)

Best estimates, +/- 10%, but Death March projects typically off by 1000%!

Systems Dynamics ModelsPrediction of impact from constraint changes

e.g. Overtime: initially output increases, then errors increase & output decreases

Prototyping & Timeboxing

Acceptable Trade-offsPose alternatives

80/20 rule

“everybody wants things good, wants them fast & wants them cheap … pick two”

Balancing Time, Resources, Capability10% change in one variable, change another variable 10%

What happens if greater than 10% change?


Negotiation Games

Negotiation is a game

Safety factor in most projects is?

But, for Death March projects …


Basic Negotiation Games

Doubling & add someBosses know this one, so they halve it.

But, actually sound logic behind this one

Reverse DoublingClient / 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


Advanced Negotiation Games

Low Bid / What are they prepared to pay

Gotcha!

Smoke & Mirrors / Blinding with science (GIGO rule)

False Precision


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

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 overtimePreferably short sprints

Reward the team well if project succeeds

Focus on building a loyal, cohesive & cooperative teamCommitment

Motivation

Rewards


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


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!


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 RuleKey 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


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/2007se 652- 2007_7_17_peopleware_deathmarch1 team software project (tsp) july 17, 2007 cycle 2...

Documents

launch cycle

peopleware slide

team cycle

project plan cycle

test complete cycle

requirements complete

course review cycle

good slide