Agile Development Approach or Waterfall – which software development approach is better for my project?

Time and again, there are clients who are confused (while outsourcing their software development project to us) about whether we, at ISHIR, follow the agile software development approach or waterfall for most of our application and software development projects. We have clients who are also concerned about whether agile will work better for their project or waterfall. At times, we spend hours discussing the best development methodology for our clients’ software development requirements.

Since the response is not so simple, I decided to address it through this blog.

There is a trend you’re likely to find when dealing with outsourcing software development vendors. Large and predictable organizations are usually comfortable with the waterfall approach as it provides a standardized and centralized to development across the organization. But things are changing rapidly. Businesses are rapidly depending on digital business and services, wherein the primary need is to speed up their time to market. This is where agile development methodology can help.

If I get to the rudimentary level, waterfall is known as the traditional approach while agile is the new approach and is implemented with the help of Scrum.

Image Source: https://image.freepik.com/free-vector/father-and-son_23-2147515791.jpg

Waterfall isn’t that bad

Waterfall follows a linear software development approach (and predictable too). So you typically start with:

1. Gathering requirements
2. Design
3. Code
4. Unit testing
5. System testing
6. User acceptance testing
7. Bug fixing
8. Deployment

If waterfall is truly followed, each of the stages mentioned above is a distinct software development phase. One stage only begins once the one prior to it is over. For example, you can’t start designing before the client has approved and signed off the requirements.

So, you see, the waterfall approach isn’t all that bad. There obviously are some benefits, for example, developers and clients are more on the same page (in fact earlier on in the project).  Planning and designing is pretty much standard and predictable. Even the project progress can be measured easily. One of the biggest advantage is that the documentation is so thorough so one team can prepare the ground work (for example, testers can prepare the test cases taking a cue from the requirements document.

Clients needn’t be present always (other than the requirements phase). It’s the best suited approach wherein multiple software components are required (as design can be completed early in the cycle).

In the end, you have a software that is developed completely and more meticulously. It is based on a full understanding of the client requirements and a thorough understanding of deliverables.

There are many problems with the approach too. The requirements gathering phase itself can get intimidating for clients as it seems never ending. Specially clients who are not clear with the requirements and are not able to visualize what they want. In such cases, clients can benefit from looking at wireframes and mockups. Clients have no visibility to what will be delivered to them in the end, so you never know if they will be totally flabbergasted to see the final deliverable.

Then came Agile

Agile can help to drive business agility or evolve faster. It can enable an organization to become more resilient and open to change. You can say that it’s a modern way of working. As per a survey of senior executives from across the world, 92% believe that business agility is essential for the success of any business. It is critical for any business to respond to market changes and external factors quickly and efficiently. For organizations working towards a digital transformation, organizational agility is a given.

Agile is an iterative and team-based approach to development. It enables rapid delivery of application with all functional components. The schedules are time-boxed into phases that are called sprints. Sprint has defined duration and has a list of deliverables that are prioritized as per the business value (and decided by the client). If the sprint doesn’t work, the work is prioritized again. There are project team members or clients to review the completed work (or they can view daily builds and end-of-sprint demos). Of course, agile requires a high involvement from the client.

There are clearly some evident benefits of agile wherein the client has a lot of visibility into what is happening. It has been experienced that clients have a higher ownership in projects that follow the agile development methodology. If time to market is critical, agile can help with a basic version of a working software that can be developed after many iterations. Since there is a higher involvement of clients, the deliverables are more user-focused.

Of course, not all is well with agile. It requires the client to be involved all the time, which may not be possible for some clients. Agile development approach works best for projects that can have dedicated team resources. Often, it is experienced that since the client involvement is so high that features keep getting added and modified throughout the project. This may lead to a higher implementation time and cost. There is also some risk involved in agile methodology as all requirements might not be factored in the initial architecture and design, and hence have an impact on the overall quality of the deliverables. Large-scale implementations have several issues with integration when they follow the agile methodology.

Mobility and e-commerce projects or the ones that require regulatory changes are best managed with agile.

How do we choose?

We choose either agile or waterfall based on several factors like client availability, scope of the project, features to be developed, type of team required (dedicated or part-time) and pricing model required.

There are many organizations which may combine the best of most models, and follow the Hybrid development model, especially for large software implementations as these require more visibility, governance and predictability.

If you wish to discuss what’s best suited to your project requirements, you can connect with us.