Comparing Agile and Waterfall

Ah, the ever so fun debate between agile methodologies and waterfall for IT development. Take a deep breath. Not only is this a big debate, but it’s often very heated.

Gantt ChartsWaterfall was the way to go for many, many years. Recently, though, the agile methodologies have been providing more of a sustainable path for companies because of the flexibility and success. Because I actually leverage both, I thought I’d share some insights into both methodologies.


This is the typical IT project methodology. It is a linear, sequential approach to software design. Each phase is a silo, from which you don’t move on until it’s completed. Waterfall is very schedule- and milestone-oriented, which results to detailed requirements and understanding of the final product before teams get to start building. A change control process is put in place to ensure the right things are documented and nothing is missing. By nature, Waterfall is process-driven and heavy with documentation and prescribed deliverables.

Phases of a typical waterfall project usually follow a predefined route.

  • Project Initiation: The initiation phase is leveraged to create the Business Case, charter or vision statement, budget, and some planning documents.
  • Define: This phase allows project teams to describe the project’s requirements and understand the needs for process and the application’s functionality. The typical deliverables are the Project Requirements document and Business requirements.
  • Design: This is the time for product functionality and technical design. It’s when wireframes and prototypes are created to ensure the final product will meet the customer needs. The deliverables are dependent on the environment and interpretation needed for the teams to become aligned.
  • Develop: This is encompasses final technical design and development. It is more of the “behind-the-scenes” effort for the technical team. The business partners typically do not have heavy involvement during the phase.
  • Test/Deploy: Like it says, test and deployment.
  • Warranty: Usually a 30-day cycle to allow the project team to manage any open or new defects before handing the product over to the support team.

A few additional things to note are the defect management and change control processes.  These ensure that the team has a level of flexibility while moving through a project. It also ensures the proper level of documentation for education of, and validation by, other members of the project team.


Agile methodologies are very different. They’re a group of software development methods based on iterative and incremental development. Requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. They leverage adaptive planning, iterative development and delivery, a fixed iterative approach, and encourage rapid and flexible response to change.

The driver behind these methodologies is the Agile Manifesto, which was created in 2001. The methodology typically focuses on individuals and interactions over processes and tools,working software over comprehensive documentation,; customer collaboration over contract negotiation, and responding to change over following a plan.

It’s easy to understand why Agile requires a different mindset. Individuals and teams have to be adaptive and react in a positive way to change. It also requires a willingness and commitment for teams to move forward and constantly adapt and change.

Some popular Agile methods are:

  •     Agile Unified Process (AUP)
  •     Extreme Programming (XP)
  •     Open Unified Process (OpenUP)
  •     Scrum
  •     Lean Software Development

Comparing the Two

Waterfall is like a traditional waterfall, literally. It starts at the top and drops in a linear fashion until it is “done.” Agile is not as predictive and allows for iterative change and process.

Waterfall is better for projects that are predefined and understood. Agile is better in situations where there is still a bit of uncertainty regarding the end solution. Waterfall does not allow for interactive development. Agile enables the team to close the feedback loop more quickly and enables communication to start early in the process.

