Team Software Project (TSP) July 10, 2007 Peopleware & Post Mortem

1. Team Software Project (TSP) July 10, 2007 Peopleware & Post Mortem 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) SE 652- 2007_7_10_peopleware

3. 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 SE 652- 2007_7_10_peopleware

4. Class Outline Post-Mortem Presentations Peopleware topics Mythical Man Month SE 652- 2007_7_10_peopleware

5. Team Post Mortem Presentations

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 budget Edward Yourdon Project Success Study – 500 projects 15% cancelled, aborted, postponed For projects > 25 staff years, 25% fail Tom DeMarco & Timothy Lister 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” SE 652- 2007_7_10_peopleware

8. Management Managers concede that people issues exist, but tend to manage technical issues. Why? 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! 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? SE 652- 2007_7_10_peopleware

11. 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!” 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 Result Slip typically not evident until late in the project Absolute worst time: Project fully staffed Consumers & downstream teams geared up to proceed SE 652- 2007_7_10_peopleware

13. 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 SE 652- 2007_7_10_peopleware

14. 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! SE 652- 2007_7_10_peopleware

15. 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 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? 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! SE 652- 2007_7_10_peopleware

18. Quality Associate self-esteemQuantity 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 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! 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 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! 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! 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 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 grew Created a team personality (name, dress, appearance, socially) Delighted in finding defects Came to be feared SE 652- 2007_7_10_peopleware

25. How Do I Get One? Common goals Hope & Don’t practice behaviors that kill the seedling SE 652- 2007_7_10_peopleware

26. 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 SE 652- 2007_7_10_peopleware

27. “Most organizations don’t set out consciously to kill teams … They just act that way.” SE 652- 2007_7_10_peopleware

28. Open Kimono Trust 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. 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 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 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 Kimono Check-up / Parkinsonian patrol Open Kimono Off-premise development meetings w/o supervision The best managers take chances on their people 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 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 SE 652- 2007_7_10_peopleware

34. 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 SE 652- 2007_7_10_peopleware