Classic Mistakes Enumerated Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes." Most of the mistakes have a seductive appeal. Do you need to rescue a project that's behind schedule? Add more people! Do you want to reduce your schedule? Schedule more aggressively! Is one of your key contributors aggravating the rest of the team? Wait until the end of the project to fire him! Do you have a rush project to complete? Take whatever developers are available right now and get started as soon as possible! Developers, managers, and customers usually have good reasons for making the decisions they do, and the seductive appeal of the classic mistakes is part of the reason these mistakes have been made so often. But because they have been made so many times, their consequences have become easy to predict, and they rarely produce the results that people hope for. This section enumerates three dozen classic mistakes. I have personally seen each of these mistakes made at least once, and I've made many of them myself. The common denominator in this list is that you won't necessarily get rapid development if you avoid the mistake, but you will definitely get slow development if you don't avoid it. If some of these mistakes sound familiar, take heart. Many other people have made the same mistakes, and once you understand their effect on development speed you can use this list to help with your project planning and risk management. Some of the more significant mistakes are discussed in their own sections in other parts of this book. Others are not discussed further. For ease of reference, the list has been divided along the developmentspeed dimensions of people, process, product, and technology. People Here are some of the people-related classic mistakes. #1: Undermined motivation. Study after study has shown that motivation probably has a larger effect on productivity and quality than any other factor (Boehm 1981). In Case Study 3-1, management took steps that undermined morale throughout the project--from giving a hokey pep talk at the beginning to requiring overtime in the middle and going on a long vacation while the team worked through the holidays to providing bonuses that work out to less than a dollar per overtime hour at the end. #2: Weak personnel. After motivation, either the individual capabilities of the team members or their relationship as a team probably has the greatest influence on productivity (Boehm 1981, Lakhanpal 1993). Hiring from the bottom of the barrel will threaten a rapid development effort. In the case study, personnel selections were made with an eye toward who could be hired fastest instead of who would get the most work done over the life of the project. That practice 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 Case Study 3-1, the team knew that Chip was a bad apple, but the team lead didn't do anything about it. The result--redoing all of Chip's work--was predictable. #4: Heroics. Some software developers place a high emphasis on project heroics, thinking that the certain kinds of heroics can be beneficial (Bach 1995). But I think that emphasizing heroics in any form usually does more harm than good. In the case study, mid-level management placed a higher premium on can-do attitudes 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 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 this behavior when they focus too strongly on can-do attitudes. By elevating can-do attitudes above accurate-and-sometimes-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 setback 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 gasoline on a fire (Brooks 1975). #6: Noisy, crowded offices. Most developers rate their working conditions as unsatisfactory. About 60 percent report that they are neither 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, crowded work bays or cubicles. Noisy, crowded 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 requirements have been baselined. 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 the worst case, customers' refusing to accept the completed product. On average, friction between customers and software developers is so severe that both parties consider canceling the project (Jones 1994). Such friction is time-consuming to overcome, and it distracts both customers and developers from the real work of the project. #8: Unrealistic expectations. One of the most common causes of friction between developers and their customers or managers is unrealistic expectations. In Case Study 3-1, Bill had no reason to think that the Giga-Quote program could be developed in six months except for the fact that the company needed it in that amount of time. Mike's failure 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. High-level project sponsorship is necessary to support many aspects of rapid development including realistic planning, change control, and the introduction of new development practices. Without an effective project sponsor, other high-level personnel in your organization can force you to accept unrealistic deadlines or make changes that undermine your project. Australian consultant Rob Thomsett argues that lack of an effective project sponsor virtually guarantees project failure (Thomsett 1995). #10: Lack of stakeholder buy-in. All of the major players in a software-development effort must buy in to the project. That includes the executive sponsor, team leader, team members, marketing, 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). #12: Politics placed over substance. Larry Constantine reported on four teams that had four different kinds of political orientations (Constantine 1995a). "Politicians" specialized 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 they 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 through the course of their normal workflow. Constantine reported that initially the political and generalist teams were both well regarded by top management. But after a year and a half, the political team was ranked dead last. Putting politics over results is fatal to speed-oriented development. #13: Wishful thinking. I am amazed at how many problems in software development boil down to wishful thinking. How many times have you heard statements like these: "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 just might be able to pull it off." "Our team hasn't done very much work to coordinate the interfaces among the different parts of the product, but we've all been in good communication about other things, and the interfaces are relatively simple, so it'll 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 in their proposal. They didn't have as much experience as some of the other contractors, but maybe they can make up in energy what they lack in experience. They'll probably deliver on time." "We don't need to show the final round of changes to the prototype to the customer. I'm sure we know what they want 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's 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: Overly optimistic schedules. The challenges faced by someone building a three-month application are quite different than the challenges faced by someone building a one-year application. Setting an overly optimistic schedule sets a project up for failure by underscoping 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 hurts developer morale and productivity. This was a major source of problems in Case Study 3-1. #15: Insufficient risk management. Some mistakes have been made often enough to be considered classics. Others are unique to specific projects. 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 slowdevelopment one. Failure to manage risks is one of the most common classic mistakes. #16: Contractor failure. Companies sometimes contract out pieces of a project when they are too 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 illdefined interfaces 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. Projects 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 then falling into code-and-fix mode instead. In Case Study 3-1, the team abandoned its plan after it missed its first delivery, and that's typical. The result was that work after that point was uncoordinated and awkward--to the point that Jill even started working on a project for her old group part of the time and no one even knew it. #19: Wasted time during the fuzzy front end. The "fuzzy front end" is the time before the project starts, the time normally spent in the approval and budgeting process. It's not uncommon for a project to spend months or years in the fuzzy front end and then to come out of the gates with an aggressive schedule. It's 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 upstream 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 disaster project that I took over, I asked to see the design. The team lead told me, "We didn't have time to do a design." Also known as "jumping into coding," the results of this mistake are all too predictable. In the case study, a design hack in the bar-chart report was substituted for quality design work. Before the product could be released, the hack work had to be thrown out and the higher quality work had to be done anyway. Projects that skimp on upstream activities typically have to do the same work downstream at anywhere from 10 to 100 times the cost of doing it properly in the first place (Fagan 1976; Boehm and Papaccio 1988). If you can't find the 5 extra hours to do the job right the first time, where are you going to find the 50 extra 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 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 planning, and performing only perfunctory testing. In the case study, design reviews and code reviews were given short shrift in order to achieve a perceived schedule advantage. As it turned out, when the project reached its feature-complete milestone it was still too buggy to release for five more months. This result is typical. Short-cutting a day of QA activity early in the project is likely to cost you 3 to 10 days of activity downstream (Jones 1994). This inefficiency undermines development speed. #23: Insufficient management controls. In the case study, there were few management controls in place to provide timely warnings of impending schedule slips, and the few controls there were in place at the beginning were abandoned once the project ran into trouble. Before you can keep a project on track, you have to be able to tell whether it's on track. #24: Premature or too 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 a development schedule (van Genuchten 1991). #26: Planning to catch up later. If you're working on a six-month project, and it takes you three months to meet your two-month milestone, what do you do? Many projects simply 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 schedule. Another kind of reestimation mistake arises from product changes. If the product you're building changes, the amount of time you need to build it changes too. In Case Study 3-1, major requirements changed between the original proposal and the project start without any corresponding reestimation of schedule or resources. Piling on new features without adjusting the schedule guarantees that you will miss your deadline. #27: Code-like-hell programming. Some organizations 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. For reasons that will become clear throughout this book, this is far from the truth. The entrepreneurial model is often a cover for the old code-and-fix paradigm combined with an ambitious schedule, and that combination almost never works. It's an example of two wrongs not making a right. Product Here are some classic mistakes are 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 needs 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're successful at avoiding requirements gold-plating, the average project experiences about a 25-percent change in requirement 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 sometimes 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 negotiation. One bizarre negotiating ploy occurs when a manager approves a schedule slip on a project that's 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 supercomputers, 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 1988). Many software projects could learn a lesson from Cray. If your project strains the limits of computer science by requiring the creation of new algorithms or new computing practices, you're not doing software development; you're 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 expect great uncertainty in your scheduling. If you're pushing the state of the art and you have any other weaknesses in your project--personnel shortages, personnel weaknesses, vague requirements, 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 remaining classic mistakes have to do with the use and misuse of modern technology. #33: Silver-bullet syndrome. In the case study there was too much reliance on the advertised benefits of previously unused technologies (report generator, object oriented design, and C++) and too little information about how well they would do in this particular development environment. When project teams latch onto a single new methodology or new technology and expect it to solve their schedule problems, they are inevitably disappointed (Jones 1994). #34: Overestimated savings from new tools or methods. Organizations seldom improve their productivity in giant leaps, no matter how good or how many new tools or methods they adopt. Benefits of new practices are partially offset by the learning curves associated with them, and learning to use new practices to their maximum advantage takes time. New practices also entail new risks, which you're likely to discover only by 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. The team in Case Study 3-1 should have planned on, at most, a 10-percent gain in productivity from the use of the new technologies instead of assuming that they would nearly double their productivity. A special case of overestimated savings arises when projects reuse code from previous projects. This can be a very effective approach, but the time savings is rarely as dramatic as expected. #35: Switching tools in the middle of a project. This is an old standby that hardly ever works. Sometimes 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're 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 the program, they have to coordinate their work manually. They might agree to put the latest versions of each file into a master directory and to check with each other before copying files into that directory. But someone always 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 were using the wrong version of the interface. Users report defects that you can't reproduce because you have no way to recreate the build they were using. On average, source code changes at a rate of about 10 percent per month, and manual sourcecode control can't keep up (Jones 1994). Table 3-1 contains a complete list of classic mistakes: Table 3-1. Summary of Classic Mistakes People-Related Mistakes Process-Related Mistakes Product-Related Mistakes Technology-Related Mistakes 1. Undermined motivation 14. Overly optimistic schedules 28. Requirements goldplating 33. Silver-bullet syndrome 2. Weak personnel 16. Insufficient risk management 29. Feature creep 34. Overestimated savings from new tools or methods 3. Uncontrolled problem employees 17. Contractor failure Insufficient planning 4. Heroics 5. Adding people to a late project 6. Noisy, crowded offices 7. Friction between developers and customers 18. Abandonment of planning under pressure 19. Wasted time during the fuzzy front end 31. Push me, pull me negotiation 32. Research-oriented development 20. Shortchanged upstream activities 21. Inadequate design 8. Unrealistic expectations 22. Shortchanged quality assurance 9. Lack of effective project sponsorship 23. Insufficient management controls 10. Lack of stakeholder buy-in 24. Premature or too frequent convergence 11. Lack of user input 25. Omitting necessary tasks from estimates 12. Politics placed over substance 30. Developer goldplating 26. Planning to catch up later 13. Wishful thinking 27. Code-like-hell programming This material is Copyright © 1996 by Steven C. McConnell. All Rights Reserved. 35. Switching tools in the middle of a project 36. Lack of automated source-code control CASE STUDY: Giga Safe by Steven C. McConnell Mike was eating lunch in his office and looking out his window on a bright April morning. He was a technical lead for Giga Safe, a medical insurance company. "Mike, you got the funding for the Giga-Quote program! Congratulations!" It was Bill, Mike's boss. "The executive committee loved the idea of automating our medical insurance quotes. It also loved the idea of uploading the day's quotes to the head office every night so that we always have the latest sales leads online. I've got a meeting now, but we can discuss the details later. Good job on that proposal!" Mike had written the proposal for the Giga-Quote program months earlier, but his proposal had been for a standalone PC program without any ability to communicate with the head office. Oh well. This would give him a chance to lead a client-server project in a modern GUI environment, and that's what he wanted. They had almost a year to do the project, and that should give them plenty of time to add a new feature. Mike picked up the phone and dialed his wife's number. "Honey, let's go out to dinner tonight to celebrate ..." The next morning, Bill met with Mike to discuss the project. "OK, Bill. What's up? This doesn't sound like quite the same proposal I worked on." Bill felt uneasy. Mike hadn't participated in the revisions to the proposal, but there hadn't been time to involve him. Once the executive committee heard about the Giga-Quote program, they'd taken over. "The executive committee loves the idea of building software to automate medical insurance quotes. But they want to be able to transfer the field quotes into the mainframe computer automatically. And they want to have the system done before our new rates take effect January 1. They moved the software-complete date you proposed up from March 1 to November 1, which shrinks your schedule to 6 months." Mike had estimated the job would take 12 months. He didn't think they had much chance of finishing in 6 months, and he told Bill so. "Let me get this straight," Mike said. "It sounds like you're saying that the committee added a big communications requirement and chopped the schedule from 12 months to 6?" Bill shrugged. "I know it will be a challenge, but you're creative, and I think you can pull it off. They approved the budget you wanted, and adding the communications link can't be that hard. You asked for 36 staff-months, and you got it. You can recruit anyone you like to work on the project and increase the team size too." Bill told him to go talk with some other developers and figure out a way to deliver the software on time. Mike got together with Carl, another technical lead, and they looked for ways to shorten the schedule. "Why don't you use C++ and object-oriented design?" Carl asked. "You'll be more productive than with C, and that should shave a month or two off the schedule." Mike thought that sounded good. Carl also knew of a report-building tool that was supposed to cut development time in half. The project had a lot of reports, so those two changes would get them down to about nine months. They were due for newer, faster hardware, too, and that could shave off a couple of weeks. If he could recruit really top-notch developers, that might bring them down to about seven months. That should be close enough. Mike took his findings back to Bill. "Look," Bill said. "Getting the schedule down to seven months is good, but it's not good enough. The committee was very clear about the six-month deadline. They didn't give me a choice. I can get you the new hardware you want, but you and your team are going to have to find some way to get the schedule down to six months or work some overtime to make up the difference." Mike considered the fact that his initial estimate had just been a ballpark guess and thought maybe he could pull it off in six months. "OK, Bill. I'll hire a couple of sharp contractors for the project. Maybe we can find some people with communications experience to help with uploading data from the PC to the mainframe." By May 1, Mike had put a team together. Jill, Sue, and Tomas were solid, in-house developers, and they happened to be unassigned. He rounded out the team with Keiko and Chip, two contractors. Keiko had experience both on PCs and the kind of mainframe they would interface with. Jill and Tomas interviewed Chip and recommended against hiring him, but Mike was impressed. He had communications experience and was available immediately, so Mike hired him anyway. At the first team meeting, Bill told the team that the Giga-Quote program was strategically important to the Giga Safe corporation. Some of the top people in the company would be watching them. If they succeeded, there would be rewards all around. He said he was sure that they could pull it off. After Bill's pep talk, Mike sat down with the team and laid out the schedule. The executive committee had more or less handed them a specification, and they would spend the next two weeks filling in the gaps. Then they'd spend six weeks on design, which would leave them four months for construction and testing. His seat-of-the-pants estimate was that the final product would consist of about 30,000 lines of code in C++. Everyone around the table nodded agreement. It was ambitious, but they'd know that when they signed up for the project. The next week, Mike met with Stacy, the testing lead. She explained that they should begin handing product builds over to testing no later than September 1, and should aim to hand over a feature-complete build by October 1. Mike agreed. The team finished the requirements specification quickly, and dove into design. They came up with a design that seemed to make a good use of C++'s features. They finished the design by June 15, ahead of schedule, and began coding like crazy to meet their goal of a first-release-to-testing by September 1. The project hadn't been entirely smooth. Neither Jill nor Tomas liked Chip, and Sue had also complained that he wouldn't let anyone near his code. Mike attributed the personality clashes to the long hours everyone was working. Nevertheless, by early August, they reported that they were between 85 and 90-percent done. In mid-August, the actuarial department released the rates for the next year, and the team discovered that they had to accommodate an entirely new rate structure. The new rating method required them to ask questions about exercise habits, drinking habits, smoking habits, recreational activities, and other factors that hadn't been included in the rating formulas before. C++, they thought, was supposed to shield them from the effects of such changes. They had been counting on just plugging some new numbers into a ratings table. But they had to change the input dialogs, database design, database access, and communications objects to accommodate the new structure. As the team scrambled to retrofit their design, Mike told Stacy that they might be a few days late releasing the first build to testing. As expected, the team didn't have a build ready by September 1, and Mike continued to assure Stacy that the build was only a day or two away. Days turned to weeks, and the October 1 deadline for handing over the feature-complete build to testing came and went. Development still hadn't handed over the first build to testing. Stacy called a meeting with Bill to discuss the schedule. "We haven't gotten a build from development yet," she said. "We were supposed to get our first build on September 1, and since we haven't gotten one yet, they've got to be at least a full month behind schedule. I think they're in trouble." "They're in trouble, all right," Bill said. "Let me talk to the team. I've promised 600 agents that they would have this program by November 1. We have to get that program out in time for the rate change." Bill called a team meeting. "This is a fantastic team, and you should be meeting your commitments," he told them. "I don't know what's gone wrong here, but I expect everyone to work hard and deliver this software on time. You can still earn your bonuses, but now you're going to have to work for them. As of now, I'm putting all of you on a 6-day-per-week, 10-hourper-day schedule until this software is done." After the meeting, Jill and Tomas grumbled to Mike about not needing to be treated like children, but they agreed to work the hours Bill wanted. The team slipped the schedule two weeks, promising a feature-complete build by November 15. That allowed for six weeks of testing before the new rates went into effect in January. The team released its first build to testing four weeks later on November 1 and met to discuss a few remaining problems areas. Tomas was working on report generation and had run into a roadblock. "The quote summary page includes a simple bar chart. I'm using a report generator that's supposed to generate bar charts, but the only way it will generate them is on pages by themselves. We have a requirement from the sales group to put the text and bar charts on the same page. I've figured out that I can hack up a report with a bar chart by passing in the report text as a legend to the bar-chart object. It's definitely a hack, but I can always go back and reimplement it more cleanly after the first release." Mike responded, "I don't see where the issue is. We have to get the product out, and we don't have time to make the code perfect. Bill has made it crystal clear that there can't be any more slips. Do the hack." Chip reported that his communications code was 95-percent done and that it worked, but he still had a few more tests to run. Mike caught Jill and Tomas rolling their eyes, but he decided to ignore it. The team worked hard through November 15, including working almost all the way through the nights of the 14th and 15th, but they still didn't make their November 15 release date. The team was exhausted, but on the morning of the 16th, it was Bill who felt sick. Stacy had called to tell him that development hadn't released its feature-complete build the day before. Last week he had told the executive committee that the project was on track. Another project manager, Claire, had probed into the team's progress, saying that she had heard that they weren't making their scheduled releases to testing. Bill thought Claire was uptight, and he didn't like her. He had assured her that his team was definitely on track to make their scheduled releases. Bill told Mike to get the team together, and when he did, they looked defeated. A month and a half of 60-hour weeks had taken their toll. Mike asked what time today they would have the build ready, but the only response he got was silence. "What are you telling me?" he said. "We are going to have the feature-complete build today, aren't we?" "Look, Mike," Tomas said. "I can hand off my code today and call it 'feature complete', but I've probably got three weeks of cleanup work to do once I hand it off." Mike asked what Tomas meant by "cleanup." "I haven't gotten the company logo to show up on every page, and I haven't gotten the agent's name and phone number to print on the bottom of every page. It's little stuff like that. All of the important stuff works fine. I'm 99-percent done." "I'm not exactly 100-percent done either," Jill admitted. "My old group has been calling me for technical support a lot, and I've been spending a couple hours a day working for them. Plus, I had forgotten until just now that we were supposed to give the agents the ability to put their names and phone numbers on the reports. I haven't implemented the dialogs to input that data yet, and I still have to do some of the other housekeeping dialogs too. I didn't think we needed them to make our 'feature complete' milestone." Now Mike started to feel sick too. "If I'm hearing what I think I'm hearing, you all are telling me that we're three weeks away from having feature complete software. Is that right?" "Three weeks at least," Jill said. The rest of the developers agreed. Mike went around the table one by one and asked the developers if they could completely finish their assignments in three weeks. One by one, the developers said that if they worked hard, they thought they could make it. Later that day, after a long, uncomfortable discussion, Mike and Bill agreed to slip the schedule three weeks to December 5 as long as the team promised to work 12 hour days instead of 10. Bill said he needed to show his boss that he was holding the development team's feet to the fire. The revised schedule meant that they would have to test the code and train the field agents concurrently, but that was the only way they could hope to release the software by January 1. Stacy complained that that wouldn't give QA enough time to test the software, but Bill overruled her. On December 5, the Giga-Quote team handed off the feature-complete Giga-Quote program to testing before noon and left work early to take a long-awaited break. They had worked almost constantly since September 1. Two days later, Stacy released the first bug list, and all hell broke loose. In two days, the testing group had identified more than 200 defects in the Giga-Quote program including 23 that were classified as 'Severity 1'-'Must Fix'-errors. "I don't see any way the software will be ready to release to the field agents by January 1," she said. "It will probably take the test group that long just to write the regression test cases for the defects we've already discovered, and we're finding new defects every hour." Mike called a staff meeting for eight o'clock the next morning. The developers were touchy. They said that although there were a few serious problems, a lot of the reported bugs weren't really bugs at all but were misinterpretations of how the program was supposed to operate. Tomas pointed to bug #143 as an example. "The test report for bug #143 says that on the quote summary page, the bar chart is required to be on the right side of the page rather than the left. That's hardly a Sev-1 error. This is typical of the way that testing overreacts to problems." Mike distributed copies of the bug reports. He tasked the developers to review the bugs that testing had assigned to them and to estimate how much time it would take to fix each one. When the team met again that afternoon, the news wasn't good. "Realistically, I would estimate that I have two weeks' worth of work just to fix the bugs that have already been reported," Sue said. "Plus I still have to finish the referential integrity checks in the database. I've got four weeks of work right, total." Tomas had assigned bug #143 back to testing, changing its priority from Sev-1 to Sev-3"Cosmetic Change." Testing had responded that Giga-Quote's summary reports had to match similar reports generated by the mainframe policy-renewal program, which were also similar to pre-printed marketing materials that the company had used for many years. The company's 600 agents were accustomed to giving their sales pitches with the bar chart on the right, and it had to stay on the right. The bug stayed at Sev-1, and that created a problem. "Remember the hack I used to get the bar chart and the report to print on the same page in the first place?" Tomas asked. "To put the bar chart on the right, I will have to rewrite this particular report from scratch, which means that I will have to write my own low-level code to do the report formatting and graphics." Mike cringed, and asked for a ballpark estimate of how long all that would take. Tomas said it would take at least 10 days, but he would have to look into it more before he would know for sure. Before he went home for the day, Mike told Stacy and Bill that the team would work through the holidays and have all of the reported defects fixed by January 7. Bill said he had almost been expecting this one and approved a four-week schedule slip before leaving for the four-week Caribbean cruise he had been planning since the previous summer. Mike spent the next four weeks holding the troops together. For four months, they had been working as hard as it was possible to work, and he didn't think he could push them any harder. They were at the office 12 hours a day, but they were spending a lot of time reading magazines, paying bills, and talking on the phone. They seemed to make a point of getting irritable whenever he asked how long it would take to get the bug count down. For every bug they fixed testing discovered two new ones. Bugs that should have taken minutes to fix had project-wide implications and took days instead. They soon realized there was no way they could fix all of the defects by January 7. On January 7, Bill returned from his vacation, and Mike told him that the development team would need another four weeks. "Get serious," Bill said. "I've got 600 field agents who are tired of getting jerked around by a bunch of computer guys. The executive committee is talking about canceling the project. You have to find a way to deliver the software within the next two weeks no matter what." Mike called a team meeting to discuss their options. He told them about Bill's ultimatum and asked for a ballpark estimate of when they could release the product, first just in weeks, then in months. The team was silent. No one would hazard a guess about when they might finally release the product. Mike didn't know what to tell Bill. After the meeting, Chip told Mike that he had accepted a contract with a different company that started February 3. Mike began to feel that it would be a relief if the project were canceled. Mike got Kip, the programmer who had been responsible for the mainframe side of the PC-tomainframe communications, reassigned to help out on the project and assigned him to fix bugs in the PC communications code. After struggling with Chip's code for a week, Kip realized that it contained some deep conceptual flaws that meant it could never work. Kip was forced to redesign and reimplement the PC side of the PC-to-mainframe communications link. As Bill rambled on at an executive meeting in the middle of February, Claire finally decided that she had heard enough and called a "stop work" on the Giga-Quote program. She met with Mike on Friday. "This project is out of control," she said. "I haven't gotten a reliable schedule estimate from Bill for months. This was a six-month project, and it's now more than three months late with no end in sight. I've looked over the bug statistics, and the team isn't closing the gap. You're all working such long hours that you're not even making progress anymore. I want you all to take the weekend off; then I want you to develop a detailed, step-by-step report that includes everything-and I do mean everything-that remains to be done on that project. I don't want you to force fit the project into an artificial schedule. If it's going to take another nine months, I want to know that. I want that report by end-of-work Wednesday. It doesn't have to be fancy, but it does have to be complete." The development team was glad to have the weekend off, and they attacked the detailed report with renewed energy the next week. It was on Claire's desk Wednesday. She had the report reviewed by Charles, a software engineering consultant who also reviewed the project's bug statistics. Charles recommended that the team focus its efforts on a handful of error-prone modules, that it immediately institute design and code reviews for all bug fixes, and that the team start working regular hours so that they could get an accurate measure of how much effort was being expended on the project and how much would be needed to finish. Three weeks later, in the first week in March, the open-bug count had ticked down a notch for the first time. Team morale had ticked up a notch, and based on the steady progress being made, the consultant projected that the software could be delivered-fully tested and reliable-by May 15. Since Giga Safe's semi-annual rate increase would go into effect July 1, Claire set the official launch date for June 1. Post Mortem The Giga-Quote program was released to the field agents according to plan on June 1. Giga Safe's field agents greeted it with a warm if somewhat skeptical reception. The Giga Safe corporation showed its appreciation for the development team's hard work by presenting each of the developers with a $250 bonus. A few weeks later, Tomas asked for an extended leave of absence, and Jill went to work for another company. The final Giga-Quote product was delivered in 13 months rather than 6, a schedule overrun of more than 100 percent. The developer effort including overtime consisted of 98 staff-months, which was a 170-percent overrun of the planned 36 staff-months. The final product was determined to consist of about 40,000 nonblank, noncomment lines of code in C++, which was about 33 percent more than Mike's seat-of-the-pants guess. As a product that was distributed to 600 in-house sites, Giga-Quote was a hybrid between a business product and a shrink-wrap product. A product of its size and type should normally have been completed in 11.5 months with 71 staff-months of effort. The project had overshot both of those nominals. Rapid Development: Taming Wild Software Schedules by Steven C. McConnell. Redmond, Wa.: Microsoft Press, 1996. ISBN: 1-55615-900-5. 
Purchase answer to see full attachment