Plan-driven versus Agile = Predictive versus Adaptive
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.
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.
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.
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.
The book Agile Leadership is about organizing software development and leadership in a knowledge based organization. 
I like your entry but I have a question – how are these changes in what the customer wants priced? I mean, in the end, we’re talking about a business, and if customer signed off on B but wants C, how do you price these changes along the way?
/Hila Annis (send to me through http://www.linkedin.com)
Hi Hila Annis,
Thanks for a good question. I have tried to answer your question in a new post If You Adapt to Change! How do you handle the Price?. Hope you find this answer satisfactory.
Regards
Patrik Malmquist
Pingback: Tweets that mention Predictive versus Adaptive | Applitude -- Topsy.com
I’m so lucky to have found this blog page. You practically told me exactly what I preferred to hear and then some. Beautiful publication and cheers again for doing this no price ! ! .
Thanks for writting this, glad I be of assistance.
Thanks for a great post, looking forward too the book.
Got a great link thanks to this post yesterday. It’s an article written C++ Journal in 1992, never mind the C++ perspective. It’s a great post: http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
Q: Is agile approach the best or applicable for all/most projects? The discussion here and elsewhere in Agility forums doesn’t convince me on that point. Seems like Agile approach is based on the assumption that customer doesn’t fully know what he wants or will change his mind about it along the course. All/most of the arguments is related to be able to manage this situation. Off course this is a challange and it seems reasonable that the agile approach would be advantegeous. But assuming the customer knows what he want and does not change his mind about it. What are then the pros and cons for Agile approach? I don’t find many argument in this situation. Or is it the experience/assumption that a stable goal/requirements situation never/seldom happens irl?
Thanks for that questions. The short answer to if is the best for all/most projects is absolutely NO. I will try to explain in a while, I get back to you.
A frequent argument for Agile approach is benefits in manage changes during the projects cause. Here I think it is called upon to better understand why changes occur. Is it the customer that changes his mind about what he wants? Or is it the uncovering of that the development team didn’t understand what the customer wanted in the first place? Is it an actual change of requirements, or is it just perceived (by the developer) as change of requirements? Aren’t these two different situations which needs to be addressed differently? In what way is the Agile approah helping the customer for the latter situation? From a business and commercial perspectives I think this question have great impact. Why shall the customers pay for developers inability to understand the actual requirements? Who is taking the risk when communication of requirements is difficult? Who is (commecrially) responsible for understanding the actual requirements correctly? Frequent delivies of small increments and face to face communication seems great. But is it enough?