Brad Egleland has a post titled Agile Software Development Project vs. Standard Software Development Project where he conjectures there is less cost, lower rework, and the final product is closer to the customers needs. Which may or may not be true. It'd hard to tell without parallel projects. But that's not the point.
He describes the traditional project activities as:
- Requirements definition
- Development
- Unit/system testing
- User acceptance testing
- Deployment
- Post-deployment support (break/fix & tech support)
Nothing wrong, that's pretty much what happens ON EVERY SOFTWARE DEVELOPMENT PROJECT independent of the development method. Yes I'm shouting.
It's the granularity of how long each of these is performed. Nothing in the "agile," approach be any different in the end. It's simply not possible. Agile MUST:
- Capture the requirements in some way - use cases, story cards, hand waving at the white board
- You gotta right the code
- You gotta unit test and system test
- The user needs to confirm no matter what
- The system needs to be placed into service
- And of course updates and the like have to take place
So why is type of comparison still occurring? I don't know.
I had an long ago picture from Kent Beck that showed the evolution of XP. Starting with the traditional Design > Code > Test > Fix sequence. All linear. Then evolving into multiple shorter cycles of DCTF. Then a two week cycle of DCTF.
My friend who is the CTO at BoldTech here in Denver has a DAILY DCTF, and on some projects a twice a day DCTF.
No matter the method the steps Brad shows in the traditional approach MUST be done, in SOME order.
It's the order, the granularity, and the response at the end of the cycle that seperated agile from traditional. It's NOT agile versus traditional is GOOD project management Versus BAD project management. Everything else is a matter of granularity.
So to take up Brad Challenge - Show Agile is Better
In the agile world you find problems faster. By agile I mean finer granined cycles. Finding problems faster lets you fix them faster. That's obvious. If you have a stable baseline for the next iteration, you can improve the quality as the process proceeds. That's likley meausreably better. Agile is simply good rick retirement planning. The same risk retirement planning we employee on multi-billion manned spaceflight programs. Like build a full scale mock up of the same weight and shape to see if the crew can fit inside. Like taking a short flight in the desert - the Flight Test Article
Agile is a sweet spot software development process. But remember it's just that a software development process, not a complete end-to-end project management method.
