Is frequency of release the only real difference between Agile and Waterfall? [closed]

Question

Obviously the differences in the impact to teams, customers, ROI, etc. of applying the two approaches is huge and is the subject of many books and endless discussions and conferences.

But as I think more about it, I am having a hard time finding any difference between the two that doesn't ultimately map to a single root difference which is the frequency of release.

Waterfall spends time on a design, then writing the code, then testing and finally releasing. But Agile does exactly the same set of steps - its just that each one is smaller.

A key piece of the Agile approach is about learning from each release and using that to let the larger design emerge instead of trying to predict it at the beginning.

But Waterfall does this too. Its just that instead of learning every 3 or 4 weeks, the Waterfall team only learns every 6 or 9 months. But the Waterfall design still emerges. That is, waterfall release 2 will reflect what was learned in release 1. So the process is not different, its just that it executes at a different speed.

Agile focuses on close customer collaboration. But Waterfall does this too. Its just that since waterfall has a longer iteration time, an enumerated list of requirements in the form of a contract is more needed to keep everyone on the same page over the long period of time. But again, this is just an artifact of frequency. The higher the frequency of delivery, the lower the need for a contract.

Are there any other primitive differences that I am missing - or is it really just frequency?

Stark

Discussion threads like this ought to be wikis. – Cockle

Talking about differences from the waterfall model is silly -- since day one it's been a straw man for people to contrast with whatever they advocate. I believe the first ever description of the waterfall model was in: cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf, which describes it only as a contrast with the oh so inevitably superior method advocated by the author. – Goldia

No to repeat myself in an answer - you should distinguish between releases and being release-ready: andybrandt.net/637/to-release-or-not-to-release – Chatman

Agile is a series of short waterfalls each with a splashback. – Theophany

Answer 1

Waterfall:

• you design the product
• you build it
• you test it
• you document it
• you release it when you have developed all the requirements

Agile:

• you design the most valuable feature (or user story) first
• you test it (TDD ;))
• you built it
• you document it
• you repeat the process with the next most valuable feature
• you can potentially release it at any time

(after each feature you completed or after the time boxed period (usually called sprint or iteration))

The difference is pretty clear to me.

With Agile, you can adapt what to build by delivering small chunk of the software frequently. You can stop when you have enough.

Tuinenga

That's a good point -- with Agile, you start testing when the feature is done. With Waterfall, you start testing when the entire product is done, which makes for longer end-to-end cycles. – Sarcastic

If I were going to niggle I might want to swap the test/build around - being the TDD advocate that I am :-) I'd also only document if documentation was necessary. And I'd design as-I-went rather than all up front :-) – Asymmetry

+1 for "You can stop when you have enough". A point many people miss – Marcelo

@adrianh: If you're giving it to end users, you need to document things because they won't read the code, no matter how good it is. Maybe you document different things, but it's still documentation and it still must be written. – Outofdate

Adrian is not telling you the inverse – Tuinenga

@Donal Did I say no documentation? Nope - I said "document if documentation was necessary" :-) If end-user documentation is needed - write it. Even better - bring in your UX and technical authors and figure out how to reduce that documentation to the minimum necessary. Don't document just coz you hit the "document" phase in your process. Document when documentation is needed. – Asymmetry

@adrianh: OK, so we're in agreement at a practical level. :-) – Outofdate

Answer 2

Faster feedback - at all scales, not just releases, is certainly one common factor in many agile practices. But I don't really think it's the primary difference between agile & waterfall. For example:

• Waterfall teams tend to be built around group of narrow specialisations. The analysts/architects/designers/coders/testers tend to be separate groups of people working alone. Agile teams work together.

• Waterfall processes depend on lots of documentation and handovers. Agile teams are oriented around working code/products.

• I'd disagree that waterfall focusses on customer collaboration. There is a single point of contact, with a small group of the overall development team, often only at the start of the process. Agile is built around continual collaboration throughout the whole development process. Very different.

• Waterfall processes are built around the idea that you can fully define the product & architecture before development begins. Agile processes are built around the idea that you discover the product/architecture as you go.

Asymmetry

Answer 3

Waterfall spends time on a design, then writing the code, then testing and finally releasing. But Agile does exactly the same set of steps - its just that each one is smaller.

Agile is not a single entity, but an umbrella for many varying methodologies.

In at least some of them, as others have noted, these "phases" overlap much more and are in somewhat different normal order.

In fact, in XP, the order is more or less:

• test (TDD/test first)
• code
• design (refactoring)
• repeat and eventually release

which sort of inverts most of the sequence.

And the test, code and design is done at a finer grade than the release.

A key piece of the Agile approach is about learning from each release and using that to let the larger design emerge instead of trying to predict it at the beginning.

But Waterfall does this too. Its just that instead of learning every 3 or 4 weeks, the Waterfall team only learns every 6 or 9 months. But the Waterfall design still emerges. That is, waterfall release 2 will reflect what was learned in release 1. So the process is not different, its just that it executes at a different speed.

