I've been wondering if one can still classify a Waterfall type development approach, where the length of the waterfall cycle is 1-2 weeks, as Agile.

  • 1
    What do you mean by "cycle"? Is that the length of the project, or are you repeating fortnight-long waterfall developments? Sep 7 '11 at 20:41
  • Repeating fortnight-long waterfall. So spending say 4 days in analysis, the rest in development/dev testing. Deliver the feature. Then repeat. Sep 7 '11 at 20:42

Traditional (and incorrect) waterfall is a single iteration through the phases of the lifecycle. First, you perform requirements engineering. Using those requirements, you architect and design the system and verify/validate those designs. Then, you implement the system. Once the system is implemented, you test it to ensure it works as intended. Finally, you ship it off to the customer for deployment and use. The project enters a maintenance cycle where you fix bugs and release updates, until the project is end-of-lifed. The process looks something like this:

Winston Royce's "Waterfall"

In reality, this is a bad model for developing software. The paper where a lot of people learned about waterfall actually proposed something very different. It involves a high level of customer involvement at each phase and transitioning back to previous phases to correct and revise artifacts. You can read more about it in Royce's paper, Managing the Development of Large Software Systems. It looks something more like:

Winston Royce's SDLC

Finally, we have the agile approaches, which are iterative and incremental development models. There are many variants on iterative and incremental models. The idea in all of them is that you perform all of the lifecycle phases - requirements, architecture, design, implementation, testing, release - many times in the life of the product, until customer wants to end the product. There's no real detailed diagram of what iterative and incremental development looks like, as there are many variations, but the result is typically a feedback loop.

  • And this just scratches the surface. I didn't even talk about iterative models such as Boehm's spiral model nor the specific implementations of iterative and incremental models such as RUP, XP, and so on. But I hope it illustrates the difference between sequential and iterative/incremental.
    – Thomas Owens
    Sep 7 '11 at 21:11
  • I'm doing a software rewrite that had been developed over 11 years. The requirements are "just as the old worked, with tweaks." I'm in huge unknowns, but keeping cycles of Analysis/Development/Feature Release in a 2 week window to keep up with an accurate'ish estimation. I'm trying to understand what kind of methodology this is. Sep 7 '11 at 21:17
  • 2
    There are lots of methodologies. It's not Waterfall, since you have multiple releases at the end of a cycle. And your methodology might not have a name, either - processes are typically models that are tailored and tweaked to the project and the team. Giving the models names makes it easier to talk about them in an academic sense. When it comes to application, very rarely should anyone be implementing a model at face value.
    – Thomas Owens
    Sep 7 '11 at 21:22
  • 1
    @Martin, It sounds like your methodology is AgileFall... agile-fall.blogspot.com/2010/03/what-is-agilefall.html
    – maple_shaft
    Sep 7 '11 at 21:36

Agile development allows you to:

  1. Deliver working functionality rapidly
  2. Respond to changing requirements

One of the points is to avoid the whole Big Design Up Front problem that traditional Waterfall developments which lasted for years before anything was delivered led to.

So if you are delivering something every two weeks then you are effectively doing agile (notice the lower case "a"), but not Agile (with the upper case "A"). You should be able to respond to changes as long as you are only doing the design for the current iteration and don't have some "Big Design" you're not deviating from.

  • What's the difference between Agile and agile? Sep 8 '11 at 7:18
  • 1
    @Martin - I was trying (and obviously failing) to make the distinction between actually being agile/responsive etc. and following a recognised Agile pattern.
    – ChrisF
    Sep 8 '11 at 7:38

Short answer is, no. Agile implies iterative, adaptive development where as Waterfall implies design upfront. So, either you're not doing agile or you're not doing waterfall, or (most likely) you're not doing either.

  • 1
    Your last sentence is kind of confusing with the "not" in there - is this intentional? Also, "incremental" is often used to describe Agile with "iterative" - I've never heard of "adaptive development" before.
    – Thomas Owens
    Sep 7 '11 at 20:49

tough call.

In case like you describe I'd probably use cost of design errors as determining factor.

  • Say, if it takes a month or two to recover from design error discovered at testing stage and if that happens frequently enough to cause pain then that certainly smells like a typical Waterfall issue to me. Otherwise, it seems to be just good enough to stop worrying about terminology.

If you are shipping a version every 2 weeks, then you must have something a bit unusual.

Either your business is constantly changing, the size of implementation you are undertaking in each cycle is so small, or your user is not providing the full picture of requirements.

All of the above is very risky and can be fixed by proper up-front analysis and design.

If you release your software every 2 weeks, you will possibly need to spend considerable time in regression testing, documentation, production support education, user training, etc. Also, the water fall style is not based on iterative cycles and has no accommodation for regression testing.

I am also concerned about the end-user feel for a change in the software every 2 weeks. Personally, I don't want to see a new menu item on the application every so often that does something new...

If I were you, I would study the true value of having a 2-week cycle.

  • 1
    It's entirely possible to ship software every two weeks, or at least have potentially shippable software every two weeks, even if you decide to not ship.
    – Thomas Owens
    Sep 7 '11 at 22:03
  • If that is possible, then you really have a good team. In my experience this time frame is too short.
    – NoChance
    Sep 7 '11 at 22:17
  • It is definitely possible to ship more frequently even than this, though you have to have lots of things in place to make it work well. Also, it is a lot easier to do in some situations than others. May 30 '12 at 5:28
  • 2
    There are teams achieving this even within the banking sector - see qconlondon.com/london-2012/presentation/…
    – DNA
    Jul 29 '12 at 22:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.