I was lucky enough to be asked to speak at Agile India 2006 on the deployment production line, so I popped along today to check out the opening talks. Craig Larman, Cheif Scientist at Valtech, gave an entertaining, well-researched talk on agile vs waterfall, covering the history of both and the evidence in favour of agile. For me, the most compelling argument he presented was the long list of historical figures who promoted agile practice.

Although it’s news to me, it’s apparently well known that Dr Winston Royce’s original paper setting out the ‘waterfall’ model (although he doesn’t use the name) is actually describing it in order to demonstrate how poor it is as a project management technique. Larman claims that even von Neumann, working on the early stages of the Mercury Project, espoused an iterative approach to development.

It is often claimed that agile is not suited to defence projects, where techniques such as critical path development are preferred. In fact, Larman has dug out Sapolsky’s book on the development of the Polaris system, where Sapolsky says that critical path analysis and PERT charts were used as a smokescreen to placate senior management while engineers got on with their iterative development process. It seems that even the Space Shuttle software development was planned as 17 6-week iterations, with “continual integration” central to the process (ACM 1984 vol. 27 issue 9).

Larman has even tracked down the source of most government directives requiring subcontractors to follow waterfall project management processes: Department of Defence directive 2167. It seems that this directive infected European government via NATO, but has subsequently been discarded by the US DoD after it lead to the failure of over 50% of their projects.

According to Larman it comes down to this: waterfall style development methods are taken from manufacturing, and are entirely acceptable when planning predictable development processes such as building cars or prefabricated houses. However when performing new product development (the example Larman gave was the pharmaceutical industry), agile processes should be preferred, and indeed have been in use for just as long. Hence inasmuch as building software is like new product development (and for the vast majority of large projects it is), agile should be preferred.

  • http://www.trigent.com Nattu

    I attended a seminar on the same topic in Bangalore, 04-Aug-2006 and the above points were cogently explained by Craig Larman. The fact that he is a practitioner lends lot of credibility to his recommendations.

    During the seminar, Craig strongly debunked PMI approach of software project management. But after listening to the entire seminar, one cannot but observe the similarity in PMI and agile approaches:

    # The topic of ‘cone of uncertainty’ is covered extensively in Rita mulchahy’s PMP prep.
    # PMI speaks about building teams and allowing teams to form , storm, norm and then perform, something that Craig mentioned about ‘self organizing teams’
    # PMI practitioners speak eloquently about using visual techniques in requirements, design and planning discussions and explain that visual techniques elicit participation and help in attitude management. Craig strongly advocated visual techniques as a tool to elicit conversations
    # Both PMI practitioners strongly rejected MS project as a planning tool!

    So, the point i’m making is that for an un-initiated participant, after attending this seminar, they may summarily dismiss PMI while there are certain reasons why a PMI training may still be relevant

  • Test

    Hi all!

    G’night

  • Pingback: … So We Built One :: Waterfall as Smokescreen and the Surprisingly Long History of XP