This depends heavily on practice. As described in DOD-STD-2167A, (Section 4.1.1) the waterfall model does indeed allow for the phases of the development process to overlap and iterate (in short, to be somewhat agile). But most actual practice missed that, and there was no learning until the end of the project.

Agile focuses on close customer collaboration. But Waterfall does this too. Its just that since waterfall has a longer iteration time, an enumerated list of requirements in the form of a contract is more needed to keep everyone on the same page over the long period of time. But again, this is just an artifact of frequency. The higher the frequency of delivery, the lower the need for a contract.

Again practice-dependent. I don't see in the spec referenced above much mention of the customer responsibilities at all, let alone continuously.

As Jerry Coffin noted in a comment, Waterfall is indeed a strawman used to argue in favor of Agile (as indeed I'm using it now...), but it's worth looking at this document and thinking about what it implies and how it's been applied.

What this spec does show is an intense focus on contracts, delivery and maintenance of plans and documents, and adhering to plan. And I believe that did carry over into practice.

The contrast with agile is not the timeboxing, but a change in values.

As The Agile Manifesto proclaims:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Curiously, this values statement says nothing about frequency of delivery (though the following "Principles" section does). It does however shift the value system away from plans, documents and contracts and back where it belongs, on actually delivering working software.

Frequent release is a mechanism for fulfilling these values.

If you worked in "mini-waterfalls" it would indeed be a bit more agile than the strawman BDUF waterfall. But frequency of delivery is certainly not the whole story.

Stalker

Answer 4

One difference is transparency: whether people outside the dev team, during the dev cycle, have any visibility into the process, the progress, the obstacles, and what the end result will look like.

Waterfall does not imply transparency. Often (though not necessarily) it's implemented as "programmers go into their cave and emerge n weeks/months later with a 'finished' product". The business experts write the specs up-front, and that may be the end of their involvement -- they might no longer be available when the programmers have questions during implementation. The programmers might not show any deliverables to anyone until the end of the cycle.

Agile requires transparency -- it's part of the basic fabric. People outside the team will (or at least can) see what the team is doing. (If not, the team is lying about being Agile.) This might be the daily stand-up meetings of Scrum, or the Big Visible Charts and information radiators, or the demo at the end of the iteration. It might be XP's requirement that the Customer make all the business decisions, instead of leaving the programmers to scratch their heads and blindly pick an option when the requirements aren't clear. It might be the fact that the testers -- and the Customer -- are considered part of the team, not separate teams.

You certainly could run Waterfall with transparency, and in a well-run Waterfall shop, you probably would. But with Agile, it's a given.

Sarcastic

Answer 5

Mark,

As you pointed out, both approaches share "good things" that should be in every good project. For instance take these two: early feedback and transparency. While it is true that Agile has an structure that encourages this, these two "good things" can (and should) be in any waterfall project, too.

However, I tend to (respectfully!) disagree with the idea that release frequency is the only difference. One substantial difference is the following:

Waterfall spends time on a design, then writing the code, then testing and finally releasing. But Agile does exactly the same set of steps - its just that each one is smaller.

I don't think so. In Agile, you attempt to do all these things concurrently, with a multidisciplinary team. I say "attempt" because is not something that can be easily done... but at least trying helps.

On the traditional waterfall, on the contrary, you expect to have separate teams (research/analysis, QA, design, marketing, etc.) and hand offs between them. You mix disciplines and form a special team only in exceptional cases, or when you need to do exploratory research or risk analysis in a complex project.

Just my two cents...

Capsular

Answer 6

I really like this question.

I have worked maintenance with bad examples of massive waterfall projects. The deliverables for the initial developers were several sets of documents, and one codebase. Once the high-level design document was completed, it was delivered, and never again updated. Ditto SRS, Detail design etc. There is documentation, all of which is unreliable and suspect.

With Agile, there is code. The long-since-gone developers thought it was self-documenting, because they were current with the project when it was written. (Have you ever proofread your own memos? They always make sense to the author.) I will try to discern the architecture from looking at 1500-2000 modules. Likewise trying to figure out the high-level design. I will take copious notes. Maybe even binders full. Looking at the "self-documenting" code will tell me what is being done (in that module), but not why. Oh yeah, the staff who collaborated with the developers got promoted (or scared) and are no longer available.

Bad agile is not better than bad waterfall. In fact, bad agile may be worse than bad waterfall. Is good agile better than good waterfall?

The manifesto says nothing about documentation. The real danger here is that "agile" means to many developers and clients a justification of a quick cheap heroic model. Do you think the customer enjoyed reading the three thick three-ring-binders of high-level design? We all heard in Computer Science 100 that the majority of the cost of software is maintenance, not development. Am I incorrect in thinking that the maintenance aspect is totally ignored in this discussion?

The difference may be that modern clients cannot afford to not specify "agile" because they fear being thought backward.

Interleave