Waterfall or Agile - which is right for you?

I have been asked this question a lot: What is the difference between the Waterfall Methodology of development and the Agile Methodology of development?  Both have the advantages as well as disadvantages, so it is important to understand (basically) how each works and at the end of the day, the best method really is based on the needs of the business.

So first, let’s discuss just what is the Waterfall Methodology of Development?

The Waterfall Methodology is a sequential design process, think in terms of automobile manufacturing.  The building of an auto happens in a very precise and set sequence, you cannot install the exterior doors without the interior completed.  The Waterfall Methodology has eight stages:

  1. Conception
  2. Initiation
  3. Analysis
  4. Design
  5. Construction/Development
  6. Testing
  7. Implementation
  8. Maintenance

As this method is sequential the developers can’t go move on until the step is completed, subsequently, they cannot go back to a previous step – not without dumping the entire project and starting from the beginning. With the Waterfall Method, there is no room for error or change, so every step must be thought out completely and then every step must be meticulously performed.

What are the advantages of the Waterfall Methodology?

  • The Waterfall Methodology stresses documentation, detailed documentation on each and everything done. Detailed documentation allows for future development as well as a clear upgrade path. It also helps with the technical documentation as the development team evolves.
  • With the Waterfall Methodology, the business process owners, the clients, the end users know what to expect. The size, cost, timeline and expectations have been set in great detail. Before the project even begins they understand and know what the program will do.

What are the disadvantages of the Waterfall Methodology?

  • Once a step has been completed, developers can’t go back to a previous stage and make changes. They have to move forward. This means if the business process owners/users decide to change what is required, they either have to start over or live with what was scoped.
  • The Waterfall Methodology is dependent on the initial requirements. If the requirements change, or worse still, if they were not captured correctly, the project will fail.
  • With the Waterfall Methodology the developed application is not tested until the end, so if the earliest written code has bugs, it may impact code that was written later, potentially creating a technical slew of fixes later.
  • The Waterfall Method does NOT take into account the evolution of a business, the business model as well as the business process. A business process owner will ALWAYS realize they need something more or different, this will ultimately impact the cost, schedule and finish time of a project.

When should you use Waterfall Methodology?

  • Only when there is a clear, set in stone picture of what the final solution should be.
  • Only when the business process owners are required to NOT change the requirements once they have been scoped out.
  • Only when the defined project is more important than the speed to get it done. Definition/Scope is everything

So, now what is the Agile Methodology?

The Agile Methodology was developed as an answer to the disadvantages of the Waterfall Methodology. Rather than following a strict sequential process, the Agile Methodology follows an incremental approach to development, developing in ‘Sprints’.

The Business Process Owners AND the Developers start off with a very simple project design, and while it may be simple, the entire team knows what the ultimate end goal it.  The Developers begin to work on small modules within the project; the work on these modules is done in weekly or monthly ‘Sprints’ and at the end of each ‘Sprint’, the project is evaluated with the Business Process Owners as well as tested.  This allows for the evolution of the business process, changes in the business process as well as capturing any ‘Ah-Ha’ moments generated by experiencing the development. Since development is done in ‘Sprints’, changes and bug fixes are relatively painless in the sense impact is minimal.

With the Agile Methodology the temptation can be to ignore the initial design. I want to stress here that while it is not sequential in nature, having an initial design will help the process along.  The biggest benefit is the collaborative nature of the Agile Method, the Business Process Owners are committed as well as involved, and they have a stake in the game.

What are the advantages of the Agile Methodology?

  • The Agile Methodology is flexible and allows for changes to be made after the initial planning. Changes to the business process, the evolution of the business and those pesky ‘Ah-Ha’ moments are expected.
  • Changes are expected, so it is easier to add or modify features or processes. Additionally, the Agile Methodology will help you keep up with changes within the particular industry you are working.
  • Since you are working as a team with the Business Process Owners, you are getting feedback at the end of each ‘Sprint’ and the Business Process Owners will ultimately get the product they envision/want. Additionally, testing at the end of each ‘Sprint’ (UAT and otherwise), bugs are caught and fixed immediately rather than later.

Yeah – yeah, so what are the disadvantages of the Agile Methodology?

  • With a weak Project Manager, the ‘Sprints’ can become a series of changes and business process modifications. This will lead to cost overruns as well as the project coming in seriously late.
  • If you don’t take the time to define the initial plan, the final product may be vastly different than what was imagined.

When should you use the Agile Methodology?

  • When speed is more important than definition and when the Business Process is influx or evolving.
  • When the Business Process Owner is simply unsure of what the final outcome should be or if they are hoping to clean up their business process with an application thus assuming many changes.
  • When you have a strong Project Manager who can push back to the Business Process Owners and strong developers who have a keen business sense and can make assumptions during the development process.

Both methods have the strengths and weaknesses. What it really comes down to is the needs of the Business over the needs of technology. Remember, the needs of the business must always drive technology and not the other way around. If you are working in a business that has had the same business process for years and is not apt to change, the Waterfall Methodology would probably work well.  If you are in a business that is screaming for change or is evolving, the Agile Methodology is probably going to work well. At the end of the day, the business will drive it.