- Knock knock.
- Who’s there?
- Project scope.
- Project scope who?
- Project scope has been expanded again, we need another month.
In the software development world, “project scope” can sometimes become a term used as a joke — since so many projects end up taking more time and effort than originally planned.
Currently, there are two main workflow models that software development companies use: Waterfall and Agile. In this blog, we’re going to take a look at each model in an effort to help decide which one is right for you.
What is the Waterfall Model?
Interestingly, the Waterfall model dates back almost 50 years! Briefly, this workflow follows a logical progression of steps throughout the software development lifecycle process — not unlike a cascading “waterfall.”
There are six stages of “falling water”:
- Requirements - Analyzing and recording the possible requirements of the project in a document, which serves as the ultimate reference for all future development. Usually, this document lists what the project results should be, but not exactly how it should be done.
- Analysis - A close look at the system in order to properly develop the models and business logic for the project.
- Design - This stage handles the technical design requirements, including programming language, services, etc. The creation of a design specification, outlining exactly how the business logic from the previous stage will be implemented technically.
- Coding - Writing the actual source code, including all the elements developed in the previous stages.
- Testing - This stage is when quality assurance (QA), beta testers, and any other testers discover and report any issues that need resolution. It’s common for this phase to require a repeat of the previous stage.
- Operations - The final stage is ready when the project is ready for deployment to a live environment. It also includes any follow-up support and maintenance required to keep it functional and up-to-date.
Issues with the Waterfall Model
While the Waterfall workflow has been a reliable method for decades, it doesn’t work for every project. Potential pitfalls for Waterfall users include:
- A more traditional workflow may be counterproductive since some clients may not specify every single detail of their project; also, new complications or requirements that arise can clash with the “Step 1, then Step 2, then Step 3” process. Waterfall leaves very little room for unexpected changes and revisions.
- A lack of adaptability across all stages is a major issue of the Waterfall workflow. For example, if a major issue is found during a test in Stage Five, it may mean a giant leap backward in the process.
- Adhering to a strict, step-by-step process can mean that client or user feedback can be provided too late — leading to costly, time-consuming fixes.
- The Waterfall model doesn’t use much testing until late in the life cycle. This means that many bugs or design issues may be caught late in the process.
NOTE: For comparison, our review of Agile methodology can be found here.
How to Choose Between Waterfall and Agile
Waterfall is more straightforward and easy to understand, and works well in extremely buttoned-up environments in which requirements are set in stone and documentation is in order. These limitations become more obvious depending on the size, type and goals of the project.
On the other hand, Agile is best used for projects in which speed, flexibility, and constant iteration are valuable. Open-ended projects with continuous software development can benefit from an Agile workflow, especially when there is clear communication between the teams and client throughout the process. Plus, Agile enables a team with strong leadership to catch mistakes early and handle them quickly.
Code Authority Recommendation: We’ve seen success with Agile, which is better for smaller, dedicated teams working in a fast-paced environment with a high degree of collaboration. We have a great deal more constant deployment, maintenance, and updating to handle, and Agile helps us get it all done — even for clients who vacillate on their decisions, expectations, and demands.
While “scope creep” is not really a laughing matter, we’ve demonstrated why Agile is the workflow of choice for Code Authority.