News Stay informed about the latest enterprise technology news and product updates.

Methodology wars: Agile or waterfall?

Lately, I’ve been talking with software testers and developers about software methodologies, and I’ve noticed the Agile vs. waterfall camps are very divided.

Miss Manners will tell you to stay away from controversial topics, such as politics or religion, when you’re meeting a new acquaintance. Some people have such strong opinions that they have a hard time discussing them without getting into a heated debate. I’m sure you could add many things to that list. I’ve known sports fans — or are they fanatics? — who have had such heated arguments that nacho wars are a real danger at Super Bowl parties.

And geeks? What do we get all hot and bothered about? All kinds of things. Techies argue about operating systems, tools, databases — just about everything — each certain that their way is the right way. I’m amazed at how personally people can feel about these things!

Yes, the Agile-versus-waterfall debate can be added to the list of controversial things that geeks have strong opinions about.

Many groups are convinced that Agile is the best methodology for any type of development effort. Others feel it works well for small projects, but not for large enterprise development projects. There are even some that speak out against Agile. Software pro, blogger and self-proclaimed software entomologist Dave Whalen makes no secret of his feeling that the Agile movement can be like a cult. On his blog, Whalan complained:

“Like most cults, if anyone dares to have a different opinion or refuses to drink the Agile Kool-Aid, the true-believers will rally their masses and crucify you…Don’t get me wrong –I like Agile. It’s a great process. It works well in SOME, very narrowly defined, situations. NOT every situation!”

I found this “Agile Made Simple” video on YouTube by Rodrigo Coutinho that I think does a great job of explaining the difference between the two models.

As I responded to Dave in his post about cults, my opinion is that not any one methodology is the right answer to every software development project. Some of the considerations I think are important:

  • Size of the project: I would think smaller projects cater more to agile, because the smaller the team, the easier to collaborate.
  • Compliance/regulations: Some government projects may require documentation and processes that are not always present with Agile.
  • Risk of project: High risk, life-and-death type projects require more rigor and discipline than low risk.
  • Existing processes, tools, methodologies, team expertise: There’s always a learning curve and pain involved in changing the way things have been done. Change is good, but might want to take baby steps, depending on the criticality of the project.
  • Team mindsets: Is the team excited about trying agile? It seems it would be a lot more effective if there was buy-in rather than mandate.

I asked an agile expert whether there were certain types of projects, such as the ones I mentioned above, that might be better being done using a waterfall approach. Her opinion was that all projects would benefit from using an agile methodology. She felt smaller, iterative releases would always be an advantage.

SearchSoftwareQuality’s contributors have been participating in the debate, as well as offering useful information about Agile and waterfall. They’ve covered such topics as waterfall versus iterative development misconceptions and if Agile and traditional project management can co-exist. Also, in two articles, software testers Matt Heusser and Lanette Creamer debated the differences between test automation and test-driven development.

When deciding on a methodology, there are a lot of things to consider, a major being choosing Agile, waterfall, or something in between.  Which is right for you and why? And no virtual nacho-throwing for those who disagree!

