A lot of people throw around the terms agile, waterfall, and maybe spiral very often when they talk about the software development methodology they use within their teams. What do I say? Rest in peace waterfall. Take care spiral. Be gone with you both because, dude, you've got to be more agile! But what really is the difference between agile and waterfall? The end result is the same, right? Well, that's not really true.  Waterfall is a much older model. Although it may sometimes hit the mark, I would argue that agile gets better, quicker, and cheaper results. 

Waterfall

The sequential nature of the waterfall model is meant to ensure that progress cascades down through the phases of a product/software lifecycle. This covers all aspects from conception through implementation and maintenance.

• Business requirements do not evolve/change with time and during development.
• There should be no budget constraints or overruns.
• A consultant clearly understands the requirements.
• The same requirements have been communicated to technical architects, project managers, developers and the testing team.
• The documentation is thoroughly read, understood, and visualized by everyone involved exactly as business needs it.
• A step is not started until the previous step is fully completed.

Sounds great, right? Well a waterfall project can be quite expensive before you see any results or functionality. Additionally, over time requirements change, scope can change, and desired results can change. Strict adherence to the waterfall model does not allow for these changes to be implemented. What you see in the beginning is what you get in the end with waterfall.

Agile

In contrast, agile software development allows solutions to evolve through self-organizing teams. Rapid development, organic development and continuous improvement are all hallmarks of agile software development, resulting in a rapid, flexible development model.

• The implementation can be broken down into sprints. Each sprint delivers a value and solves a small portion of the larger problem statement.
• The client is a part of the implementation team and is involved during the sprint. They are also part of testing each sprint before the next starts.
• The learning from each sprint is carried forward to another sprint for better execution.
• Ideally there is no project manager. A sprint leader, or Scrum Master, ensures tasks are broken down and picked up by developers voluntarily.
• Each developer is solely responsible for successful completion of the task.
• The sprint leader puts back together all tasks once completed, ensuring a value-adding, meaningful sprint is delivered on time.

Can you see the difference? Not only do you get functionality faster, but with agile you can adapt to change. This results in the customer getting exactly what they want at the time of delivery.

In Conclusion

You may be "old school-ish" and still plan (and maybe even operate) using the waterfall methodology.  Ask yourself these questions: (1) Am I really saving money? (2) Am I really producing the end results my clients expect to see? (3) Would a more iterative approach that is flexible to change and has constant validation be more valuable to what we as a team are looking for?  Imagine if an organization did everything more agile. Stop planning with the end-goal in mind. Instead plan out a couple of weeks at a time... then reassess the situation. I guarantee you that the end-result will be better for what you want now, saving you money and stress. So seriously dude, you've got to be more agile!

This article is a guest post to Zephyr from Evan Golden, Senior Atlassian Consultant, Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.