7/10/2007 SE 652- 2007_7_10_peopleware 1

Team Software Project (TSP)July 10, 2007

Peopleware &Post Mortem

7/10/2007 SE 652- 2007_7_10_peopleware 2

Due Today

Cycle 1 Reports / Post-Mortem (including Peer & Team evaluations)Cycle 1 Results PresentationFinal Cycle 1 Work Products (Project documents, quality records & source code)

7/10/2007 SE 652- 2007_7_10_peopleware 3

Remaining Lectures Plan/DiscussionJuly 10 – Cycle 1 Test Complete & Post-Mortem

Cycle 1 Results Presentation & DiscussionCycle 1 Reports & Post-MortemTeam audits (Maxigon complete, Greg’s team 3p today, Steve’s team 7p Thurs)

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

July 24 – Cycle 2 Requirements CompleteCycle 2 RequirementsDeath March Projects:

July 31 – Cycle 2 Implementation CompleteSystem Test Plan BaselinedCycle 2 Design & ImplementationProcess topics – CMMI, TL-9000, ISO

August 7 – Cycle 2 Test CompleteCycle 2 Test CompleteCycle 2 Post-Mortem Complete??

August 14 - Course ReviewCourse ReviewClass exerciseFinal

7/10/2007 SE 652- 2007_7_10_peopleware 4

Class Outline

Post-Mortem PresentationsPeopleware topicsMythical Man Month

Team Post Mortem Presentations

7/10/2007 SE 652- 2007_7_10_peopleware 6

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 schedule50 – 100% over budget

Edward Yourdon

Project Success Study – 500 projects15% cancelled, aborted, postponedFor projects > 25 staff years, 25% fail

Tom DeMarco & Timothy Lister

7/10/2007 SE 652- 2007_7_10_peopleware 7

Project Failures

What is the root cause of failures:Technology?

No. Politics!CommunicationStaffingLack of MotivationHigh turnover

Conclusion:“major problems are not so much technological as sociological”

7/10/2007 SE 652- 2007_7_10_peopleware 8

Management

Managers concede that people issues exist, but tend to manage technical issues.

Why?

7/10/2007 SE 652- 2007_7_10_peopleware 9

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 10

Mythical Man MonthExample

Assume:1200 staff day project10 team members120 working days

80 days into project:Only 50% complete (PV=800/1200=.67, EV=.50, SPI=.75)Therefore, have completed 600 staff days of workAssuming 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 11

Not!

Fallacy of man-monthAssumes resources are interchangeableAssumes tasks are partitioned & requires no inter-person communicationNeglects 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 12

How do projects get into schedule trouble?

Project Planning Process is Very flawed!OptimismAgree to unachievable schedule to meet customer’s/patron’s desired datePoor estimation techniquesConfusion on the effort & processPoor risk mitigation and monitoring

ResultSlip typically not evident until late in the projectAbsolute worst time:

Project fully staffedConsumers & downstream teams geared up to proceed

7/10/2007 SE 652- 2007_7_10_peopleware 13

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

7/10/2007 SE 652- 2007_7_10_peopleware 14

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!

7/10/2007 SE 652- 2007_7_10_peopleware 15

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

7/10/2007 SE 652- 2007_7_10_peopleware 16

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 17

Overtime

Productivity improvement methodsWork associates harderMechanize product developmentCompromise qualityStandardize procedures

Side effects:Reduces job satisfactionIncreases 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 18

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

7/10/2007 SE 652- 2007_7_10_peopleware 19

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 20

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 21

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 22

Characteristics of Jelled Teams

Self-motivatedLow-turnoverStrong sense of identity (e.g. team names, social interactions)Joint ownership of the productSense of prideHigh moraleSense of eliteness

No one ever forgets the experience of being part of a jelled team!

7/10/2007 SE 652- 2007_7_10_peopleware 23

Characteristics of Jelled Team Environment

Work is funPeople energizedThey blow past deadlines & milestonesIncredible loyalty to team and environment that allows team to exist

7/10/2007 SE 652- 2007_7_10_peopleware 24

IBM’s Black Team

Born of realization that testing viewed as unimportant & undesirableResult, poor test quality = poor product quality

Pulled people with slightly better testing skillsInitial results okay, but ….

Sense of pride & team grewCreated a team personality (name, dress, appearance, socially)Delighted in finding defectsCame to be feared

7/10/2007 SE 652- 2007_7_10_peopleware 25

How Do I Get One?

Common goalsHope &Don’t practice behaviors that kill the seedling

7/10/2007 SE 652- 2007_7_10_peopleware 26

Teamicide!How to kill team growth

BureaucracyPaperworkDecision MakingCommunication

Physical SeparationPosters & PlaquesTime FragmentationQuality ReductionPhony DeadlinesClique ControlOvertimeDefensive Management

7/10/2007 SE 652- 2007_7_10_peopleware 27

“Most organizations don’t set out consciously to kill teams … They just act that way.”

7/10/2007 SE 652- 2007_7_10_peopleware 28

Open Kimono

Trust

7/10/2007 SE 652- 2007_7_10_peopleware 29

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.

7/10/2007 SE 652- 2007_7_10_peopleware 30

Exercise

Objective: Maximize your winningsRules:

Two teams (3 people each)Each Round:

Each team decides to Collude or Denounce (2 minutes to decide)Writes result on index card & hand inRound scoring:

Both teams collude: +2 eachOne team colludes, one denounces: -1 Colluder, +4 denouncerBoth teams denounce: 0 each

Random # of Rounds

7/10/2007 SE 652- 2007_7_10_peopleware 31

ExerciseRound 4+

Objective: Maximize your winningsRules:

Each team decides to Collude or Denounce (2 minutes to decide)Writes result on index card & hand inRound scoring:

Both teams collude: +1 eachOne team colludes, one denounces: -1 Colluder, +4 denouncerBoth teams denounce: 0 each

Random # of Rounds

7/10/2007 SE 652- 2007_7_10_peopleware 32

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 trustResponse: 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

7/10/2007 SE 652- 2007_7_10_peopleware 33

Growing & Maintaining Team Chemistry

Make a cult of qualityProvide lots of closure opportunitiesAllow team to feel unique or elitePreserve & protectNetwork model of leadership

Individuals provide occasional leadership in their strength areasManager 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 34

Due July 17 Class

Cycle 2 Launch:Cycle 2 Project PlanCycle 2 Measurement PlanUpdated Cycle 2 Project & Process docs based on Cycle 1 experience & audit