Join the conversation


Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Agile can be used with projects of all sizes. It just forces us to break up huge time consuming tasks into smaller and more manageble tasks. I also do not agree that it does not allow for documentation. It says document as much as you need, so in short if you need is extensive, go for it. I am one who has been involved deeply in executing large projects, some with industry leading companies in their sector, using the Agile methodology and I have not seen a single reason so far as to why it should not be used.
Hi Vishy, Thanks for your comment. I agree that the Agile methodologies do allow for documentation. Here is an audiocast that was done not too long ago that addresses that very subject amongst others: [A href=",295582,sid92_gci1361290,00.html"]Succeeding with software requirements in Agile projects[/A].
I agree with the "cult" comment. There seems to be travelling bands of Agile evangelists who are happy to tell you Agile is the answer to everything - it may even cure cancer and solve the problems of the middle east. The reason why Agile is so wholeheartedly embraced and promoted by some developers is that is a developer's nirvana. Each day you get a bite-size piece of work to focus on. You are forbidden from considering the big picture. You are not responsible for the big picture - just getting the basic function of the day to work. Documentation is an afterthought and given scant regard. It's a lazy developer's dream - and they will push that dream no matter what the cost. From a company/project/delivery perspective, the picture isn't anywhere near as rosy. The 2 things the methodology supposedly guarantees is the delivery date and the budget, and yet from the Agile projects I've seen both of these KPIs have blown out. I'd be happy to try Agile on small projects only, where there is a small team of developers and testers involved. Beyond that, it is a high risk approach that has a poor track record of delivery. - cyba
Why either or? Why not both and? Each methodology has its strengths and weaknesses. I’ve had a lot of success picking and choosing from multiple methodologies to put together processes for teams to follow and then modify as needed. Some people think that Agile equals no plan, no documentation and no accountability. A good Agile implementation has a roadmap with clear visibility into what needs to be delivered. The deliverables are broken into short iterations and the working code output of the iteration is demonstrated to the customer. To me this is one of the most important aspects of iterative development, the check in with the customer to validate that what the team is doing is exactly what the customer expects. Documentation delivered with the project is up to what the customer wants, it’s simply another work product in the backlog, if the customer wants it, the customer gets it. Burndown charts provide reporting against agreed productivity goals clearly indicate to management how the team is performing. There are no surprises.
As if there isn't any middleground ? I'm familiar with UP in large and small projects and the range of UP is form "high formalism - low agility" to "low formalism - high agility". The first rule of UP is 'adapt the process' which says it all in my opinion. Look what requirements you have (in the sense of formalism) and adapt the process to it. What I find a plus is the fact that his way 1 methodology is used for all types of project - cutting down on formation, avoiding misunderstanding through the use of 1 terminology - no internal methodo wars etc.... just 2cts
Doing formal static analysis of code, or any of the the other things needed to produce safety critical code does not make a project "waterfall". The differences between agile and waterfall go much deeper even that the notion of iterations. A waterfall project is really categorized by certain underlying assumptions that substantially conflict with agile principals, such as assuming that a design can be completed with no validation of that design by actually coding any part of it. Since I don't believe that assumption (amongst others) holds true under any circumstances I can conceive of, I therefore don't believe that a pure waterfall approach is EVER best for anything.
Great discussion! I love to see the varied points of view and healthy debate. DenDanny, I hadn't heard about UP. I'll check into that. It sounds like an interesting concept. I ran into Lisa Crispin, author of Agile Testing, at the Agile Denver user group on Monday and asked her opinion. Stay tuned for a future blog post.
Agile is a very disciplined process that relies on commitment and buy in from the whole team. The projects I've worked on definately have seen the benefits of Agile and I have seen it work on large and small projects (I must say the larger projects may have slightly more complexity but it still can work). One of the benefits seen is the customer has been able to have input all the way through and refine their requirements along the way as opposed to receiving the end product and realising it's no longer what they wanted. Another one of the benefits is the immense focus on testing. As testing is done all along the way time is saved by identifying, fixing and prioritising defects straight away. The developers I work with may focus on their cards but they always have the big picture in sight. They know they are a part of a team to deliver an end result so part of their focus is on that. I don't think they always think it is nirvana as they have estimated the cards they are delivering and they are commited to delivering their agreed points within the iteration. There is more visibility on their delivery......imagine how the developers and project team feels at an iteration close when their burndown chart is displayed and they didn't meet their velocity. The visibility is high and delivery is constant so everyone is accountable for reaching the goal.
@pncampbell99 : indeed 'true waterfall' has some principles antipodal to agile. @Rmaslen 'Agile is a very disciplined process' - I love to hear you say it. I come across a lot of developers 'wanting to do agile' because they think the opposite. @Yvettefrancino - if you check out UP - keep in mind that it is a vast methodogy (well, RUP is anyway) which can provoke a knee-jerk reaction as to declaring it 'huge, formal .....not agile...., which is not necessarily the case ! There are separate initiatives found on the web : agileUP, EnterpriseUP, OpenUP, ......which attempt to 'adapt the process' for you. I haven't encountered any agile principle or practice that UP precludes.
I'm still very anti A! (I refuse to use the "A" word) It is my New Year's resolution to do everything in my power to kill it. See my feature article in the December 2009 T.E.S.T (The European Software Tester) Magazine -
Most of the Agile principles can be incorporated into waterfall model also like short cycles, important work first, talk to customer etc etc. Real difference in Agile and Waterfall from project management side is that in Waterfall model Resource and Scope are fixed dimensions while time is variable and time is plan (contract) driven variable. While in Agile Resource and Time remain fixed and Scope is variable. Scope keep getting realigned to business priorities. In a long project if visibility is important and contract driven, I prefer plan driven approach while products having long roadmap and features being priortized by end users, I use Agile in this case. Most customers using Agile do not have very precise visibility of cause and effect on certain iterations while it can be provided with plan driven approaches.