Agile Methodologies Turn Dev Team into 'Cargo Cult'

Software development is prone to fads, going back to the days of "goto Considered Harmful." One current fad goes under the general name of " Agile methods;" some of its variants are extreme programming, the SCRUM methodology and Alastair Cockburn's Crystal Clear Methodology.
Now, I'm the last guy to run down Agile methodologies, but...let me tell you a story.
About two years ago, I joined a project to build an appliance to Do A Good Thing. I'm changing the names and details to protect, well, primarily me, but innocents were involved. In any case, the details of what we were doing are unimportant; what matters is how we did it.
All of us team members were survivors of another much larger project. That project had been done with outsourcing to a CMM Level 5 organization, with great care in the methodology at our end and with careful detailed project management overall. The project consumed tens of millions of dollars and years of overtime. It failed utterly.
The whole experience was traumatic. None of us wanted to repeat it. Some of us advocated adopting Agile methods, which had generated plenty of good reports. Since it was clear that the last thing anyone would have said about the last project was that it was "agile," adopting Agile seemed like a good idea.
We couldn't adopt an Agile methodology whole, though. We had to adapt to our corporate environment. User stories or use cases sounded like a great idea; we'd do use cases. Continuous integration would be great. Incremental development was a good idea too, so we'd do that. And extreme programming uses a morning " stand up meeting," which some of us had used before; we'd have a standup meeting.
The problems started when we tried to integrate these methods into our existing environment. First, management demanded that we estimate-and commit to-a schedule and budget. You can't do that without knowing what you'll be doing, so we built our use cases and created a schedule. Several months later, we had hundreds of use cases, and the local Microsoft Project wizard had a schedule estimated down to the day।

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.
Reference : http://www.pcworld.com/article/149586/2008/08/.html?tk=rss_news