By Steve McConnell (1996)
The effects of individual ability, individual motivation, team ability, and team motivation dwarf other productivity factors.
- Use estimate ranges
- Aim for accuracy, not precision (a larger range may be more accurate because of more uncertainty)
- Estimates early in a project are off by a factor of four. They slowly get better and aren’t correct until project completion
- The correct response to a missed milestone is to multiply the whole schedule by the magnitude of the slip. Or change the product or cost
Projects hardly ever make up lost time.
Programmers tend to underestimate their projects by 20 to 30 percent.
I am most opposed to overly optimistic scheduling because it doesn’t work. It doesn’t result in shorter actual schedules; it results in longer ones.
Projects that aim from the beginning at having the lowest number of defects usually also have the shortest schedules.
Given the same set of requirements, developers will create solutions that vary by as much as a factor of 10 in the amounts of code they require… If you’re on a rapid-development schedule, you can’t afford to create a pressure-cooker environment in which people are too rushed to find the solution that is one-tenth as expensive to implement as the others.
Developers derive some of their self-esteem from the products they develop. If they develop a high-quality product, they feel good. If they develop a low-quality product, they don’t feel as good.
If you feel that your developers won’t be able to build a high-quality product in the time available, let the developers come to that conclusion themselves.
In a survey of 8,000 projects, the Standish Group found that the number one reason that projects succeed is user involvement.
- “People will work harder to achieve their own goals than to achieve someone else’s”
- People must experience meaning in their work, responsibility for the outcome, and know the results of their efforts
- Reward as a gesture of appreciation, not as an incentive (intrinsic vs extrinsic motivation)
- Use the Hawthorne effect to your advantage: “Run every software project as an experiment”
- Should be on a mission
- Have a sense of identity
- Mutual trust
- Clear roles and accountabilities
- Fact-based decision-making
When you cut across this set of studies, the bottom line is that among groups with different backgrounds and different levels of experience, there is about a 5-to-1 difference in productivity. Among groups with similar backgrounds and similar levels of experience, there is about a 2.5-to-1 difference in productivity.
Group cohesiveness contributes more to productivity than project members’ individual capabilities or experience.
Make the team responsible for its actions rather than making individuals on the team responsible for their individual actions.