Agile vs. Waterfall Development: How About Both?

Ann All

When I scheduled an interview with Steve Hardin, IT Business Edge's VP of software development, to talk about our company's use of agile development, I'd been hearing and reading a lot about agile, interviewed a few other folks about it and hoped Steve could further enlighten me. About midway through our discussion, I discovered ITBE actually uses a hybrid approach that combines elements of agile and more traditional waterfall development.


Steve's explanation: "No one approach is always going to be the best." Mike Beltzner, Mozilla's director of Firefox, made similar comments in an article published earlier this year that detailed Mozilla's use of a hybrid development model for the most recent iterations of the Firefox browser. I especially liked his final quote:


Really, we're not tied to any specific development model. We're tied to what is effective.


Forrester Research analyst David West, speaking during an HP-sponsored Webcast, said many developers view agile as "the ability to respond to change in the most effective way, considering the restraints of the environment in which you're working in." Though agile's popularity is growing, West said he expected more developers would incorporate agile concepts into their current development processes rather than using agile exclusively.


Thirty-five percent of developers surveyed by Forrester in late 2009 said they were using agile development. A surprising 31 percent said they don't follow a software methodology at all, which West interpreted as meaning they may use concepts taken from multiple development methods rather than following any single method.


A story conveys the experiences of two companies, sharing the pros and cons of using a blended waterfall/agile approach.


The pros:

  • Incremental delivery of features helps developers identify and build on early success.
  • Solving problems as they occur rather than testing and performing fixes at the end of a development cycle reduces the likelihood of fatal system flaws.
  • Iterative releases make it easier to accurately forecast delivery times and final budget.


The cons:

  • Agile requires developers to be able to work together as a team. Developers who don't do so may neglect integration issues and interdependencies.
  • Team leaders who don't establish and enforce scope and design requirements upfront risk losing control of the project. Though this is also a risk with waterfall projects, it's an even bigger one for agile due to its emphasis on frequent iterations and making changes as you go.

Add Comment      Leave a comment on this blog post
Jul 2, 2010 3:50 AM Keith Sterling Keith Sterling  says:

So one of the cons is that is forces developers to work as a team..... really this is a negative, the fact that it creates an environment that encourages people to communicate and solve problems and does away with the concept of hero hackers who want to spent their whole life in isolation.

As for team leaders who don't enforce control, I'm sorry, but thats the role of the team lead, to define the scope of the team and lead by example, therefore by definition enforce a level of control

Its clear that the author of this post does not understand the concepts and therefore unfortunately should not be trying to write about it

Jul 2, 2010 9:24 AM Ann All Ann All  says: in response to Keith Sterling

Thanks for your comments, Keith. Perhaps I should have said 'caveats' instead of 'cons.' If you read the earlier post I link to, in which I interview ITBE's VP of software development, he stresses the importance of teamwork and communication. I am not a software developer, nor do I even play one on TV.

Jul 5, 2010 11:19 AM Raj Menon Raj Menon  says: in response to Ann All

Keith/Ann - in a way, i think both of you are correct in your claims. While Keith, I am guessing an Agile/Scrum practitioner like me, is correct in saying that working together as a team, collaborating, is very important for Agile to work and it is one of the strengths the model offers, unlike waterfall. So he is absolutely right that it is not a con in any way. However, I read Ann's statement as a con to the blended model and I agree. A blended agile/wf model will not allow for a team to work together especially if each person has his/her own set task to work on for the release and works mostly on their own. It defeats what Agile is trying to change in s/w development environments. So it is definitely a reason (a con) for why we should not favor for a blended model.

My take (probably obvious): Choose one model. Dont blend it coz id you will lose the benefits of each and doesnt help with nothing but meeting your deadline, which i believe you will do so one way or the other... those who call it "blended" are being nothing short of ad-hoc in their development methodologies. While shorter TATs and enhanced visibility is just one of the benefits of agile, the most important is collaboration, cross trainin thru which you'll increase your teams velocity, and gradually remove micro-mgmt and bring on accountability. That is the true power and need for agile today.

Jul 6, 2010 1:39 AM Al Gibson Al Gibson  says:

There's nothing new about incremental development of features.  It's certainly not exclusive to Agile vs Waterfall.  I've worked on many Waterfall projects over the years with iterative development and a rolled out schedule of planned features in the code base.

Why do the Agilistas believe they've re-invented the wheel when they haven't?

Don't forget that the Agile Manifesto was written by a bunch of people who completely screwed up a project at Chrysler (Kent Beck and Ron Jeffries) along with others who attempted to breathe life into their religions (Extreme Programming, ASD, FDD, SCRUM, etc) by adopting a unifying umbrella to it all.

Jul 6, 2010 3:00 AM Ann All Ann All  says: in response to Raj Menon

Thanks, Raj. Interesting thoughts on the limitations of a blended approach. John Storts, moderator of our Knowledge Network, wrote a great note about his experience w/ agile development at his previous employer, spotlighting the importance of making sure all members of a development team are on board w/ the agile approach. I think it builds on your point. (I managed to miss it as it was published while I was on vacation. Had I seen it, I would have linked to it in my post.)

Jul 12, 2010 6:20 AM Raj Menon Raj Menon  says: in response to Ann All

Thanks Ann. Appreciate you sharing the link.

I have writting an article (and many more to come soon) that I consider the 1st lesson of Agile teams: Humanizing your team. If you care to read and comment, here is the link:

Jul 15, 2010 3:48 AM XebiaLabs XebiaLabs  says:

Hi Ann-nice article. I agree that agile's frequent iterations could pose difficulties for IT teams. This is why it is so important for IT teams using agile methods to implement deployment automation in order to keep up with the faster and more frequent deliverables-do you agree? I also like your remark about how developers need to be able to work as a team in an agile environment. In fact, one could say that the word team' could also be regarded in a broader sense, to include the operations staff as well. In fact, there is a risk that in agile, the deployments will become the (next) bottleneck in the overall software production process. Deployment automation helps developers and operations both to become the true enablers of change.

Aug 21, 2010 11:52 AM Sanjib Maji Sanjib Maji  says: in response to XebiaLabs

Can you please describe with example between two Methology?


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.