It is true that, for most of the 1980's, standards such as Mil Spec 2167A which was a US Defense standard that demanded the waterfall approach for all Defense contracts (this Mil Spec was also followed by governments in the UK and Australia) tended to dominate the world of software engineering. Going back further into history, system development models such as SDM/70 and Method1 that emerged in the 1970's also were focussed on the waterfall model which had been borrowed from construction.
However, by the early 1980's a number of alternative development models started to emerge that confronted the inherent inability of the waterfall model to respond to change as well as the inordinate length of the development process. In 1982, the Australian Department of Defence abandoned a project called SSR which had been in the analysis phase for over 10 years as they blindly followed Mil Specs! As a side note, once SSR was cancelled a consulting company called Mincom was engaged and had a prototype of SSR within 6 months based on a package they had developed for another industry. Early Agile.
Certainly by 1985/6 the impact of deregulation and global capitalism driven by Ronald Reagan and Margaret Thatcher had begun to be felt world-wide and the rate of change experienced by projects and organizations had begun to increase. This fuelled the initial debate about waterfall. Agilists, please note, this was 1985!
By the mid-1980's, techniques such as Time-boxing where the project was broken into releases of 6 months or so, Joint Application Development (JAD), Rapid Application Development (RAD), Joint Requirements Planning (JRP) and Production Prototyping begun to emerge and gain some acceptance. All these models tried to increase the level of involvement of stakeholders in the system development process while, at the same time, speeding up the development process.
However, a number of factors limited their impact. First, while 4th GL languages were available, the most common development technology was still main frame centric and not suited for rapid iteration, Secondly, the power base of IT was still dominant and many traditionalists did not believe that business should be involved in projects, Third, the rate of change was relatively low and the business imperative for fast delivery was not as intense as it is today. Finally, the cultural impact of these "new" techniques was completely ignored .. see next blog.
The key point here is that the emergence of Agile models is NOT a revolution but rather the result of an evolution that started some 30 years ago.
We believe that Agile was inevitable and like any evolutionary process cannot be stopped and will continue to evolve.
We are close but not there yet.
