This is a list of mistakes that are repeated again and again in different software development projects and for this reason called "Classic Mistakes". These mistakes all lengthen a project time to schedule, often so much that the whole project get out of scope, and for this reason should be avoided at all costs. If you do not avoid these mistake it is almost impossible that can reap the profit from a Rapid Development or Agile team practise.
These notes are taken in large parts from the book "Rapid Development" written by Steve McConell
Here are some od the people-related classic mistakes.
1: Undermined motivation.
Study after study has shown that motivation propberly has a larger effect on productivity and quality than any other factor (Boehm 1981). In a case stody, management took steps that undermined morale throughout the project - from given a hokey pep talk at the begining to requiring overtime in the middle, from going on 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.
2: Week personnel.
After motivation, either the individual capabilities of the team members or their relationship as a team probably has a greater influence on producitivity (Boehm 1981, Lakhanpal 1993). Hiring from the bottom of the barrel will threaten a rapid-development effort. In a case study, personnel sellection where made with an eye toward who could be hired fastest insted of who would get the most work done over the life of the project. That practise gets the project off to a quick start but doesn't set it up for rapid completion.
3. Uncontrolled problem employees.
Failure to deal with problem personnel also threatens development speed. This is a common problem and has been well-understood at least since Gerald Weinberg published "Psychology of Computer Programming" in 1971. Failure to take action to deal with a problem employee is the most common complaint that team members have about their leaders (Larson and LaFasto 1989). In a case study, the team knew that a person was a bad apple, but the team lead didn't do anything about it. The result - redoing all of his work - was predictable.
4: Heroic.
Some software developers place a hight emphasis on project heroics, thinking that certain kind of heroic can be beneficial (Bach 1995). But emphasising heroics in any form usually does more harm than good. in a case study, mid-level management placed a higher premium on can-do attributes than on steady and consistent progress and meaningful progress reporting. The result was a pattern of scheduling brinkmanship in which impending schedule slips weren't detected, acknowledged, or reported up the management chain until the last minute. A small development team and its immediate management held an entire company hostage because they wouldn't admit that they were having trouble meeting their schedule. An emphasis on heroics encourages extreme risk taking and discourages cooperation among the many stakeholders in the software development process.
Some managers encourage heroic behaviour when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate and some times gloomy status reporting, such project managers undercut their ability to take corrective action. They don't even know they need to take corrective action until the damage has been done. As Tom DeMarco says, can-do attitudes escalate minor setbacks into true disasters (DeMarco 1995).
5: Adding people to a late project.
This is perhaps the most classic of the classic mistakes. When a project is behind, adding people can take more productivity away from existing team members than it adds through new ones. Fred Brooks likened adding people to a late project to pouring petrol on a fire (Brooks 1975).
6: Noisy, crowded offices.
Most developers rate their working conditions as unsatisfactory. About 60 percent report that they are nether sufficiently quiet nor sufficiently private (DeMarco and Lister 1987). Workers who occupy quiet, private offices tend to perform significantly better than workers who occupy noisy, crowed work bays or cubicles. Noisy, crowed work environments lengthen development schedules.
7: Friction between developers and customers.
Friction between developers and customers can arise in several ways. Customers may feel that developers are not cooperative when they refuse to sign up for the development schedule that the customers want or when they fail to deliver on their promises. Developers may feel that customers unreasonably insisting on unrealistic schedules or requirements changes after the requirements have been base-lined. There might simply be personality conflicts between the two groups.
The primary effect of this friction is poor communication, and the secondary effects of poor communication include poorly understood requirements, poor user-interface design, and, in worst case, customers' refusing to accept the completed product. On average, friction between customers and software developers becomes so severe that both parties consider cancelling the project (Jomes 1994). Such friction is time-consuming to overcome, and it distracts both customers and developers from real work on the project.
8: Unrealistic expectations.
One of the most common causes of friction between devlopers and their customers or managers is unrealistic expectations. In a case study project manager had no sound reason to think that a program could be developed in 6 months, but that's when the company's executive committee wanted it done. His manager inability to correct that unrealistic expectation was a major source of problems.
In other cases, 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.
Although unrealistic expectations do not in themselves lengthen development schedules, they contribute to the perception that development schedules are too long, and that can be almost as bad. A Standish Group survey listed realistic expectations as one of the top five factors needed to ensure the success of an in-house business-software project (Standish Group 1994).
9: Lack of effective project sponsorship buy-in.
High-level project sponsorship is necessary to support many aspects of rapid development, including realistic planning, change control, and the introduction of new development practises. Without an effect executive sponsor, other hight-level personnel in your organisation can force you to accept unrealistic deadlines or make changes that undermine your project. Australian consultant Bob Thomsett agues that lack of en effective executive sponsor virtually guarantees project failure (Thomsett 1995).
10: Lack of stockholder buy-in.
All major players in a software development effort must buy in to the project. That includes the executive sponsor, team leader, team members, marketing staff, end-users, customers, and anyone else who has a stake in it. The close cooperation that occurs only when you have complete buy-in from all stakeholders allows for precise coordination of a rapid-development effort that is impossible to attain without good buy-in.
11: Lack of user input.
The Standish Group survey found that the number one reason that IS projects succeed is because of user involvement (Standish Group 1994). Projects without early end-user involvement risk misunderstanding the projects' requirements and are vulnerable to time consuming feature creep later in the project.
12: Politics placed over substance.
Larry Constantine reported on four teams that had four different kind of political orientation (Constantine 1995a). "Politicians" specialised in "managing up", concentrating on relationships with their managers. "Researchers" concentrated on scouting out and gathering information. "Isolationists" kept to themselves, creating project boundaries that kept closed to non team members. "Generalists" did a little bit of everything: they tended their relationships with their managers, performed research and scouting activities, and coordinated with other teams though the course of their normal work-flow. Constantine reported that initially the political and generalist teams where both well regarded by top management. But after a year a half, the political team was ranked dead last. Putting politics over results is fatal to speed-oriented development.
13: Wishful thinking.
It is amazing how many problems in software development boil down to wishful thinking. How many times have you heard statements like these from different people:
"None of the team members really believed that they could complete the project according to the schedule they were given, but they thought that maybe if everyone worked hard, and nothing went wrong, and they got a few lucky breaks, they might be able to pull it of."
"Our team hasn't done much work to coordinate the interface among the different parts of the product, but we have all been in good communication about other things, and the interface are relatively simple, so it will probably take only a day or two to shake out the bugs."
"We know that we went with the low-ball contractor on the database subsystem, and it was hard to see how they were going to complete the work with the staffing levels they specified on their proposal. They will probably deliver on time."
"We don't need to show the final round of changes of the prototype to the customer. I am sure we know what they want to by now."
"The team is saying that it will take an extraordinary effort to meet the deadline, and they missed their first milestone by a few days, but I think they can bring this one in on time."
Wishful thinking isn't just optimism. It is closing your eyes and hoping something works when you have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blowups at the end of a project. It undermines meaningful planning and may be at the root of more software problems than all other causes combined.
Process.
Process related mistakes slow down projects because they squander people's talents and efforts. here are some of the worst process related mistakes.
14. Over optimistic schedules.
The challenges faced by someone building a 3-month application are quite different from the challenges faced by someone building a 1-year application. Setting an overly optimistic schedule sets a project up for failure by under-scoping the project, undermining effective planning, and abbreviating critical upstream development activities such as requirements analysis and design. It also puts excessive pressure on developers, which hunts long term developers morale and productivity.
15. Insufficient risk management.
Some mistakes are not common enough to be considered classic. Those are called "risks". As with the classic mistakes, if you don't actively manage risks, only one thing has to go wrong to change your project from a rapid development project to a slow development project one. The failure to manage such risks is a classic mistake.
16. Contractor failure.
Companies sometime contract out pieces of a project when they are to rushed to do the work in-house. But contractors frequently deliver work that's late, that's of unacceptably low quality, or that fails to meet specifications (Boehm 1989). Risks such as unstable requirements or ill-defined interface can be magnified when you bring a contractor into the picture. If the contractor relationship isn't managed carefully, the use of contractors can slow a project down rather than speed it up.
17. Insufficient planning.
If you don't plan to achieve rapid development, you can't expect to achieve it.
18. Abandonment of planning under pressure.
Project teams make plans and then routinely abandon them when they run into schedule trouble (Humphrey 1989). The problem isn't so much in abandoning the plan as in failing to create a substitute, and failing into code and fix mode insted.
19. Wasted time during the fuzzy front end.
The "fuzzy front end" is the time before a project starts, the time normally spent in the approval and budgeting process. It is not uncommon for a project to spent months or years in the fuzzy front end and then to come out of the gates with an aggressive schedule. It is much easier and cheaper and less risky to save a few weeks or months in the fuzzy front end than it is to compress a development schedule by the same amount.
20. Shortchanged upsteam activities.
Projects that are in a hurry try to cut out nonessential activities, and since requirements analysis, architecture, and design don't directly produce code, they are easy targets. On one disastrous project when asked to see the design. The team lead told, "We didn't have time to do a design".
The result of this mistake, also known as "jumping into code", are all too predictable. Projects that skim on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it probably in the first place. If you can't find 5 hours to do the job right the first time, where are you going to find 50 hours to do it right later?
21. Inadequate design.
A special case of shortchanging upstream activities is inadequate design. Rush projects undermine design by not allocating enough time for it and by creating a pressure cooker environment that makes thoughtful consideration of design alternatives difficult. The design emphasis is on expediency rather than quality, so you tend to need several ultimately time consuming design cycles before you can finally complete the system.
22. Shortchanged quality assurance.
Projects that are in a hurry often cut corners by eliminating design and code reviews, eliminating test planing, and performing only perfunctory testing. Shortcutting 1 day of QA activity early in the project is likely to cost from 3 to 10 days of activity downstream (Jones 1994). This shortcut undermines development speed.
23. Insufficient management controls.
Before you can keep a project on track, you have to be able to tell whether it's on track in the first place.
24. Premature or overly frequent convergence.
Shortly before a product is scheduled to be released, there is a push to prepare the product for release - improve the product's performance, print final documentation, incorporate final help-system hooks, polish the installation program, stub out functionality that's not going to be ready on time, and so on. On rush projects, there is a tendency to force convergence early. Since it's not possible to force the product to converge when desired, some rapid development projects try to force convergence a half dozen times or more before they finally succeed. The extra convergence attempts don't benefit the product. They just waste time and prolong the schedule.
25. Omitting necessary tasks from estimates.
If people don't keep careful records of previous projects, they forget about the less visible tasks, but those tasks add up. Omitted effort often adds about 20 to 30 percent to the development schedule (van Genuchten 1991).
26. Planning to catch up later.
One kind of re-estimation is responding inappropriately to a schedule slip. If you are working on a 6-month project, and it takes you 3 moths to meet your 2-month milestone, what do you do? Many projects simple plan to catch up later, but they never do. You learn more about the product as you build it, including more about what it will take to build it. That learning needs to be reflected in the re-estimated schedule.
Another kind of re-estimation mistake arises from product changes. If the product you are building changes, the amount of time need to build it change to. Piling on new features without adjusting the schedule guarantees that you will miss your deadline.
27. Code-like-hell programming.
Some organisations think that fast, loose, all as you go coding is a route to rapid development. If the developers are sufficiently motivated, they reason, they can overcome any obstacles. This is fare from the truth. This approach is sometime presented as an "entrepreneurial" approach to software development, but it is really just a cover for the old Code and Fix paradigm combined with an ambitious schedule, and that combination almost never works. It is an example of two wrongs not making a right.
Product.
Here are classic mistakes related to the way the product is defined.
28. Requirements gold-plating.
Some projects have more requirements than they need, right from the beginning. Performance is stated as a requirement more often than it need to be, and that can unnecessarily lengthen a software schedule. Users tend to be less interested in complex features than marketing and development are, and complex features add disproportionately to a development schedule.
29. Feature creep.
Even if you are successful at avoiding requirements gold-plating, the average project experiences about 25-percent change in requirements over its lifetime (Jones 1994). Such a change can produce at least a 25-percent addition to the software schedule, which can be fatal to a rapid development project.
30. Developer gold-plating.
Developers are fascinated by new technology and are sometime anxious to try out new features of their language or environment or to create their own implementation of a slick feature they saw in another product - whether or not it's required in their product. The effort required to design, implement, test, document and support features that are not required lengthens the schedule.
31. Push-me, pull-me development.
One bizarre negotiating ploy occurs when a manager approves a schedule slip on a project that is progressing slower than expected and then adds completely new tasks after the schedule change. The underlying reason for this is hard to fathom, because the manager who approves the schedule slip is implicitly acknowledging that the schedule was in error. But once the schedule has been corrected, the same person takes explicit action to make it wrong again. This can't help but undermine the schedule.
32. Research-oriented development.
Seymour Cray, the designer of the Cray super computers, says that he does not attempt to exceed engineering limits in more than two areas at a time because the risk of failure is too high (Gilb 1998). Many software projects could learn a lesson from Cray. If your project stains the limits of computer science by requiring the creation of new algorithms or new computing practises, you are not doing software development; you are doing software research. Software development schedules are reasonably predictable; software research schedules are not even theoretically predictable.
If you have product goals that push the state of the art - algorithms, speed, memory usage, and so on - you should assume that your scheduling is highly speculative. If you are pushing the state of the art and you have any other weakness in your project - personal shortage, personal weaknesses, vague requirments, unstable interfaces with outside contractors - you can throw predictable scheduling out the window. If you want to advance the state of the art, by all means, do it. But don't expect to do it rapidly!
Technology.
The technology classic mistakes have to do with the use and misuse of modern technology.
33. Silver-bullet syndrome.
When project teams latch onto a single new practise, new technology, or rigid process and expect to solve their schedule problems, they are inevitably disappointed (Jones 1994).
34. Overestimated savings from new tools or methods.
Organisations seldom improve their productivity in giant leaps, no matter how many new tools or methods they adopt or how good they are. Benefits of new practises are partially offset by the learning curves associated with them, and learning to use new practises to their maximum advantages take time. New practises also entail new risks, which you are likely to discover only using them. You are more likely to experience slow, steady improvement on the order of a few percent per project than you are to experience dramatic gains.
A special case of overestimated savings arises when projects reuse code from previous projects. This kind of reuse can be a very effective approach, but the time saving is rarely as dramatic as expected.
35. Switching tools in the middle of a project.
This is an old standby that hardly ever works. Sometime it can make sense to upgrade incrementally within the same product line, from version 3 to version 3.1 or sometimes even to version 4. But the learning curve, rework, and inevitable mistakes made with a totally new tool usually cancel out any benefit when you are in the middle of a project.
36. Lack of automated source-code control.
Failure to use automated source code control exposes projects to needless risks. Without it, if two developers are working on the same part of a program, they have to coordinate their work manually. They might agree to put the latest version of each file into a master directory an to check with each other before copying files into that directory. But someone invariably overwrites someone else's work. People develop new code to out of date interfaces and then have to redesign their code when they discover that they where using the wrong version of the interface. Users report defect that you can't reproduce because you have no way to re-create the build they were using. On average, source code changes at a rate of about 10 percent per month, and manual source code control can't keep up (Jones 1994).
Written by Steve McConell. Edited and changed by Henrik Baastrup