software development through collaboration of waterfall and agile methods

Question

How can waterfall method and agile method be used in a single project?

Answer 1

It's impossible.

All agile methodologies should be iterative. Otherwise, they will not correspond to the first and third principles of the manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

...

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Waterfall is non-iterative approach by it definition:

The waterfall model is a linear sequential (non-iterative) design approach for software development, in which progress flows in one direction downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, deployment and maintenance.

So, you can't use iterative and non-iterative approaches at the same time.

---

Update: There are several methodologies that are neither a classical waterfall nor agile (RUP or Spiral model, for example). They can take something from both approaches, but they are neither the one nor the other.

Answer 2

There is a term for such a thing, Wagile:

Wagile software development is a group of software development methodologies that result from slipping from agile back into waterfall, doing a lot of short waterfalls and thinking it is agile, Waterfall model masquerading as Agile software development, etc.

And it is as bad as it sounds...

Found a nice article for this kind of process...

Answer 3

Sergey Kudryavtsev is correct, it's not possible.

The fundamental principal behind waterfall is that the Product Management work is done upfront: the marketplace is researched, the concept is generated, the customers are interviewed, the entire product is designed and then a comprehensive and exhaustive PRD is passed to Engineering which then develops the product, tests it and then deploys it. All of the progress flows in a single direction and the PRD represents a directive from Product to Engineering.

With agile, Product will still research the marketplace, generate a concept and interview customers, but the entire product will not be specced before development begins. A PRD, or multiple PRDs, will be shared with Engineering, but these will be smaller, living documents. Engineering will respond with their feedback and concerns, and the PRD will be updated accordingly. The same occurs when feedback and concerns are received from customers. The process is iterative and these documents represent an understanding of the customer that is shared between Product and Engineering.

Looked at another way, the agile anti-patterns are almost the definition of waterfall requirements:

Anti-patterns to watch for

• The entire project is already spec'd out in great detail before any engineering work begins
• Thorough review and iron-clad sign-off from all teams are required before work even starts
• Designers and developers don't know when requirements have been updated
• Requirements are never updated in the first place (because everyone signed off on them, remember?)
• The product owner writes requirements without the participation of the team

The problem will be felt particularly acutely when one part of the organization is implementing agile while the other waterfall. If Product is using agile and Engineering waterfall, then Product will be wondering why things are taking so long and Engineering will complain about the PRDs being "half baked." If it's the other way around, Engineering will be wondering what they're supposed to work on and Product will be complaining that Engineering needs to wait. Hurt feeling will ensue.

Update: Steve Blank just published some thoughts on the topic in AgileFall – When Waterfall Sneaks Back Into Agile:

AgileFall is an ironic term for program management where you try to be agile and lean, but you keep using waterfall development techniques. It often produces a result that’s like combining a floor wax and dessert topping.

He goes on to describe how the process can be tweaked to get back on track

Answer 4

Waterfall is based on the premise that catching errors early - before much is invested - is cheaper than catching errors late. Thus you plan more upfront to avoid surprises later.

Agile is based on the premise that the above is a good step to preventing errors but will not protect you from changes and complications. So operating iteratively and on a smaller scope accomplishes the same as waterfall and more on top of it.

You could try and argue something like "Scrum really just is iterative, overlapping waterfall" or "Agile simply advocates doing much shorter waterfall subprojects, one after another" and depending on who asks and what they want you might be successful.

You can incorporate several agile principles like close collaboration, prioritisation, customer involvement, continuous testing, values like openness, courage and respect into waterfall project and consider this mission accomplished.

The problem is that both waterfall and agile tend to come with certain expectations. It's generally more the expectation that clash with each other than the practices advocated by the "models". And it's generally the expectations that tend to go with waterfall that make waterfall problematic. Like the expectation that the waterfall gantt chart has prophetic qualities. Or the expectation that because you've added some buffer time at the end you can easily squeeze in a few more features or "clarifications" of features. Where as agile rigorously opposes these...

You can do successful projects with waterfall just as with agile. Trying to shove both into the same project is generally a sign that not everyone in your group understands the point of agile. And you're trying to solve disfunctionalities that people aren't willing to let go of yet.