Business Analyst Interview Question: What is the difference between Waterfall and Agile?
The answer requires you to know what Waterfall and Agile are, and the important differences between them.
What the heck is an Agile Waterfall, anyway?
The terms “Agile” and “Waterfall” refer to two different methods for performing software engineering. Building software happens by executing the Software Development Life Cycle (SDLC), which has a number of steps needed to successfully create or enhance software. The actions you undertake in some of the steps, and the frequency with which you complete the SDLC, are among the primary differences between Waterfall and Agile. Another major difference is in the actors involved.
Briefly, the major steps of the SDLC, and their traditional IT actors, are as follows:
- Requirements, where you make statements about what the software solution needs to do (Actors: Business Analysts);
- Design, which provides a technical blueprint for implementing the solution (Actors: Systems Analysts, Solution Architects);
- Development, where the coding work actually occurs (Actors: Software Developers);
- Testing, where the code gets tested to be sure it works properly (Actors: Software Testers); and
- Implementation, where the code “goes live” and becomes fully available (Actors: Developers, Testers, hardware/network specialists).
Another important role is that of Project Manager (PM), which manages the complexities of the project schedule to make sure everything gets done on time.
The idea of Waterfall is what I call a “Big Bang Approach.” This means that Waterfall seeks to create software that is feature-complete at the end of the SDLC. Only then does the business realize value. It’s “Big Bang” in the sense that development of all features happens at the same time.
In Waterfall, each of the SDLC steps occurs in a sequential, start-stop fashion that culminates in a “software release.” That is, you start with step 1, Requirements. You do all of the work associated with requirements. There are many meetings, stakeholder agreements, and arguing about what the entirety of requirements should be. The Business Analyst then puts out a large Functional Requirements Document where all stakeholders sign off.
The Requirements phase then ends, and you begin the next phase which is Design. That step incorporates requirements and does substantial additional work, putting out complete blueprints for the solution. Again that phase ends, and Development begins. Software developers have a large amount of code to deliver, which encompasses the entirety of all the project’s requirements.
Each phase continues in sequence until the entire project is complete and the “software release” occurs. Only then does the team deliver business value.
There may have been requirements that got knocked out of the project in the Requirements phase, or requirements that were discovered too late in a later phase, which may start the process over again for a subsequent software release. But for all intents and purposes, the solution described at the end of the Requirements phase is what the developers deliver at the end of the project.
Pros and Cons of Waterfall
The biggest advantage of Waterfall is that you know what you’ll be getting at the end of the project. Since the final solution needs to completely map back to the original requirements, a business can anticipate all of the features it will receive when the solution is complete (at least in theory). And, based on the schedule, the business also knows when the project will be feature-complete. In turn, this allows for more accurate budgeting and Return on Investment calculations.
There are a number of disadvantages. First is that Waterfall is slow and time-consuming. This is a problem at a time of need for increased speed to market and the ever-quickening pace of technological progress. It is also frequently document-intensive, increasing the possibility of mistakes when someone misses that requirement on page 349, paragraph 5, subparagraph a(1)b. Waterfall can be process-intensive with many reviews, checkpoints, and other mechanisms for keeping a complex project on track.
Lastly, when you try to build a complex solution that contains a number of “moving parts” or interfaces, the possibility of error increases exponentially because you’re trying to do it all at once. If errors or omissions happen, you may not have time or money left to fix the problem properly. So while a business may anticipate a feature-complete solution, what it gets in reality may fall short if there were unanticipated problems.
The “Agile Manifesto” perfectly and simply describes the philosophy and methods behind Agile development:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile is a response to the slow and process-heavy Waterfall method. It recognizes that things have to be done faster. It also respects the fact that when you’re building a complex solution, sometimes it’s better to develop it one simpler component at a time.
Agile development is iterative and incremental. You start small. Oh, you may have an overarching story of what you want to accomplish with your solution (called an “epic”). But you’re not going to build the whole story at once the way you would with Waterfall. That epic breaks down into small user stories that comprise your primary requirements. Rather than trying to tackle all the requirements simultaneously, an Agile team tackles only one or a few user stories at a time.
There are three important actors in Agile:
- the Scrum Master, which removes roadblocks and tracks progress for the project;
- the Product Owner, which represents/advocates for the business and ensures the solution meets business needs; and
- the Development Team, which does the coding.
The various Waterfall roles can often get slotted into these three main roles. For example, a Business Analyst could become a Product Owner, and a solution architect could join a Development Team.
How do you perform Agile?
The most common way of doing Agile is through a process called scrum. Once there is agreement on which user stories to begin with, the PM initiates an intense period of activity called a sprint, which usually lasts a few weeks to a month. The sprint tackles the selected user stories by employing intense collaboration, often including daily “standup” meetings to discuss requirements and coding progress. Rather than creating tons of documentation, people talk things out and develop solution features in real time. The developers report on what they did and what they will be working on at the “standup” meetings. At the end of the sprint, the features are presented to the Product Owner for acceptance of what was built (or rejection of it.) The team gathers its “lessons learned” which include what worked well, what didn’t, and how to improve the next iteration.
The team keeps a product backlog with a prioritized list of future features, as well as any requirements that came up during a sprint that the team could not resolve. These features can become part of subsequent sprints/iterations.
In Agile, the business gets to see value at the end of each iteration. The business therefore waits far less time to see business value than when using Waterfall.
Pros and Cons of Agile
The pros of Agile are easy to see. You don’t have to wait a long period of time for a working solution. You can obtain a “minimum viable product” very rapidly, and improve it later with subsequent iterations. The documentation requirements are much less burdensome. Agile allows you to respond quickly to unexpected or rapidly changing situations. These features make Agile a great way to do software in a world of rapidly increasing speed to market.
The biggest downsides to Agile, in my opinion, are related to budgeting and accountability. In Agile, you don’t necessarily know every feature you want in your final solution. (Part of its appeal is that you need not determine everything before getting started.) If you don’t know everything that will go into the final solution, it’s difficult to estimate how long the project will take or how much it will cost. This can be a problem for an organization’s capital planning activities that often occur far in advance of a project launch.
Additionally, given the lack of up front analysis, it is likely that unexpected problems and requirements will pop up. Many of these will have to be pushed into future agile “sprints.” Unlike Waterfall, which commits to a feature-complete solution at the end of the process, Agile takes more of a “wait and see” attitude about the final product. This therefore creates the temptation to continue pushing features out to additional iterations, increasing time and cost. On the other hand, this may also be a more realistic approach that recognizes the likelihood of rapidly changing requirements and market conditions.
How to briefly answer an interview question about the difference between Waterfall and Agile
Now that you know the basics of Waterfall and Agile, you could briefly answer an interview question in a manner such as:
Waterfall and Agile both refer to methodologies used for building business solutions. Waterfall is the traditional approach, requiring full planning up front to nail down requirements. Subsequent phases of design and development happen sequentially based on documentation created in prior phases. This leads to a successful final product, but the process is often too slow to meet current market needs. Agile leverages close collaboration in favor of extensive documentation. It employs a series of short “sprints” that build the solution iteratively and incrementally. This facilitates rapid development of a working prototype that can then continue to be improved over time with future iterations. Agile therefore lends itself to tight solution development schedules in response to rapidly changing market needs.
How would you answer an interview question about the difference between Waterfall and Agile? Leave your thoughts in the comments below!