When Does Agile Make Sense?

I’m a fairly vocal proponent of Agile development methods, but there’s something I think is very important for people to understand: Agile is not appropriate for every kind of project.

That may sound like blasphemy to the hardcore Agile evangelists (they seem to be everywhere these days!), but the reality is that just like a traditional Waterfall approach, Agile has its disadvantages. Agile skeptics will use this fact to point out how Agile fails as a methodology, as though using the wrong tool for the job is an indication of the quality of the tool. Neither methodology is “better” objectively - but one approach may be better suited to your particular project. So how do you know which to choose?

This article assumes you have a general understanding of Waterfall and Agile. If you need more information on what these terms mean, click through to these quick tutorials: Waterfall Model | Agile Model

First, I think it helps to understand some of the primary differences between Waterfall and Agile. And keep in mind, these are not your only two options* (they just happen to be the two most popular and most distinctly different)! Each approach has its advantages and disadvantages, and there are reasons in favor of selecting one approach over another.

*Check here for more information about different software development methodologies.

Waterfall is:
  • Plan-driven: work is organized and executed according to a project plan created before the project is executed
  • Linear and highly structured
  • Comprised of a series of distinct phases
  • Big Up-Front Design: All requirements are gathered and documented before any development begins.
  • Focused on timely completion of project milestones and deliverables as a primary measure of success
Agile is:
  • Backlog/feature-driven: work is organized and executed according to a product backlog that is continually updated and re-prioritized throughout the project
  • Cyclical and highly adaptive
  • Comprised of a series of iterations
  • Just-In-Time Analysis: Requirements are gathered right before development is to begin on a given feature.
  • Focused on working software as a primary measure of success
Advantages of Waterfall:
  • Predictable: planning is more straightforward
  • Milestones can be identified far in advance
  • Project budget can be identified up front to a reasonable level of certainty
  • Documentation is generally more thorough
  • Progress can be measured fairly easily along a linear path
  • Clients are not required to commit a great deal of time to the project on an ongoing basis
  • The overall system design can be informed by a holistic view, with all major dependencies identified up front.
Advantages of Agile:
  • Flexible: the project team can easily adapt their planned work based on new information or requirements
  • Changes are equally inexpensive to make at any point during the project
  • Promotes stronger team collaboration and communication
  • Client feedback is solicited on completed product increments on a regular basis, leading to higher quality development and greater client satisfaction
  • Complete, working software can be delivered much more quickly
Disadvantages of Waterfall:
  • Does not allow team to react quickly to change
  • Relies heavily on the accuracy and quality of requirements gathered early in the project, when the project is least understood.
  • Documentation can be overwhelming and complex
  • Changes become increasingly expensive as the project goes on
  • Testing is typically delayed until development is complete, when changes are most expensive to make
  • Client feedback may not be gathered until after each phase, meaning a greater portion of the work may need to be re-done if a client requests changes, which may impact overall client satisfaction
Disadvantages of Agile:
  • Requires high level of discipline from all team members
  • Requires a high level of commitment and participation from the client/product owner
  • Can be difficult to execute under a fixed budget contract
  • Not as suitable for highly complex dependencies
  • Documentation may not be as thorough, and may not provide a quick and easy understanding of the system as a whole (documentation tends to be focused on individual feature sets).
  • A focus on speedy delivery can have an impact on overall system quality
When to use Waterfall:
  • If the system does not contain a great deal of novelty (i.e., something similar has been done before, or a prototype exists) If a similar project has been completed before, up-front estimates for the project plan can be based on these similar efforts and are much more likely to be accurate and realistic.
  • If the requirements are known in advance and not subject to a great deal of change over the course of development
  • If the client has a very thorough and clear understanding of their needs
  • If your client has limited or restricted availability to commit to the project, or you must be able to clearly identify and anticipate the required client resource needs up front.
  • If the project is fixed budget
  • If the system has a great deal of integrations or a high number of dependencies
When to use Agile:
  • If the system contains a great deal of novelty (i.e., something similar has not, or has rarely been done before) If a similar project has not been done, or has been rarely done, estimates cannot be based off of previous experience, which would make estimating all efforts for the project up-front very difficult. An Agile approach allows the team to estimate tasks only when enough information is known about the work to accurately determine the required effort.
  • If the system contains a great deal of complexity. Highly complex systems may be difficult (or impossible!) to model in their entirety prior to beginning development. Progressive elaboration of a system over a number of iterations can help the team build a highly complex process over time.
  • If the client does not have a clear understanding of the needs of the system, or the client’s needs are likely to change quickly over time
  • Your client can commit a great deal of time to working with the project team and the project team can ideally work co-located on the client site.
  • The client needs to have a system in production fairly quickly, and may be comfortable with limiting features to accommodate speed