Is performing a Waterfall every 2 weeks considered agile development?

Question

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.

Answer 1

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:

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:

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.