The inspiration for plan-driven methodologies came from other engineering disciplines such as civil and mechanical engineering. In civil engineering, it is less costly to change requirements during the design stage and it is more expensive to adapt to changes when construction has already started.
Therefore a lot of energy is put into the planning phase. When the drawings are specified and finalized, it is reasonably easy to predict the schedule and budget for the rest of the processes, because both the requirements and the technology are known. Once we have the construction plan, the construction is more predictable. The nature of these projects is to resist changes, because it costs too much to make them after construction has started.
Software development is different. There is no guarantee that a good design will make construction predictable. In civil engineering, the time spent on construction design is often less than 10% of the project’s total budget. In software development, it’s more common that over 50% of the total budget is spent on design and understanding requirements. When we adopt the civil engineer’s approach, anything that wasn´t planned causes a problem. We need to reach (B) as planned when the project plan (Time, Money and Scope) was approved.
Image may be NSFW.
Clik here to view.
Construction is less costly in software development. So why not adapt to change as we learn more during the process? Changes in the requirements during the process of developing a system leads to increased information about the system, and thus enabling better decisions because of this additional information. This is how competitive advantage is gained.
Image may be NSFW.
Clik here to view.
If we could use methodology that allows us to change, we will know more without incurring major costs so it would be a mistake not make the required changes. If our methodology allows this, the output (the system or product) is going to be worth more than the product we would have had have from the original design (C) >= (B).
A Difference View of Success
The plan-driven methodologies defined success as the delivery of agreed functions on time and on budget. But agile methodologies promote the idea that there is something nobler to strive for, because sometimes the customer remains dissatisfied even if he got everything he asked for! This is because he got (B) but at the end of the project, he now wants (C).
Customers also adapt but if they change their mind about what they want and you prefer not to make the requested changes, problems could arise.. Either you or the customer will be disappointed. Success for Agile methodologies depends on knowing more which makes it better for us to adapt to new goals. This gives the customer what he wants at the end of the project (C).
Conclusion
If customers don’t know what they want when the project ends, how can you design a system in the beginning when you don’t know what the understanding was? If your design isn’t good enough to predict the rest of the work, it won’t be such a good idea to design too much in the beginning of the project.
Image may be NSFW.
Clik here to view.
And if you cannot establish requirements you cannot make a good design and in turn, you cannot get a predictable plan. The Agile approach is to welcome change so if your assumption is proven wrong, you redefine the goal and set new priorities. At the end of the project journey (C) this new goal will be worth more than the first defined goal (B).
Because the customer and stakeholders are allowed to change as they learn more new things, the value of (C) becomes greater than (B). This of course builds on the idea that you manage to deliver (C) according to time and budget restrictions.
Image may be NSFW.
Clik here to view.