The Agile software development philosophy has become quite popular among programmers, for good reason. As you consider your next (or first) software development effort, you may be thinking it would be worth your while to understand the pros and cons of Agile development, especially compared to the traditional development method known as Waterfall. Which one should you use for your application, and why? Good question.
Waterfall vs. Agile
Basically, Waterfall takes a linear approach to development. The metaphor is simple, and obvious: water falls down in one direction, and getting it back up to start over is difficult, and costly.
You start by working with your stakeholders to figure out and describe exactly what you need to build (the “requirements”), design a solution that meets those goals, write the code and perform tests, check for user acceptance of the software, take their feedback, and integrate that into the final product. If at any point in the journey you determine that something needs to change, then you have to climb back up to the top of the waterfall and do it over again.
With the Agile methodology, the emphasis is on rapid development and constant change. The Agile method breaks the entire application into smaller bits that can be built, tested, reviewed and refined. This (hopefully) prevents the “Oops, we just realized we forgot to add X, now we have to rewrite the entire application” syndrome.
The key to making the right choice is to understand the fundamental nature of your project and the people working on your project, and how those relate to the methodology you choose to follow. As we’ll see, certain types of projects and people fit with the rigor of a Waterfall approach, while others are best considered from an Agile perspective. The fundamental consideration is how well your project can be defined up front, and how amenable it is to change along the way.
A software project that is an integral part of a physical system, or that relies heavily on complex external interfaces, does not lend itself to incremental development with many changes. If you’re launching a rocket to Mars, you need to follow a rigorous process. If, however, your project is loosely defined and reliant on the reaction of its users to what it does and how it does it, then don’t bother trying to define it up front. Your detailed requirements will fall by the wayside as soon as your app meets its users.
How people fit in
It’s a bit of an oversimplification, but it helps to consider that there are two general camps in the software development world: software engineers and application developers. It will likely annoy people in both camps to hear this simplistic view, but it helps for the purpose of this discussion. The point of this discussion is not to fit the process to the people, but rather to find the right people for the process that makes the most sense for you.
Engineers of any stripe are, by their nature, accustomed to a rigorous approach to work. They like to understand a problem fully before proceeding to a solution, they tend to be process-oriented, and they can be analytical and data-focused. Software isn’t quite as easy to touch, feel, or measure as a bridge or an electronic circuit, and so software engineers are often even more rigorous than the rest. They tend to be comfortable with Waterfall, as it requires that you be very precise in defining what your goals are, what the various interfaces are between the components in your system, and then apply the same precision to building, testing, and integrating.
Application developers are more at home with the looser nature of Agile. They like the bursts of creativity, the immediate user feedback, and the cycle of change that it inspires. This approach is best suited to consumer or business applications that are user-focused, fairly self-contained, and interact with only a few other systems or applications.
Agile Pros and Cons
While the more flexible Agile method has many supporters, there are both pros and cons to Agile development that business owners should keep in mind.
Pros of Agile:
- You, and your customer, are able to see work as it’s being done so you can comment and make decisions. More engagement on your part has a number of advantages to the overall application – there is less chance that developers will need to redo polished work, and the resulting application will be better tailored to your needs.
- You can usually get to market faster, because you are creating smaller, functional elements that are designed, tested, and refined as you go. You have the option of choosing to bring your product to market at any step along the way: the industry has embraced the notion of a minimal viable product that is just good enough to get you in the game, and that you continually update and improve once you are out there.
- Agile has a more predictable timeframe. By working in discrete and relatively short “sprints,” you’re never more than a few weeks away from your next usable release. And by tracking your performance metrics for past sprints, you can better predict where the coming sprints will get you.
- Lastly, Agile is, well, agile. The requirements can change as you think about the project. If you gain more or better information about what your users want, you can more easily incorporate these new insights into the project.
Cons of Agile:
- Increased customer participation is a double-edged sword. A customer – or a customer avatar, such as an internal Product Manager – must commit to deep involvement with the Agile process for this method to show its value. If you cannot devote someone to this project full time, chances are you won’t get the best results possible.
- Agile also requires high commitment from members of the development team, because it relies on short, intense sprints. It’s not so easy to multi-task this way, so they will likely not be able to devote time to other projects during Agile development.
- Agile prioritizes speed and customer requirements over high technical precision. It may not be the best choice when creating software that must be highly integrated with other systems.
Waterfall Pros and Cons
Waterfall is more precise, methodical, and in many ways more traditional. You will naturally find a huge number of adherents to the Waterfall method out in the software world.
Pros of Waterfall:
- Because everyone is absolutely clear on the goals of a project in Waterfall right from the start, planning and strategy is more straightforward.
- You, as the sponsor, do not necessarily need to be involved in the Waterfall project once you’ve signed off on the requirements, provided you trust your team to build it. This makes scheduling and communications less of hurdle. Customer presence may still be desirable, however, if there are elements of the development that require their input. Periodic design reviews can address this need.
- If you are involved in Waterfall, you will not be working on the project at all times, only during the phases that pertain to you. For instance, when the design phase is done, designers may move onto other projects while the other teams complete their work. This also helps with time management.
- Integration of components in a distributed system can be easier to plan when they are developed according to formal interface specifications, and on a rigid schedule. Just as an airplane comes together as components arrive from subcontractors, integration can be choreographed.
Cons of Waterfall:
- A project is only as good as its requirements, and gathering sensible, detailed, well-thought-out requirements that are carefully reviewed and approved by the customer can be a very difficult challenge. If you aren’t a Waterfall veteran, you might not know what kind of questions you need to ask – and the effectiveness of your project going forward will be severely hampered.
- Change is expensive, and must be managed very carefully.
- If you only get feedback at the beginning and you are not satisfied with the delivered result, then a lot of time and money could potentially be wasted. Good communication, from both the developers and the customer, is absolutely critical if Waterfall is to work. This can be difficult to get right.
Which do I choose?
Naturally, the right method for you depends on what you’re building, and who is building it – either your internal team or the outside firm you’re working with. It’s not unheard of, also, to have a hybrid approach: a large and complex system being built in Waterfall fashion could have components that are suited to an Agile approach.
Both Agile and Waterfall can be done right, and they can be done wrong. The difference, as in so many things, rests on experience.
At Applied Visions we are experienced in both methodologies, and our staff includes seasoned software engineers and application developers. We’ve worked for the military, and we’ve worked for software companies. Most of our work is in consumer and business applications, so we do tend towards Agile methodology, but our team can help with either method.
If you’re interested in working with Applied Visions, please contact us! Or you can call at (631) 759 3900.