Waterfall, Agile & the “Triple Constraint”

Anyone who has ever worked on a project probably realizes there are three (really four, but people often forget about the fourth) criteria that project success is focused on:

1. Features (Requirements)
2. Estimates (Cost)
3. Schedule (Timeframe)
4. Quality (Often forgotten about since it is hard to see/define/measure)

Regardless of whether we use waterfall or agile, we need to be concerned with these 4 elements.

Process

Below is a breakdown of how the two methodologies (waterfall and agile) approach this criteria.

     Waterfall

In Waterfall, we constrain requirements, meaning we must deliver 100 percent of requirements. Based on the requirements, we estimate the time (cost) and schedule it will take to deliver those. We then define a plan and work to stick to that plan. This means we try to predict the future by estimating and limiting changes from occurring on the project. If we were perfect, we would always be able to deliver 100 percent of the requirements with the exact cost and schedule we estimated, and nothing would change during the course of the project. But we are not, and will never be, perfect. So when a project is behind, the cost and/or schedule (or quality) will have to change in order to deliver 100 percent of the functionality. We see this when we get close to the end of a project and either add resources, push the release date or release and deal with a lot of post-implementation production issues.

     Agile

In Agile, we flip the constraints upside down. Rather than constraining requirements, we instead constrain the cost and the schedule. Based on the provided cost and schedule, we then estimate the features that can be delivered. This means we follow a process that tries to adapt to change. By doing this, we make sure we deliver projects within the cost and schedule, and since the backlog is prioritized based on value, we deliver the highest priority features for the cost/schedule. This approach welcomes change, which means as you learn more you can shift the priority of features. So when a project is behind, we cut the lowest priority features to insure that we deliver the most important items within the cost/schedule. We see this when we release a project on time, but some of the less valuable features do not make the release. With this approach, the stakeholders can make a decision on if they want to spend the extra cost/schedule for the lower value features, or if they would rather invest their money into other projects/features.

Planning

So when we get to planning projects, the approach looks quite different between the two.

     Waterfall

Waterfall is a plan-driven model. In order to create a plan we can stick to, we must (try) to know everything upfront. So we spend a long time understanding and documenting requirements, then we use those requirements to create the design. After this, based on the detailed requirements and design, we develop the features and test the features. Once all of the features are developed we have the users test the features and release them to production. This model involves estimating each features and creating a plan/schedule based on those estimates. The project manager then follows and tries to hold people to this plan in order to deliver on time. As previously stated, if something needs to slip, it will be the project cost or schedule.

     Agile

Agile is a value-driven model. Value is defined by being able to actually use functionality that  provides a return on investment (ROI). In order to deliver value, we need to complete functionality. Since agile estimates features, all of the features may not make the release. Therefore, agile planning focuses a little on understanding all of the requested features and their priority level, but then it focuses on actually delivering the top priority features as soon as possible. This means that after the first sprint (ideally), some of the features are completed. Assuming the stakeholders agree, these features can then be released and provide ROI. Then the team repeats the cycle with the next top priority features and this continues until the cost/schedule constraints are hit. Less focus is on planning and more focus is on delivering value.

Among the many benefits to agile, my favorite is that it forces you to stay within cost and on schedule.  You may not deliver all of the features, but you know that you will not overrun your cost, and can make the decision on if you want to invest more money to continue the project.