Agile teams build just two weeks of work at a time, sometimes less. They get feedback from the customer and allow the customer to decide what to work on first, what next, and when to ship.
2. Agile Is Skipping Requirements Not Worth Doing
When I worked on projects 10 years ago, we made a formal document called the functional specification. It neatly listed everything we intended to put into the software. Put another way, we had those 15 requirements that Gregory mentioned.
However, because we put everything together in one lump, we avoided the hard work of deciding what the priorities were. Everything, like in Dilbert-land, was Priority No. 1-and some of those requirements were just not worth doing.
That statement is not intended as an insult; it is more like a rule of physics. If you list all your software development ideas, some will offer more value for cost; others, less. Put the work in a priority order and you get to build the high-value things first. By the time you get to the bottom of the list, you could implement the feature, sure-but you could also call the project done, ship it early and do something else more valuable with your time.
That's what happened on my first agile project. The customer looked at what was left and decided we could call it done and ship early. I remember it fondly. That kind of thing never happened on a traditional project. Because projects were big and hard to initiate, we were more likely to get kitchen-sink behavior.
3. Agile Is Knowing the Old Way Isn't Fast, Either
The third reason to do agile is because I object to the fundamental premise that it's not faster. Remember the setup: A team that could get 15 requirements documents done in a year in a traditional model would be slower when moving to agile methods.
After years in organizations that tried to know everything up front, I consistently saw one thing: Projects were late and the project managers, who had been so certain, were now surprised. Things happened that they never could've predicted, and we'd say we "did the best we could under the circumstances.
My experience isn't unique. The sixth edition of Barbara C. McNurlin and Ralph H. Sprague's Information Systems Management In Practice claims that the average cost overrun of a large ERP project is 179 percent, the schedule overrun 230 percent. In other words, comparing an agile team that can't get something done in a year to a more traditional team that can is a false comparison. In a year, the traditional team will have 12-and-a-half requirements done, a mess on the floor and nothing to ship.
Sign up for CIO Asia eNewsletters.