It is common in the Agile community of voices to compare Agile Software Development with something else to sell it's benefits. Something the Agile audience can see as undesirable. Some phrase those looking for a reason to move to Agile that tehy can get behind. This appoach is simple, easy, and of course wrong.
The first choice of the something is "waterfall." Waterfall is a code word for the linear design-code-test with little or no feedback. And that approach to project management is of course is simply Bad Project Management, really bad Project Management. The style of development that is not even used in the US Government Defense systems.
The next comparison is the "predictive approach." This is defined by one Agile thought leader as...
... predictive, shapes the definition of Scope, control of the Project Schedule and Cost, and management of software development process based on roots in scientific management, plan driven management, and manufacturing.
No source for this definition is given, so I'll take the liberty of tossing out the last word, the manufacturing piece, since by definition a project is a temporary endeavor and manufacturing is operations.
But le't use a simple approach in the rhetoric class. Does the inverse of this statement make sense to anyone? That is can we all agree that the invserse is truely the opposite?
I like all dog with brown coats. The inverse; I don't like dogs that don't have brown coats.
If not then the first sentence - the non-inverse - is nonsense as well.
So if Agile, is the alternative to Predictive,
Do we actually seek to NOT have a process that can predict the cost and schedule of the project?
Do we seek a method that can NOT define the overall Scope of the project?
Are we really seeking a software development method that does NOT have control over cost, schedule, and the scope?
Another concept used is the Winston Royce paper in 1970 showing the "waterfall," approach. Common and used in the materials I'm referencing is the clip from the first page of the paper. The final diagrams shows a fully connected - that is all boxes are connected with each other - diagram with feedback from all work to all work. This is simply bad writing and simple misrepresentation of the facts.
Having worked in the same building (TRW O6) are both Royce's the "waterfall" paper was - and still is - an indictment of the problems introduced when the feedback loops are too long.
Is this the intellectually sound approach to selling agile? I hope not.
This approach is of course nonsense. Agile provides control over scope, actually strict control over scope. Scope is controlled through adherence to the process of the Planning Game or other control mechanisms of how features are added, deleted, changed for the project. This is a method with rules, processes, steps, measurable outcomes, process flows. A method based on an external set of activities for guiding the users through the processes to a desired outcome. Gee that sounds like a process developed from theory and put into practice, just like other processes in the scientific method domain do.
This false comparison of the alternatives to agile with Taylor's 19th century manufacturing method does a disservice to both agile and the traditional methods. It's one of the approaches that has lost it's appeal once it was realized that agile is a highly disciplined, structured, step by step process, complete with process flow diagrams, defined inputs and defined outputs, and tangible measures of progress to PLAN.
Yes, there is a PLAN. Agile is PLAN based. There's even and entire book dedicated to planing in the agile context. Much of the content of that book is similar to the planning processes found in the US DoD for cost estimating and Integrated Master Planning. That fact that Bad Project management is used in some IT domains have nothing to do with the agile and traditional processes sharing many attributes.
All PLANs must be flexible, emerging, fluid, but once the PLAN is set for the iteration, for the rolling wave, for the work packages, for any duration that can be envisioned to have a level of confidence suitable for the recognized risk, it is executed according to PLAN. See the trend here. Agile has PLANs. All projects are plan based otherwise they would fail.
The next nonsensical approach is to suggest that cost and schedule are somehow anti-agile.
Not credible project in which someone else's money is being spent can fail to answer three simple questions:
- When is this project going to be done?
- How much is it going to cost when we're done?
- What am I going to get for my money, at the time you say you're done?
