Top 10 Ways to Blow Up an Agile Project

Everyone knows agile is better. But if you do it just right, agile can be fragile, too. Follow these 10 'tips' and your project is bound to come off the rails.

By David Taber
Thu, May 30, 2013

CIOThis article is the second in a series of excerpts from the second edition of David Taber's Secrets of Success, which is scheduled to be released later this year.

In the spirit of David Letterman's "Top 10 Lists," it's time again for a list of worst practices that can make even the best agile team melt down. Here's David Taber-man's newest Top 10 List of things you can do to make that a reality. (Yes, I've seen specific examples of every one of these.)

10: Start a Crash Project With a Big Budget

The idea behind agile is to break down communication barriers and have software engineers work on what the users really need, rather than what somebody was willing to push through a committee and transcribe in a big document. Teams are small and tight.

How-to: 5 Ways to Send a Custom Software Project Off the Rails

In contrast, crash projects that throw all the resources in at the beginning don't allow anybody time to think or plan—yes, you do that in agile—so the team will tend to whipsaw for the first few weeks. If you really have a crash project, start it with a small team of architects and developers who've worked together successfully before and add team members only as they ask for them.

9: Demand Requirements Tomes, Data Dictionaries and Lots of Standards

These management artifacts are terrific for hardware projects or monolithic software applications, such as an application package or a network switching system, but those aren't the kind of projects where agile thrives. Most business apps are incremental adds and integrations with existing functionality. While agile projects involve careful thinking, it has no use for big documents or heavy processes such as Six Sigma, software lifecycle management, ITIL or ISO 9001. They only get in the way.

Case Study: Rapid Application Development the Zappos Way

The clean code folks take it one step further. They don't want any comments in the code, partly because comments are often be misleading, partly because commented code is an invitation for people who don't really understand the workings to break code by trying to improve it. User training cheat-sheets and recorded webinars are fine—but you'll notice that they, too, are short.

8: Demand Fixed Price, Fixed Schedule

Agile builds on an old joke: "Price, schedule, features and quality; pick three." By doing software in a fundamentally different way—one that's user-centered, conducts tests first and constantly negotiates and re-prioritizes requirements—agile dramatically reduces waste, because the stuff you really didn't need never gets started in the first place.

Continue Reading

Our Commenting Policies