Scheduling Nightmare
The schedule ran for more than a year. We wanted to do incremental deliveries, but "making a delivery" into the rest of the organization required additional effort. There was no scheduled time for that either; besides, it was silly to go through all that effort repeatedly. The schedule ended up with four increments, months apart. Of course, as the months went by, we learned more about the problem, and we had changes requested; that meant more use cases and more effort. We slipped the schedule somewhat, but there was a lot of whining in upper management about how we'd made commitments, so why couldn't we keep them? Besides, time to market was critical.
We based the project on an existing purchased code base, so the initial builds came relatively easily. However, we hadn't really allocated any effort in the schedule to the actual build and continuous integration support-we'd assumed the build would be right the first time. We also budgeted for a full-time system administrator, but then we lost the position, so we'd just have to make do on our own. Of course, system administration wasn't on the schedule either, but by now we'd committed, and commitments are important. End result: We used up the slack in the schedule.
We had arrived at an "Agile project" in which we did all the requirements up front and committed to them, had a "let's pretend" schedule that allocated time for a year in advance but didn't recognize all the tasks that were needed, and delivered our increments months and months apart.
Now this project was a "success." We delivered on time (at least after the last big slips), and the product is shipping. It just required major slips, big cost overruns and a month of seven-day weeks and 16-hour days. Over the year-end holidays.
We didn't have an Agile project at all: What we had was an Agile methodology cargo cult. Cargo cults developed in Melanesia, starting in the 19th century, but really grew during World War II. To the locals, the war meant cargo planes and cargo ships arriving, carrying everything from canned pineapple to Quonset huts. And it was good.
Then the war ended, and the cargo stopped. The locals responded by building their own runways, with airplanes made of bamboo and palm fronds, in hopes of attracting it back.
We heard that Agile methods were good, so we adopted Agile methods. But we managed to apply them in such a way that we actually built the project in a top-down, waterfall death march.
Now, class, what have we learned from this?
The first lesson: After a traumatic experience, people are willing to try almost anything to make things better-except actually to change.
Change is hard. A lot of the techniques we ended up applying, like end-to-end "committed" schedules, were things that let management pretend they were in control.
Second lesson: Watch out for cargo cults.
Agile methods are agile. If you have hours of meetings, a three-month increment, if you have to commit to a fixed set of deliverable functionality and a firm schedule months in advance, you're doing a waterfall project, or nearly so. Even if you call the requirements "use cases" and call the meetings "stand ups."
Most important lesson: Reality is your friend.
Sometimes, your friends tell you hard things. If you think you're doing Agile, you must step back every so often and ask: Can I respond to changing requirements easily? Do I have confidence that I could run the current build and see part of the system work? Am I seeing my family on a regular basis? Or did we plan to work overtime over Christmas to make our commitments? If you aren't seeing easy response to change, regular working deliveries and a regular schedule with a normal workweek, you have a cargo cult.
The saddest thing about cargo cults? The palm frond planes never actually delivered the canned pineapple.
Ad Choices
Comments