Summary
...by presenting each of the developers with a $250 bonus.
(Note: I am reading from a kindle so no page number was available. All quotes are from chapter 3.)
This chapter started with a case study that exhibited many classic mistakes. Honestly, this case study was a good one and I felt stressed for everybody on the team. First, the schedule shinked to 6 months, and then hiring someone 2 of your teammates voted against. Company leadership getting mad when they couldn't make it to the 6 month mark. Everyone was putting in tons of overtime and the cherry on top was getting \$250 in bonus. I was offended by that meager offering on behalf of team. They set the team up to fail, then when the team failed they were blamed for it and to show the company's "appreciation" was to give breadcrumbs. No wonder everyone quit.
Classic mistakes are made because they have a "seductive appeal."
The first set of mistakes discussed are people-related mistakes. These include: undermined motivation, weak personnel, uncontrolled problem employees, heroics, adding people to a late project, noisy, crowded offices, friction between developers and customers, unrealistic expectations, lack of effective project sponsorship, lack of stakeholder buy-in, lack of user input, politics placed over substance, and wishful thinking.
The second set of mistakes discussed are process-related mistakes. These include: overly optimistic schedules, insufficient risk management, contractor failure, abandonment of planning under pressure, wasted time during the fuzzy front end, shortchanged upstream activities, inadequate design, shortchanged quality assurance, insufficient management controls, premature or overly frequent convergence, omitting necessary tasks from estimates, planning to catch up later, and code-like-hell programming.
The third set of mistakes discussed are product-related mistakes. These include: requirements gold-plating, feature creep, developer gold-plating, push-me, pull-me negotiation, and research-oriented development.
The fourth set of mistakes discussed are technology-related mistakes. These include: silver-bullet syndrome, overestimated savings from new tools or methods, switching tools in the middle of a project, and lack of automated source-code control.
Every single one of these mistakes could spell a pitfall for any development strategy. ".. they have delivered yet another project behind schedule or over budget or both." The rest of this book is most likely going to teach us how to develop properly adn not make these mistakes.
Attention Grabbers
- Undermined Motivation. "...management took steps that undermined morale throughout the project—from giving a hokey pep talk at the beginning to requiring overtime in the middle, from going on a long vacation while the team worked through the holidays to providing end-of-project bonuses that worked out to less than a dollar per overtime hour at the end."
- Noisy, crowded offices. May the lord save me open concept plans. I could rant about open offices for hours probably. They are the stupidest ever. Small offices with anywhere from 1-3 people in them should be the norm. No large rooms, no cubicles and NO OPEN OFFICES.
- Unrealistic expectations. Mike should have put his foot down and said no, we need 12 months. "...project managers or developers ask for trouble by getting funding based on overly optimistic schedule estimates. Sometimes they promise a pie-in-the-sky feature set."
- Shortchanged upstream activities. "We didn't have time to do a design."
- Code-like-hell programming, also known as "the old Code-and-Fix paradigm."
Questions
- What is the best process to avoid these mistakes?
- What does the front end of a project look like when you do it right and to avoid fuzzy front-ends?
- Is AI the silver-bullet technology today?
- I know that classic mistakes means they are made a lot however I would think some are worse than others. Which ones are most likely to be made today?
- What does good risk management even look like on a project?