11 Responses to “Comparing Agile and Waterfall”

  1. I worked 5+ years for a software company that used the Agile method. They would release code, lots of bugs would be discovered, the code would be ‘rolled-back’ to an earlier version, code was fixed and re-released (many, many times). It was a real mess. When a developer left the company, it was very difficult for the next employee to pick up his/her work since there was little or no documentation. Sometimes the new developer would spend weeks trying to tease apart the software just to figure out what was happening. Agile is expensive long-term – wasted resource hours due to no documented process; negative shadow cast on the company’s reputation (who wants buggy software?). Agile sounds good, in theory, but I have not seen it successfully implemented.

    • I would actually agree – Agile used incorrectly will product a poor quality project and many frustrated resources. One of the reasons Agile fails is lack of true adoption of the method. It is a change of mindset and process for an entire organization.

      In order to adopt Agile, everyone has to participate, resources need to be committed and companies have to be willing to work through the first few iterations to “get into a groove”. Each team works differently. One suggestion I have for teams wanting to change and move to an agile method is to bring someone in to help train and facilitate to ensure success. This person could be tasked with setting teams up and organizations up with standards/thoughts on how to work within the organization.

      It also depends on which method is leveraged. I am trained in Scrum and have participated in several agile projects. Yes, the emphasis is on resource interaction and communication not documentation, but that does not mean zero documentation. At my last company, we leveraged a Scrum coach. The person stayed with us for the first four months which helped drive consistency, visiblity and success.

      I have participated with more successful agile teams than waterfall. So I do hope at some point in your future, you get an opportunity to work on an agile team that is set up for success.

  2. Although Agile may have some good applications, my experience with it was a disaster.
    One project I was worked on attempted to use Agile to develop a data warehouse and reporting application in PARALLEL. Problem was the constant iterations of the data warehouse kept breaking the reporting application, which required constant rework on the reporting side wasting hundreds of hours. Would have been much easier and cheaper to wait until the data was in a mature state to begin reporting development. This approach was used to ‘Save Time’ and to meet an ‘aggressive deadline’, but all it did was waste time and consulting hours, and the project was delayed anyways.

    • That is unfortunately. I challenge organizations to build teams to encompass all resources needed to create the solution top to bottom. Why not merge the two project teams together to provide smaller pieces of success top to bottom instead of creating dependencies between teams like that.

      Agile helps maximize communication and shorten the feedback loop. If you have two projects teams running for the same project, it can prove to be interesting. I hope you find success in other agile projects.

  3. I believe for most projects you need a mix of the two. Not a rigid waterfall, but an iterative (or agile) version, with as much documentation as necessary – not more, not less. The problem is that people tend to either champion one or the other. I have worked with both… in waterfall, I convinced the management that half of our documentation work could be treated as “working documents”, i.e., once it was used, we didn’t have to update them any more. When I worked on my “Agile” project, I had to convince my boss that functional requirements, written down, are a good thing and shouldn’t be skipped. Mind you, you don’t need to have them in exact detail – but defining scope of work, and having an idea of what we are trying to accomplish, and having people agree on it, is very important.

    You need documentation… at the minimum, a project plan and a high-level functional requirements document. If the project gets large, you also need design documents, and especially, descriptions of the core frameworks, classes and how to use them. You can have the greatest data access and UI generation framework, but if other developers don’t know about them or don’t know how to use them, they will just write their own versions, creating duplication of effort and likely poorly written code (which you were trying to eliminate in the first place).

  4. Great comments here. About comments and documentation. I’ve worked for two companies that had almost no documentation and almost no comments in the code. Both used Agile. In the Agile and Scrum books I’ve read there is virtually no emphasis on documentation. Not all programmers are good and many hate to document. It is not hard to see how some would see Agile as giving permission not to do so.

    Not all managers are good either. Some see the Scrum stories as a commitment rather than an estimate. When a waterfall project falls behind the deadlines are pushed back. When a Scrum falls behind instead of dropping stories, frequently shortcuts are taken in the documentation or the testing leading to technical debt.

  5. I have used Agile for a few years and I have been fortunate enough to have worked with team that were properly mentored in the methodology. I agree with Cathlynn that when used appropriately it does work! The disasters experienced by some of the people in the comments above can be easily avoided;

    -Lack of code comments and knowledge disappearing when developer resigns —> Set up a culture of pair programming and pair swapping, there should never be a single point of failure
    -Documentation: at a minimun create user stories, set up a wall with lots of visible info, huddle at least once a day
    -Lots of bugs: involve a tester AS SOON AS you have testable piece and promote TDD!

    But as Cathlynn mentioned all this requires the commitment of the entire company not just the IT department. So if your CEO/CFO doesn’t see the benefit of pair programming (why pay 2 devs when 1 can do the job??) or willing to pay a consultant who will introduce the benefits of TDD then projects are doomed to fail.

  6. Urbie Watrous

    Everyone presents Waterfall as a straw man: totally inflexible, top-down, imposed by executive fiat, man-centuries of development time put in before any testing is done, additional man-centuries wasted by armies of drones writing documentation no one will ever use, and programmers living a life of drudgery (always contrasted with the workers’ paradise of Agile). But in 28 years (admittedly as a chicken, not a pig), I’ve never worked for an organization that did that. Everyone tests code, does a certain amount of iterative work, changes the product to fit the realities of the situation, etc. The Agile Manifesto reads like a hissy fit, not a model for making products — nonetheless, I’m all for collaboration, iteration, and flexibility. At the end of the day, though, the programmers don’t own the company.