7/10/2007SE 652- 2007_7_10_peopleware1 Team Software Project (TSP) July 10, 2007 Peopleware & Post...
-
date post
22-Dec-2015 -
Category
Documents
-
view
213 -
download
0
Transcript of 7/10/2007SE 652- 2007_7_10_peopleware1 Team Software Project (TSP) July 10, 2007 Peopleware & Post...
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 Presentation
Final Cycle 1 Work Products (Project documents, quality records & source code)
7/10/2007 SE 652- 2007_7_10_peopleware 3
Remaining Lectures Plan/Discussion
July 10 – Cycle 1 Test Complete & Post-MortemCycle 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 Presentations
Peopleware topics
Mythical Man Month
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 schedule
50 – 100% over budgetEdward Yourdon
Project Success Study – 500 projects15% cancelled, aborted, postponed
For projects > 25 staff years, 25% failTom 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!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 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 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 11
Not!
Fallacy of man-monthAssumes 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 12
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
ResultSlip 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 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 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 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 dynamicse.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-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 23
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 24
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 grewCreated a team personality (name, dress, appearance, socially)
Delighted in finding defects
Came to be feared
7/10/2007 SE 652- 2007_7_10_peopleware 25
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 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 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 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: +2 each
One team colludes, one denounces: -1 Colluder, +4 denouncer
Both teams denounce: 0 each
Random # of Rounds
7/10/2007 SE 652- 2007_7_10_peopleware 31
ExerciseRound 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: +1 each
One team colludes, one denounces: -1 Colluder, +4 denouncer
Both 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 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
7/10/2007 SE 652- 2007_7_10_peopleware 33
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 leadershipIndividuals 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