I traveled through the Expo portion of the SQE Better Software Development Conference & Expo today. The slant was definitely toward Agile Software Development. I had the pleasure of speaking with representatives from QSM, Rally Software, VersionOne, innerworkings, NetObjectives, Software Quality Engineering, and VMC among others.
I have not personally fully managed a project that utilized Agile or Iterative development processes. I was leading a project utilizing an iterative development process on an enterprise-wide software re-write, but unfortunately the project never finished as the company I was working for at the time closed down suddenly, thus sending the remainder of the project to a competitor.
The Standard Process
I’d like to analyze the difference between an Agile Software Development Project and what I’ll call a Standard Software Development Project. To me, the standard software project follows the process that we all grew up with…
- Requirements definition
- Development
- Unit/system testing
- User acceptance testing
- Deployment
- Post-deployment support (break/fix & tech support)
The Agile Process
Agile is much different, often utilizing 2-4 week ‘sprints’ ending in a usable (though not market-ready) product. As an experienced software developer, software manager, and project manager I can certainly embrace the concept that an iterative process that involves short bursts to turn out a usable product that the customer can interact with greatly reduces the chances of being way off the mark in terms of requirements vs. the end product. I can logically assume that the end result is lower costs, less re-work, and a final product that is often much closer to what the customer wanted than what is turned out by a decent percentage of ‘standard’ development projects.
My ‘What If’ Scenario
With what I call the ‘standard’ process there is always a strong likelihood that the end product will not be what the end user actually needs. The risk is great that either the requirements weren’t detailed enough, or development slowly strayed from requirements enough along the way to provide a basically unusable solution after a development cycle that could be a year in length. The possibility for wasted time and huge re-work is much greater. With the Agile process, you can never really be farther than 2-4 weeks off the mark.
The Big Question
So, I can understand the fact that over an entire project portfolio, the likelihood of realizing a significant cost savings could be very high…likely IS very high. Here’s my question:
If we were to take a large software project and run it both ways – standard and Agile – and then let’s assume that both work perfectly…no re-work, no missed requirements, etc. At the end of each version of the project, what shape would the budget be in?
My assumption is, that if everything else is equal…meaning it all goes smoothly with either process…then I would tend to believe that the ‘standard’ process would result in less expense and less effort. Prove me wrong…I want to hear from the readers – especially Agile promoters. Over the long haul – the entire project portfolio – I can see it being the better way to go in terms of cost due to less re-work. But in a perfect world – which is a fairy tale, I know – wouldn’t the cost be less with the standard process of running a software project? I’m not anti-Agile at all, so please don’t read it that way. I’m just trying to provoke some thought and discussion here. Now…respond!