The plan-driven model of development
In the field of software, the plan-driven approach frequently uses the Waterfall model, which consists of these phases: system requirements, software requirements, analysis, design, coding, testing, and closing. These phases are executed sequentially. The plan-driven model has been effective for projects in many industries. The world of software engineering, however, is relatively new compared to the field of "pure" science, and when we attempted to apply this model to the world of software it was less successful. The reasons include the following:
Creating detailed specifications is time-consuming and does not add any value to the product. (Still, we thought that the more we wrote specs, the more we would be able to manage risk.)
Creating WBS (Waterfall-based software) is challenging because of the complex nature of project.
Estimating accurately is difficult.
Having an exact picture of whether the project is on track is difficult; it's not clear if the work items are completed or not.
Project tend to finish late, over budget, with a high rate of defects or fewer functions than intended.
The unexpected always happens during the execution.
Requirements are often not correct or detailed, clear, or consistent, so they are not ready for the implementation. Some have been omitted, changed, or updated, and thus resolving these issues is time-consuming.
Items that are thought to be completed really are not and need an unpredictable number of revision cycles to finish.
Development work is unpredictable due to quality issues.
Teams are distracted by the need to manage change requests or issues related to the lack of clear requirements.
Scope creep happens at the end of the project in the form of change requests from end users, since they missed the train in the beginning and now, at the end of the project, they notice that the most-wanted features are not yet implemented.
Integration takes longer than expected and is more difficult.
Testing results in more defects than can be fixed in the allocated time.
The key point here is that in software projects, uncertainty is a given. The cumulative effects of uncertainty extend the project duration beyond the planned period and waste development funds, energy, and time on the wrong features or on poor-quality features.
Moreover, once a project starts, the Waterfall approach includes a phase that creates and then signs off on the set of requirements. The project manager assumes that this sign-off results in a fixed set of requirements and that now planning can begin. The project manager estimates how long it will take to complete the requirements and then creates the project plan. The plan predicts that the project will be finished by a certain date, and that date is communicated back to the customer.
The fundamental logic behind this approach is that the plan, which drives everything, is based on an assumption that the requirements are fixed and won't change. Experience has shown us that this is never the case. Requirements are never fixed -- they always change. When the requirements change, the plan is affected; as a result, the completion date needs to change too. Unfortunately, that is often impossible, and the team has to deliver by the date they committed to. This is when a major crisis occurs and the project starts to go out of control.
To overcome the drawback of the Waterfall model, Agile methods gained traction. They promote collaboration, results, and adaptability over following plans -- all of which means using a value-driven approach, not a plan-driven one.
The value-driven model of development
The value-driven Agile approach is different from the plan-driven approach. It assumes from the start that requirements that exist up front are not fixed and that they will change. The Agile mind-set also assumes that you have to deliver by a certain date. This approach fixes the time and resources and leaves the requirements undetermined. This model resembles more closely the reality of creating software. Indeed, when you have a fixed amount of time in which you aren't sure whether you can deliver all the requirements (because they will change and hence the time needed to finish them will change), the natural reaction is to prioritize the requirements and finish first those that add the most value for the customer.
We may be thinking, "What about the requirements that aren't finished by the delivery date?" That is the reason you use the value-driven approach. You acknowledge that not all the requirements will be completed by the delivery date. The important question to ask is whether we will have delivered enough
features to support a system that provides the highest value to the customer.
This does not necessarily means that the method will get rid of uncertainty and risk. They are still there during the project's entire lifetime, but we manage to lessen them by embracing change from the beginning and installing a mechanism to respond to it. Furthermore, because we are splitting up the work into small, experimental phases and incorporating quick feedback loops, we are able to inspect and adapt within the given time frame. Therefore we reduce the cumulative effect of risk and we improve along the way, based on our experiments and data. From a budget perspective, we limit the project cost to a sprint or release horizon rather than to the project horizon, as we do in the plan-driven approach.
To illustrate this idea, when uncertainty is high we don't know exactly when we will finish the project or how much it will cost; it's a roll of the dice. Many risky factors can influence the project and lead to its failure. For example:
The project might be delayed.
Funds may disappear.
Business priorities change, the company may go out of business, competitors may get to market faster, customer interest may change, etc.
In this case, risk is more about losing the entire investment than having a lower ROI than expected. The value-driven approach reduces risk since it splits up the entire project into many phases (sprints). The risk still exists, but it's shortened to a sprint-length horizon, and therefore stakeholders have the opportunity to decide whether or not they will carry on the project. Thus, funding is associated with a sprint horizon rather than the end of the entire project, as happens typically in the Waterfall approach. There the group may decide that the project is a failure and realize that they invested X number of months for nothing.
The Agile incremental delivery not only reduces risk but also provides superior ROI since we make sure that we invest in the right product at the right time. As far as we go, we have the chance to decide whether we continue with our product or whether we stop. For example, if funding problems arise after five months of sprints, we are sure that we delivered the highest-value features in the beginning, and consequently we have a high ROI compared to what we invested initially.
To conclude, the value-driven model is adaptive in the sense that it admits that early plans are necessary but likely to be flawed, so planning and adaptation activities should be scheduled into the project. Since there is the chance that plans will be missed due to uncertainty, we will need to replan. This is simplified by splitting up the total amount of work over a fixed length time, and at the end of each time period we inspect the outcome and we adapt the plans, evaluate the risk, and adjust accordingly.
To illustrate this, think of a project as a trip from a local city A to a city B. We make a plan to fly from A to B. To get there, we use itinerary maps, flight maps, etc. Once we arrived at city B, we can rent a car and use its GPS to travel around the city. Everything is planned, known, and predictable. Then let's assume that there is a flight delay. In that case, we can compare where we are now to where we would be by now if the delay had not occurred, always referring to the baseline plan. Tracking the variance between the baseline plan and the real plan (pointing out release planning based on velocity) allows us to make projections. These events are assumed to include risk, and there is a contingency risk associated with its predictability, so we can take a different route and react accordingly. It could be as if the flight were delayed and we took the connection from city A to city C and then from city C to city B.
The uncertainty could be like an adventure across a desert that nobody on the team has visited, using an old and inaccurate map. Instead, however, as a team we fix a goal, agree on a general plan, and set off in the direction we think is most likely correct. If we meet an obstacle that is not on the map, we do not blindly attempt to follow the map and the plan; we accept that our plan is flawed and update our journey based on the information that we gathered through this experimentation.