As we struggle through some of the challenges of scaling this method (and they're real; read Gary Gruver's book, A Practical Approach to Large-Scale Agile Development, to learn how he and his team overcame them), we should take a step back and consider what drove adoption of Agile methodology to begin with: the fundamental inadequacy of waterfall development. Here's one man's opinion on the shortcomings of waterfall for those of us working through the following challenges:
First, it takes too long to get anything of real value into the hands of users in a waterfall model — in fact, it can take six, 12, or even 18 months to start user acceptance testing. There are several reasons for this, including reliance on detailed, but predictably imperfect, product specifications before writing a line of code.
Second is the model's basis on the notion that planning — i.e., measuring twice and cutting once — in software development results in more accurate delivery schedules and happier customers. It doesn't. More planning results in schedules that are precisely inaccurate. Getting into the code and making software is the best way to determine how long it will take and what the obstacles will be. Holding mind-numbing planning sessions doesn't improve schedule accuracy.
A Lack of Room for Iterative Quality
Lastly, the idea that testing quality in at the back end of a well-specified, precisely inaccurate development schedule will result in quality code and productive developers is worse than wrong. It's a joke. Quality becomes an inspected-in process at the tail end of an already blown schedule. Developers end up working on fixes for code they haven't seen in months (talk about unproductive context switching) and QA ends up with enormous and unfair pressure to ship low-quality software. It's impractical to hope for a perfect product without room for trial, error, and iteration.
So now I've gotten that off my chest — and dope-slapped myself and others about why waterfall is "one of those other forms that have been tried from time to time" — let's celebrate the admittedly-flawed-but-highly-functional Agile Democracy by reveling in planning poker, compressed cycle times, testing early and often, productive and empowered developers, customer feedback on working code, and, last but not least, business value that's released on a time scale of relevance.
Learn how to integrate security into Agile, download the whitepaper: Secure Agile Development
More Posts From the Veracode Engineering Team
3 Reasons You Must Code Securely - by Maria Loughlin, VP of Engineering
Think Like a Developer - by Pete Chestna, Director of Engineering
Get More Out of Your Agile SDLC - by Scott Gray, Principal Software Engineer