Warerfall Vs Agile

Technologies are constantly changing and so do management methodologies. What worked yesterday might not work today, and vice versa. How can you then be confident that your project is managed correctly?

We are experiencing a real boost of project management approaches and methodologies. In the IT world, the most widespread and popular one is, of course, Agile. However, there is no “one size fits all” when it comes to software development, that’s why it is crucial to know your project scope first.

We recommend using Waterfall if: 

·           You don’t expect changes in scope and you’re working with fixed-price contracts

·           The project is very simple or you’ve done it many times before

·           Requirements are very well known and fixed

·           Customers know exactly what they want in advance

·           You’re working with orderly and predictable projects

And you should use Agile if:

·           The final product isn’t clearly defined

·           The clients/stakeholders need the ability to modify the scope

·           You anticipate any kind of changes during the project

·           Rapid deployment is the goal

When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or expect any changes throughout the project, go with Agile. If you know the project is fixed, unchanging, and predictable, Waterfall may be a better choice.

Drawback Waterfall

·       One area which almost always falls short is the effectiveness of requirements. Gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development, in my opinion. Customers are sometimes intimidated by details, and specific details, provided early in the project, are required with this approach. In addition, customers are not always able to visualize an application from a requirements document. Wireframes and mockups can help, but there’s no question that most end users have some difficulty putting these elements together with written requirements to arrive at a good picture of what they will be getting.

·       Another potential drawback of pure Waterfall development is the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, a customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.

Drawback - Agile

·       The very high degree of customer involvement, while great for the project, may present problems for some customers who simply may not have the time or interest for this type of participation.

·       Because Agile focuses on time-boxed delivery and frequent reprioritization, it’s possible that some items set for delivery will not be completed within the allotted timeframe. Additional sprints (beyond those initially planned) may be needed, adding to the project cost. In addition, customer involvement often leads to additional features requested throughout the project. Again, this can add to the overall time and cost of the implementation.

·       The close working relationships in an Agile project are easiest to manage when the team members are located in the same physical space, which is not always possible. However, there are a variety of ways to handle this issue, such as webcams, collaboration tools, etc.

·       The iterative nature of Agile development may lead to a frequent refactoring if the full scope of the system is not considered in the intial architecture and design. Without this refactoring, the system can suffer from a reduction in overall quality. This becomes more pronounced in larger-scale implementations, or with systems that include a high level of integration.