There are two predominant approaches for software development which are in common use. The first is referred to as Waterfall, the second is called Agile. There are advantages and disadvantages to each, and of course, there are many variations to how each of these show up in practice. This post seeks to help you gain a general understanding of each. Hopefully, it will help you make decisions about how to approach software development projects.
The first approach is called Waterfall. This type of software development process works well when there's a clear vision of what's needed that translates into well-defined requirements. Clear requirements up front allow development of a very specific software program design so that you can then know what the software will cost and how long it will take to develop the end product.
Here's How It Works
You create a set of business requirements for your end product. Those requisites are passed on to a design team who work through a process with you to create a design expressed as functional requirements. Functional requirements are documents that provide a level of detail that software engineers can use to design and build software. Then, the completed design is reviewed and approved by you. At this point, the development team can define the development timeline and the cost for you. Once approved, the design (functional requirements) goes to the software development team to write the code. The QA (Quality Assurance) team will test it to make sure it works and meets the documented specifications. Normally, this is followed by a beta release time period where the business users can test the new software in their environment. Finally, the program is released into production. At this point it enters the maintenance phase where any further problems or enhancements are handled with software updates and patches.
Benefits
This approach aims to deliver cost certainty. It can work well when the requirements are very well understood by business users and clearly communicated to the development team. By investing in software engineering design based on the specific requirements up front, the development team can create a fixed budget and lay out a timeline. If you know what you need, this approach creates more certainty around budget and timeline, and who doesn't like that?
Drawbacks
The real question is are the requirements really well understood by both the business users and the development team. Envisioning a large software application where nothing exists is challenging, to say the least. Creating extensive documentation of the requirements requires significant effort (and cost). And that documentation is generally not easy to follow for non-technical readers. Another intrinsic drawback of this methodology is that it can make changes more difficult or costly because the requirements were not really that well understood and the need for change may not be identified until the product gets into testing. So what might have been a small thing to change early in the process could become a large change because as development continues additional dependencies are built on top of that thing that needed to change. Another drawback is that the Waterfall process often leaves a long gap between development of the requirements and when output is visible to the business users. That can get stressful for the end users who want to see something sooner rather than later.
The Key Point
Much like in real life, you can't send things back up the waterfall; it is vitally important that you have a clearly defined vision for the end product because its predictability and efficiency is intricately tied to accomplishing each milestone at a precise time.
Agile
In response to the downsides of the Waterfall approach, especially it’s assumption that all requirements are fully known up front in detail, a different strategy emerged known as Agile (for the core principles of Agile, check out the Agile Manifesto) This methodology puts higher value in quick feedback loops and customer collaboration than on the completeness of up front requirement documentation and design. Agile made the design process more flexible by focusing on putting pieces of software into the hands of users early rather than waiting for a 100% completeproduct. Thisapproach better suited to handle deficiencies in the specifications, bugs in the software, internal conflicts, new specifications, and changes resulting from new standards or advances in technology. Instead of having all the requirements fully detailed out in long and hard to read documents at the beginning of a Waterfall project, the Agile approach allows the business to begin building a valuable product before nailing down a complete vision for the whole solution. The focus becomes getting value in the hands of customers quickly, gathering feedback on what is working well and what isn’t, then iterating on the high value areas with additional pieces of functionality. . This approach also limits the amount of retrofitting/shoehorning often done to implement new requirements late in the game. Due to Agile’s iterative nature and the feedback of customers collected early and often, change is generally much easier and cost effective. With so much focus on producing small quick value, reflection on customer feedback and graceful response to change, the Agile Methodology creates an excellent framework for clients and development teams to partner together in creating highly effective products.
Here's How It Works
This process kicks off with some initial high-level planning which says "I'm going to have these starting inputs, and I want to get this result as the output. How do I make that happen?" In a series of logical steps, the process is analyzed and a set of features is developed that represent the high level scope of the project. Then, the features are grouped into a series of iterations (generally called “sprints”) which are prioritized for development. Each sprint delivers functioning code which gets into the hands of the end users for review and feedback. This allows the users to identify changes that can quickly be coded in a future sprint. It also allows the vision to get refined through collaboration between the developers and the end users.
Benefits
Agile provides working functionality quickly and allows for adjustments and changes to the software throughout the process. Generally, the software development team does not get too far down the road (which can be costly) before the need for change is identified. This approach gives you as the business user many opportunities to speak into the process and refine both your vision and the software as the project proceeds.
Drawbacks
The inherent flexibility of Agile and the lower level of upfront definition of requirements at a detailed level can leave a certain amount of uncertainty about how much of your budget it will take for you to get to the desired future state. But the process is very effective at forcing tradeoffs between budget and functionality and can help you clearly define what is a "want" and what is a "need" to make your solution work.
The Key Point
The Agile approach offers flexibility to get you exactly what you wanted, but it comes with uncertainty. Since the requirements aren’t fully known at the beginning, it can be difficult to apply a fixed budget or timeframe to the project. On one side of the coin, you may quickly realize what you do and don’t need in the project, thus cutting out unnecessary scope (and cost) from the project. However, on the flip side, there could be additional overhead as the project is tweaked, refined, and adjusted to better suit the end goal and you added in new features and specifications.
The Takeaway
Waterfall’s greatest strengths are its fixed costs and predictability. You know the price, and when it is going to be delivered. Its most significant weakness is its inflexibility. This can be overcome with a good partnership between the software development company and business side stakeholders. The Agile approach is extremely flexible and could evolve into a significantly different product than was originally envisioned. It leads to a product that performs exactly the way you want it to, because you’ve learned more about what you want along the way. If the project is simple, straightforward and you are committed to accepting exactly what you ordered, then the Waterfall approach is likely the best solution. On the other hand, if your expectation is that a fast-moving, quickly-changing industry will have evolving needs during the development process, then Agile is the best choice.
Now you know!