Waterfall vs Agile

“Which development methodology should we use?”. This question is very common during the early state of the most new projects. And also it is a topic that gets a lot of discussion.

Development methodology is not about a style of project management or a specific technical approach, it’s about a general way of organizing the work of software development.

Agile and Waterfall are two distinct methods of software development. Waterfall can be described as a linear model of software design. Both of these are usable and mature methodologies. And below are my thoughts on the strengths and weaknesses of each.

Waterfall (“Traditional”)

Waterfall employs a sequential (or linear) design process. People sometimes call waterfall cookbook approach. This means that as each of the eight stages (project preparation, analysis, planning, design, construction, testing, implementation, and maintenance) are completed, the team moves on to the next step. As this process is sequential, once a step has been completed, team can’t go back to a previous step — not without scratching the whole project and starting from the beginning. There’s simply no room for change or error, so a project outcome and an extensive plan must be set in the beginning and then followed very carefully.

Waterfall flow

Waterfall has following pros:

  1. Client clearly knows what to expect. Developers and customers agree on what will be delivered early in the development life cycle and the project team has clear plan of actions (progress is more easily measured, as the full scope of the work is known in advance). Together this creates a clear vision.
  2. Waterfall development processes tend to be more secure because they are so plan oriented. Waterfall require solid documentation and extensive planning.This would help in the case of employee turnover in case of project impact.

Well, strict waterfall process also has two major problems — it is incredibly rigid and inflexible. Most common cases are:

  1. Altering the project design at any stage in the project can be a total nightmare. Once a step has been completed, team can’t go back to a previous stage and make changes. This increase the possibility that the customer will be dissatisfied with their delivered software product. As all deliverables are based upon documented requirements, the customer may not see what will be delivered until it’s almost finished. By that time, changes can be difficult (and costly) to implement.
  2. Waterfall methodology relies heavily on initial requirements. However, if these requirements are faulty in any manner, the project is doomed. Also gathering and documenting requirements in a way that is meaningful to a customer is often the most difficult part of software development
  3. The whole product is only tested at the end. If bugs appeared early, but discovered late, the cost of the fix could be pretty high.

Agile (Rapid Application Development)

In contrast, the Agile method proposes an incremental and iterative approach to software design. It was essentially developed in response to the limitations of Waterfall, as a way to give designers and developers more freedom and make their work more customer-related. Instead of a sequential design process, the Agile methodology follows an incremental approach. Usually people call Agile as innovative approach.

Agile flow

Agile has following pros:

  1. Altering the project design could be simple. Software developers work on small modules at a time. Customer feedback occurs simultaneously with development, as does software testing. This has a number of advantages, especially in project environments where development needs to be able to respond to changes in requirements rapidly and effectively.
  2. Agile can be especially preferable for the situations where the end-goals of projects are not clearly defined. For example, if you are working with a client whose needs and goals are a bit hazy and require a time to evolve. Usually it creates a possibility for continuous improvement (i.e. lessons are learnt from and ultimately used to better the next iterations).
  3. Last but not least, Agile always require interaction and communication (both Team interaction and interaction with stakeholders). In case of Agile collaboration is more important than initial design. To be clear, interaction among developers and stakeholders is key to create a cohesive piece of software at the end of the project.

But more freedom sometimes creates a more chaos:

  1. Agile projects tend to be hard to predict, from timelines to budgets. Without a concrete plan, everything remains a bit vague and nebulous.
  2. Development is much more person based. Having a person drop out of the project could prove catastrophic. Lack of documentation (usually Agile project does’t have documentation requirements) could increase a level of damage.
  3. Agile always requires self-organizing team. This also means that if team do not wish to do something (both in design/development or interaction)— Agile won’t work for this team.

So, What’s Better?

Well, neither the Agile method nor the Waterfall method is inherently better than the other. It depends on the type of the project in first case. In general, waterfall tends to be good for static projects, where it’s not likely that many changes will be made throughout the development process. In contrast, Agile tends to be a better option for projects where changes are likely to appear during the project design.

A few thoughts about project criteria. There are eight points which should be kept in mind when you choose Agile or Waterfall approach:

  1. Requirement definitions (If your project requirements are constantly changing probably your project is more Agile-like for this point).
  2. Change (If your scope is always changing, do your stakeholders always have a scope of changes which they would like to see in product. If there is always a fluctuation of changes you maybe close to Agile side).
  3. Experience (If this a new technology for your team. If it’s not a new technology or brand new established team — you probably more Waterfall-like).
  4. Resources / Dedication (Do we have people dedicated to this project or we have part-time or not fully dedicated to the project engineers. If we have people dedicated to the project — we probably more Agile-like).
  5. Resources / Physical location (Distributed or located in one place, do we have an offshore resources. If we do have distributed resources we probably should stand on waterfall-like approach).
  6. Customer involvement (Critical for Agile-like project due to the continuous feedback from customer to be able to deliver project in short time. If we unable to get this feedback in continuous way — we more like waterfall approach).
  7. Timeline (If we have fixed due-dates, financial requirements or any other calendar restrictions we should stand on waterfall-like approach).
  8. Documentation (Do we have the flexibility to require a bit less documentation. If we do — we could stand in Agile for this poitns).

In summary we should look on this eight points and decide what type of methodology should we use for our project.