I have been working in companies the last 5 years where we have followed the agile methodology in product development. Shorter sprints, faster releases as opposed to month long development cycles that were common in waterfall.
Here is a guest blog post written by Mike Cudemo of Sparta Systems that explains the differences between Agile and Waterfall product development methodologies in a very simple way. He also explains the benefits of doing agile as a way of increasing the success rate of IT projects.
Seeing is believing. Agile methodologies are not perfect, but they are three times more successful than traditional waterfall methodologies (source: Standish Group). Agile methodologies allow end users and stakeholders to visualize their requirements faster and catch errors earlier in the development process.
A waterfall process can be likened to building a house. An architect translates your requirements into blueprints which only an architect can visualize. Your first glimpse into reality occurs after the foundation is poured and the walls are erected. While things can be changed, it is more expensive to change. Most people struggle to catch problems until the drywall is up and the ductwork and plumbing are in place. Again, you can make changes if there are issues, however, now it is even more expensive to address. The waterfall process attempts to “freeze the requirements” after the blueprints are designed. As you can imagine, this is not reality. The later you catch a requirements problem (e.g. I want a larger master bedroom closet), the more expensive it is to fix. In some cases, it is impossible to fix. You can have the closet, but little Timmy needs to sleep on the roof!
The Agile Method does not attempt to “nail and freeze the requirements” all up front at one time. It assumes that the requirements will evolve and change as the customer begins to visualize their own requirements. The Agile Method attempts to build the house by first creating a visual 3D representation of the outside of the house. This is how it is going to look when you come home from a long day at work. After the outside look and feel is developed, you attempt to construct the house one to two rooms at a time. The Agile Method attempts to focus the requirements, design, code and test into iterative smaller development phases. Essentially, the Agile Method is a series of smaller contained waterfalls. End users and business stakeholders get to see and experience the system as it unfolds. Course corrections become more apparent and easier to navigate.
Waterfall processes attempt to minimize and control change. Agile processes accept the inevitable need to accommodate learning about the real requirements. End users think in broad strokes; however, we all know the devil truly lies in the details. Skilled Agile development teams have a clear methodology to guide the process most effectively. They will select the plot and then develop the look and feel of the outside of the house. Next, they will focus on the 1st floor, and then move to the second floor. The finished basement will be last, because as we all know, we’ve run out of money by that time.
We find ourselves in the worst economy since the Great Depression. Many CFOs find themselves in a complex juggling act of cutting operational costs and making technology investments. CFOs are forcing their CIOs to come up with plans to leverage existing investments, yet develop the capabilities to rapidly respond to both economic growth and competitive changes. Project failure is really not an option, yet according to the statistics, waterfall approaches waste 60% of a company’s IT project budget.
Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time. It is better, but far from perfect. It is clear, that Agile methodologies are at least 3x more likely to succeed.
Agile methodologies are iterative. Understanding is paramount to containing change. Systems unfold one functional area and set of screens at a time. An Agile Methodology will not fix a bad project vision, an impossible task, or a lack of skilled personnel. Properly applied, an Agile approach will catch the poor vision, unattainable goals, or lack of resources early. IT and application departments must learn that cancelling a project early is actually a win. Broken processes should be fixed first before they become institutionalized with software or a system.
Companies that employ Agile methodologies and cancel unattainable projects early will thrive. Their IT success rates will exceed 85%. Most importantly, they will have more working capital to drive growth, innovate, and increase productivity.
About Mike Cudemo
Mike Cudemo runs the Customer Success Program at Sparta Systems. The program accelerates knowledge transfer of best practices to our customers to enhance overall business performance. Mike spent over 12 years integrating manufacturing operations with ERP and value chain systems at Fortune 100 clients, utilizing his expertise in value chain, quality, manufacturing execution and process automation systems. Trained as a systems engineer to analyze and simplify computer systems, Mike has spent a career helping clients understand their core business drivers, simplify the underlying processes, and automate the repetitive, non-value-added tasks which introduce defects and waste.
Software Product Manager by Gopal Shenoy 
“Over 20 years ago, 90% of IT projects failed or under-delivered on functionality. Today, depending on your source for statistics, IT projects fail or under-deliver between 30-70% of the time. It is better, but far from perfect. It is clear, that Agile methodologies are at least 3x more likely to succeed.”
…
90% of first-graders will fail to spell “catastrophic” correctly — while 30-70% will succeed in spelling “cat” correctly. It is better, but far from perfect. It is clear that lowering the bar statistically enables 3x as many first-graders to be successful — is there some reason this should be considered impressive?
Very apt opinion. I second your thoughts Mike
… pps — the plus side of agile is that if you don’t know what you’re doing, you will find out before funding an entire lenghty project and finding out at the end — and may even learn something along the way and fix it as you go — i guess that has its place — especially if you have to work with people who are learning as they go — and nowadays that may well be most of them — it’s just not the level of professional rigor we’re used to …
… ps — apparently, for many — a little bit here, a little bit there — is “good enough”, so I guess not everything needs to be world-class — since very few can afford it
— Alan Hines — I agree — but with a different slant. I, too, come from an evironment where fully-qualified professionals from the Business and Technical ends of the spectrum plan, design, and change design as needed to deliver completely-realized, long-range view, planned-for-change-and-growth, professional solutions — often in incremental deliveries — but without all the lingo-jingo overhead. Actually — truth be told — agile is simply a 2-week waterfall. I’m aware that poorly-managed “waterfall” projects (and all projects used to be “waterfall”) leave much to be desired and are the source of the huge pendulum swing to the other extreme (“let’s just get one line of code in”).
However, you must realise that few companies even know how to hire this kind of professional (even if they could afford them) — much less successfully manage them (better yet — stay out of the way …). So agile is the new “emperor’s clothes” — the blind leading the blind — agile is the mutual agreement between management and their employees that no one has a clue as to what is actually needed because they can’t / didn’t hire the best people, and therefore “we’re all going to stumble our way thru piece-by-piece to whatever miniscule bits and pieces of a solution we can, and pat ourselves on the backs and say. ‘great job’ — another 2 weeks of successful muddling to a tritely-defined solution — now let’s see if we can figure out what to do next to make it … better” … well — i guess that is agile — sort of like being quick on your feet to tell the next lie — n’est-ce pas?
Agile is a profiteering snake-oil / rainmaker scam that has devastated the ranks and value propositions of more once-were thriving enterprises than I’d be able to count; to the point where most if not all of the substantive software engineers whom I would even deign to talk to have resolved to leave the industry before ever becoming quagmired in that hellish nightmare context ever again.
The whole notion that “waterfall” (which has today become a blanket slur for everything that isn’t “agile”) is recalcitrant towards change is utterly preposterous, and a Lie; I myself have served on several projects where the entire conception was changed multiple times, and yet invariably delivered on-time and to (ultimate) spec, and to the profit on the order of literal millions to my company – because the ultimate result was NOT a munged-together miasma of release-driven “features,” it was a complete and fully realized and unified coherent Whole, designed and built by capable professionals who planned their work and worked their plan (and O, how the Agilistas absolutely LOATHE that very concept; see it as a threat to be rooted out and purged from any context they infest – to their own ultimate Ruin, I assure you, and quite probably our industry’s as well).
Cannot agree more. I have been doing water fall model with my product teams for quite some time, and agile is best thing that I have learned over last few years. Beware, it is lot of hard work for the team compared to waterfall, where team stretch only at the end of the release, here you are on your feets everyday !!!
Great post! It’s interesting to see success percentages linked with Agile. It is important as a requirements analyst or product manager to be familiar with both methodologies. A colleauge of mine at Seilevel wrote a comparative article on Agile and Waterfall as well, http://requirements.seilevel.com/blog/2012/07/software-requirements-agile-vs-waterfall.html