“Much of present-day software acquisition procedure rests upon the assumption that one can
specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software acquisition problems spring from that fallacy.”
-“No Silver Bullet”, Frederick Brooks, 1986
Perhaps summing up a decade of IID-promoting messages to military standards bodies and other organizations, Brooks made his point very clear in his keynote speech at the 1995 International Conference on Software Engineering: “The waterfall model is wrong!”
In 1986, David Parnas and Paul Clements published “A Rational Design Process: How and Why
to Fake It.” In it, they stated that, although they believe in the ideal of the waterfall model (thorough, correct, and clear specifications before development), it is impractical. They listed many reasons, including (paraphrased)
- A system’s users seldom know exactly what they want and cannot articulate all they know.
- Even if we could state all requirements, there are many details that we can only discover once we are well into implementation.
- Even if we knew all these details, as humans, we can master only so much complexity.
- Even if we could master all this complexity, external forces lead to changes in requirements, some of which may invalidate earlier decisions.
and commented that for all these reasons, “the picture of the software designer deriving his design in a rational, error-free way from a statement of requirements is quite unrealistic.”
[above is an excerpt from the below linked PDF.]
I’ve heard it said that IID is less than “Agile”, that it is instead a compromise between Waterfall and Agile development. I believe the reason for this statement is a flawed belief that a detailed project plan needs to exist which has a series of sequential steps which can be submitted as part of a project estimate. To create timeline/dollar estimates for a system one must start detailing these steps. The process of which artificially creates an early design specification. Worse, a project team that egregiously attempts to use IID methodology but holds onto a “waterfall mentality” requiring a design spec begins to become muddled with cost and time estimates created by developers that don’t yet have clear vision of the whole of the system. They will sit in a room with a list of untold/mis-stated/under expressed assumptions, stories, requirements, and scenarios, and attempt to apply hours and dollar figures to these figmental ideas of work units. Accurately estimating individual tasks cannot occur on a 10,000ft view of an agile project. They can only be estimated within each iteration as they are discussed with stakeholders and fully fleshed out in incremental prototypes.
Questions about how to estimate the total cost of Agile projects are questions about how to do fixed-price, fixed-scope contracts. Fixed-price, fixed-scope contracts are adversarial and often mutually disadvantageous, so I wouldn’t encourage them. This type of contract nearly always cause badly rushed completion and baking in of final (often most important / hard to code ) features. A follow up project is sure to arrive to fix the problems left over by the first project. Fixed-cost, variable-scope projects can go farther down the road towards a satisfactorily delivered project, but users will never feel like they’ve got their money’s worth because they accidentally mix high priority requirements into their “wishlist” priorities and the feature gets cut to decrease scope (see above bullet list). A systematic change must occur in an organization in order to create budgets for an agile IT department. One where the value of the project and the ROI is considered. A more graceful and honest way of thinking is: “If we don’t do this project, what will it cost us? How can we break even?”, but not “How much will it cost if we do this?” or worse “We want it to do this, and are willing pay this much.”
Sources: https://www.it.uu.se/edu/course/homepage/acsd/vt08/SE1.pdf (a great read)
Estimating agile projects: https://scrumology.com/estimate-the-total-cost-of-agile-projects/
