Agile Software Development

4 Ways to Make Agile and Waterfall Work Together

Some businesses just are not comfortable making a hard leap into agile. They might allow some experimentation, but they would like to see some standard waterfall kept in the mix. In an article for, David Taber considers four “coping tactics” to blend agile and waterfall in a way that does not ruin both methodologies:

  1. Vigorous account management
  2. Plentiful change orders
  3. Explicit closure of discovery
  4. Stipulating a not-to-exceed for each major functional area


In cases where the waterfall specifications or scope are ill-defined, you can use this wishy-washiness to your advantage in sprints. However, it will require you to constantly be managing expectations at the beginning and end of every sprint, especially having regular discussions to reprioritize deliverables as needed. Exploit the power of change orders too, formally revising the statements of work and getting a customer signature with it whenever you need to conduct course correction. Specifically, every time an item goes from vague to clear, it is time to make a change with that information in mind.

About the third tactic, Taber has this to share:

In typical software projects, an initial fixed-cost phase… is devoted to the requirements discovery process. The output of that process is the statement of project functional requirements. Even though it is common to discover many details after that first phase, these new items are not the project implementer’s problem: they are the consuming or client organization’s problem. They should not be accepted as binding requirements without a change order. Unfortunately, I’ve seen projects that were still in discovery after deployment.

Regarding the final tactic, Taber recommends inserting a block of text (which is written explicitly in his article) into the statement of work under each major deliverable that defines how much total time may be spent on that deliverable. It is essentially a way to timebox work, and also to build in formal task reviews for work in progress.

You can view the original article, with some additional closing insights, here:

Show More