I’m working on an agile process now. Iterations are 4-6 weeks. But we’re on a multi-site team employing something akin to 60 developers and artists, many of them pretty senior, and we’re building a fairly massive client-server-SDK-content development environment. I work on the client app and right now we’re doing a lot of financial management stuff (the kind that has to be right).
The company I work for has done agile or similar sorts of things for a long time now. They’re pretty good at it. We get some pretty decent ratings and seem to mostly operate successfully.
From the trenches, I can say agile is good in some ways (sloppiness gets called out sooner, there is more focus on frequent end-to-end testing which is great in a client-server environment, and you’re always trying to take manageable bites). We couldn’t do a two week iteration with our size of project distributed over multiple sites. Sometimes even the 4 week iterations, if we count the QC cycle at the end, are pretty darn short.
You succeed, as one sharp reader pointed out, if you can get everyone working in parallel, if the overhead created by agile frequent releases isn’t too onerous, and if your utilization goes up. This is really what happens. You probably do work more, at least some of us senior folks always seem to be on a critical path and pushing to get stuff tight and solid for an iterative release. But the end result is we fairly frequently know where we’re at - risk is identified much more aggressively and mitigation actions are taken early on. That alone makes agile worth the price of admission.
And the customers get confidence when you deliver regular releases. Our project schedule was fifteen to eighteen months. We do deliveries about every 5-6 weeks. The customer sees progress, doesn’t get antsy that things are off the rails, and gets a chance to feedback regularly along the way. If you don’t think any of that has value, then you haven’t worked on many customer driven and funded projects. Also, as we almost always have some sort of release ‘canned and ready’, sales demos become much easier. And our customer can show it off to their customer and integration partners. That’s a big plus for them too.
Sometimes you bite off more than you can chew for an iteration - some parts of a task just have a heavily serialized nature or are innately tricky. That’s when agile hurts a bit because you are still pushing for your iteration endpoint and that means a harder push.
Our rule, and it is part of what keeps the customers coming back, is ‘always hit your dates’ and ‘always deliver core promised content’. Sure, we sometimes slip on the edges, on ‘good to have’ or ‘would have liked to’ aspects, but we always deliver core content on time. This is in part due to the dedicated team, but in part due to management being on top of things - agile keeps everyone more focused and problems get brought up, mitigations decided on. You don’t have time to screw around. You do, the iteration gets blown.
Agile works, but it does require a certain approach to project and risk management as well as a focus on regular builds for testing. Automation of testing and regular user driven smoke testing identify problems early and lead to better release quality. You don’t try to get everything right, just the big things… and that helps a lot.
I’ve done the waterfall model and seen six month or year long projects go off the rails. There are fewer checkpoints if you wait nine months for the first production build. And if someone in the food chain is not being honest about where the development effort is at, you don’t find out anywhere near soon enough. Agile forces a certain integrity on behalf of developers and middle management, a not inconsiderable management advantage.