LambdaTest Community

Find answers, support, and inspiration from other users

LambdaTest Community

What is the difference between the waterfall and agile development models?

Can anyone please explain me what is the difference between the waterfall and agile development models.

Up Vote Down Vote 0 Votes
Posted 2 months ago


Waterfall Model :This was the current Waterfall workflow in one of my company.

  1. The Business Analyst retrieves the requirements from the user.

  2. Team Leader estimates the project's cost with a high-level analysis (tending to overestimate).

  3. The user signs the contract for the whole project. The project might be subdivided into smaller phases, although they usually last for months.

4.The DevOps Analyst creates a Technical Design document which will be approved by the Business Analyst.

  1. At the end of each phase, the user receives the testing result and gives us the OK.

  2. Team give support to the production team so they understand the new functionality.

  3. When the project is deployed, it's monitored during the first executions by the DevOps Analyst.

Well, the thing is that this Waterfall approach usually leads to missed or hidden requirements, misunderstandings, rework, discrepancies between the high and low level analysis, etc.

However, at first glance, these were the problem we faced:

The deployment protocol was quite expensive as we need to create tons of documentation. It was only worth it if we were working in very large phases. That's why the users tend to merge all the phases in a single one when possible. In most of the cases, the value of the iterations depends on the final one. Thus one cannot deploy each one individually. Agile Model: smart iterations and close communication with the customer is the essence of agile. Getting the feedback loop between making a mistake and realizing it as short as practical. Everything else is a bonus.

· Create meaningful iterations that add value. Something you can show your customer and say: "Now it can crawl/walk/talk!"

· Hit the uncertainties and essentials early. If your customer wants an electric plane you don't build a fully kitted out plane and then at the end put the electric engine in only to see that you've got an operating range of 30 minutes. Instead you want to be able to tell the customer after the first iteration. "Look, an electric supersonic transatlantic luxury plane is not feasible. You've got to make some cuts. We can probably make it electric and transatlantic but it's going to be slow and relatively bare bones. Or we can do electric and domestic with reasonable comfort."

· Get the customer to inspect every iteration and talk about what they like and dislike. You sometimes will need to press them on it. If they don't you're back to doing waterfail - just with additional steps. At my previous employer we ran into this problem. Dev team was regularly giving the (internal) customer a snapshot of the current progress. Customer ignored it, reported back "that's ok" and at the end ripped everything to pieces over things that would have been trivial to correct in the moment but had snowballed into a ton of work. In the end the whole project was trashed because the customer never bothered to do it's part.

· Ensure quality through every iteration. At my last employer we had this problem. The external devs were not diligent enough on the tests. So when we got to testing the nitty gritty details internally all sort of faults popped up.

Up Vote Down Vote 0 Votes
Posted 2 months ago