Predictive Planning vs Adaptive Planning
While doing my efforts of promoting agile practices down here in Costa Rica, it is normal to meet skeptic people that simply don’t want to swallow the agile argument against a Big Design Up Front, commonly associated to waterfall model.
Those skeptic people are quick to get offended when I say that Software Engineering is not Computer Science. They take pride in citing Frederick Taylor’s “scientific management.”
And maybe that’s the problem: The traditional project management approach was tagged as “scientific”, so anything else that is not traditional project management is not “scientific”. This argument is not only a Denying the Antecedent fallacy, but also it’s a clear disregard of the fact that the empiricism (the foundation of Agile) is a cornerstone of the scientific method.
So these are the arguments I heard from them:
- “The absence of up front planning in Scrum gives to much freedom to the customer”
- “Given that the client can change anything in the backlog, you can’t take any stable architectural decisions”.
Why this is not a problem?
- Vision must to be clear up front. We are going to build an account system or a social network? What is the value obtained with this project?
- Agile does Planning. Agile does just enough up planning in order to have User Stories. The team should have enough User Stories to make a Release Agile Planning where costs of user stories are given based in complexity and dependencies between them. Afterwards, long enough architectural and design discussions take place before starting the first Sprint.
- Through the iterations, Adaptive planning is performed while the team takes advantage of the flexible architecture that was chosen.
- The most valuable User Stories are delivered first, each User Story represent an End-to-End functionality that traverses all the architecture required by the system, that is what is called a Walking Skeleton. So the team has a clear vision of architectural requirements from the beginning. That vision is clearer as the User Stories are consumed.
- An important rule to remember is: The Customer can change anything in the backlog as long as he/she stays within the constraints of the
Iron Triangle[Update: I better use "Agile Constrained Triangle", A concept I just made up to depict a Triangle where the constraint of Scope is flexible, but Time and Cost are not]. That is, the client can delete User Stories or replace cost-equivalent User Stories. If client wants a User Story that can’t be implemented with the tools, design and architecture, that means that the vision wasn’t clear at the beginning of the project. Please observe that more up front planned user stories would have not avoided this problem. This is not a problem of lack of depth, it’s lack of breadth. Up front planning deals, by definition with, greater depth. What I’m saying is that the same problem would have happened using any kind of project management. On the other hand, if the User Story the customer wants is more expensive than the one being replaced, it is also breaking the cost constrain, but in a lesser way. So that’s why I recommend flexible contracts with scheduled buffers to handle those minor changes in cost.
Joseph,
you’re lucky enough to live in a pure Scrum world. Those of us that are only in the beginning stages of the journey benefit from a post like this. You wouldn’t yell at a 6 month old baby for not being able to tie her shoes. Let us (babies) learn from this blog post. If you don’t like it, skip it.
Cheers.
The arguments against Srcum in the beginning of the article define the view that traditional Project Managers have about Scrum, and Agile in general.
I have lots of arguments against your list of “Why is this not a problem?”, but I would like to discuss #5 in particular.
You say that the customer has to be within the constraints of the iron triangle. Well, the bad thing is, 99% of the times, this is isn’t the case. Change requests often happen, and they do affect that triangle (anyway, even according to the PMBOK, that triangle is dead). Additionally, this statement “the vision wasn’t clear at the beginning of the project” is contradictory to why Scrum/Agile was first devised and applied, isn’t the whole purpose of Agile to be fluid enough to manage (software) projects where the customers usually don’t have a clear vision of what they want?
I should not have said “Triangle of Iron”, but Agile Constrained Triangle, where the constraint of Scope is flexible, but time and cost are not. Agile says that Scope is flexible given the uncertainty of the technology used to build the product and business environment (that is, client clarification of what she wants). In those terms, Scope (Product Backlog) can change as long as cost and time are kept fixed.
And regarding the vision, if you don’t know where you want to go, nothing can save you. Agile says: “Where do you want to go? To that peak of the mountain? Ok, instead of planning up front every single step and move we have to do, we’ll take those decisions as we go, but certainly we have to have the skills to do it and the clear goal in order to reach it”.
Please no more “vs” articles. The market has moved so far beyond this type of comparison it is like people saying, “Web 2.0 is important”.
I am sorry to be so blunt but I am just tired of all of the comparison articles. There are enough of them. If someone wants to read and understand the difference between one and the other they have AMPLE articles to read. Please don’t add to the noise. Make some new thoughts, some new ideas, push the boundaries. This code is working, it doesn’t need more tweaking, it is good enough.
Oh BTW I am a Scrum Master have been doing scrum only projects for several years and am an agile coach.
Thanks for the valuable observation Joseph, especially when I realize that the title I gave it doesn’t match very well with the content of the post
I am curious, how do you handle the type of real-life, dichotomic objections I discuss? Certainly the answer should be targeted to the value of agile rather than emphasizing the conflict between agile and traditional approaches.
Joseph,
you’re lucky enough to live in a pure Scrum world. Those of us that are only in the beginning stages of the journey benefit from a post like this. You wouldn’t yell at a 6 month old baby for not being able to tie her shoes. Let us (babies) learn from this blog post. If you don’t like it, skip it.
Cheers.
Social comments and analytics for this post…
This post was mentioned on Twitter by agilenature: #agile New blog post Predictive Planning vs Adaptive Planning http://bit.ly/5d3xVd...
[...] Predictive Planning vs Adaptive Planning » David Alfaro: Scrum Costa Rica agilenature.com/2009/12/04/predictive-planning-vs-adaptive-planning – view page – cached Predictive Planning vs Adaptive Planning [...]