Agile vs. Waterfall- Scope, Schedule and Cost
Understanding the Differences
Agile is a value-based, iterative approach under which business needs and solutions evolve through the collaborative effort of self-organizing cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. The traditional Waterfall approach is a sequential process of a series of activities or phases that need to be complete before moving forward to start a new phase. The requirements are identified upfront and the customer does not have the opportunity to interact with the product and provide feedback until the final product is delivered. If there is a change to be made after the final product has been delivered, there will be a high-cost associated with it since there was no prior opportunity to course-correct and the changes have to go through the full process again.
|Traditional Waterfall Approach||Agile Approach|
|Sequential product development/delivery process where each phase needs to be complete in order||Time boxed and iterative/incremental product development/delivery|
|Requirements and design decisions are made upfront||Product Owners and Development Team have the opportunity to negotiate and re-prioritize requirements throughout the development process|
|Months of planning before development begins||Intermediate milestones: deliver in deployable increments with useful features, it may have minimum viable product functionality|
|Broken into stages that need to be completed before you can go to the next||Complete transparency in development process, each iteration/sprint delivery is done when it is programmed, tested, and so on|
|The customer sees the product for the first time when final product is delivered||Customer is constantly interacting with product and providing feedback|
|Making changes so late in the process can be expensive and time-consuming||Changes are embraced in the iterative process through constant communication and prioritization|
|Only one initial investment to be spread out over the project timeline||Incremental investment process where money is released with phases|
Agile Investment Approach
What is the Agile Investment Approach?
- Development Approach: An Agile, phased approach to prototyping potential solution investments
- Business-driven: Identify strong product owners (business-side) with available time commitment
- Budget: Stagger release of funding dollars to reduce spend and make more informed decisions
All pilots begin with an approved Business concept. Once the Product Owner and Scrum Team members are identified, the CTO Office then engages the right resources for Discovery that will lead into the Proof of Concept (PoC) phase and beyond.
- All projects derive from approved Business concepts
- All projects engage the right resources for success
- Not all pilots lead to prototype / scalable solutions
Why use an Agile Investment Approach?
- Reduced risk and improved IT investments
- Increased collaboration among IT & Business Owners
- Provide faster solution delivery & increase transparency
During the Discovery Phase, a goal is set and the team will identify 1-2 high-value use cases that will quickly acknowledge whether the solution chosen is the right one to meet business needs. Right away, every sprint (typically 2-3 weeks) allows stakeholders to see and track progress.
While a traditional waterfall approach can work well for projects with routine and predictable requirements, an agile approach is a better fit for large cross-functional, complex products because it allows you the flexibility to make changes to requirements as they become available.
In the phased investment approach, an agile team learns early what works and what does not, which gives them more knowledge on the product and alternatives. Releasing the funds in increments allows an agile team to better inform investment decision-making and potentially reduce their overall spending. The advantage of the incremental approach is that the team learns early, fails early, and can course-correct while the budget is still intact.
Often times, in a Waterfall approach, defects are not discovered until the end of the process when testing takes place. Once the errors are exposed, the team has to retrace steps back to the beginning, while the project budget and schedule are both at risk.
In order to measure success, a product must meet the success criteria determined at the beginning of the project. Typically, the criteria will include meeting all customer requirements and business lines getting to see the product early and making decisions. These decisions are an important part of determining success as they range from the ability to learn early and stop before spending all funds, to if the product plan proves not feasible during the discovery or proof of concept phases.