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.
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.