A class of students is always an interesting mix of people. People who, mostly, did not knew each other before class. And most of the time, something strikes people the most when talking about the background of Scrum and this thing called “agile”. The ones paying the most attention and who are already working in the field for some time start exclaiming: “What I hear now, is nothing new!”
An important core part of Agile is iterative, incremental development (IID). The root of IID can be traced back to the Plan-Do-Study-Act cycle introduced in the 1930s and the W. Edwards Deming Plan-Do-Check-Act cycle of the 1940s. In the 1950s, the development of the X-15 hypersonic jet at NASA was also done using IID.
Gerald M. Weinberg, a computer scientist working at IBM Service Bureau Corporation in 1957 wrote:
We were doing incremental development (…) developing a large simulation for Motorola, where the technique used was, as far as I can tell, indistinguishable from eXtreme Programming. (…) All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.
Waterfall, the method that Weinberg is referring to, was actually introduced in the late 1960s, more than 10 years after his time at IBM. In this quote he is referring to adopting a strict one-pass development process to complex product development, known now as ‘waterfalling’.
In his 1970 article ‘Managing the Development of Large Software Systems’, Winston Royce introduced an iterative incremental approach to the waterfall process. He saw an inherent risk in a single-pass sequential approach. Ironically the single-pass sequential application of waterfall development is now incorrectly attributed to Royce by many. Royce:
I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.
In the mid 1970’s work was ongoing at IBM FSD on LAMPS. LAMPS (Light Airborne Multipurpose System) was a project for the US Navy in which helicopters, which were already used at US Navy ships, were fitted with a weapons platform to be used in anti-submarine warfare. According to H. Mills “Top-Down Programming in Large Systems”, at IBM this was a four year long, 200 person-year effort, delivered in 45 time-boxed iterations of one month. Every one of those iterations was delivered on-time and under-budget. Mills:
Software development should be done incrementally, in stages with continuous user participation and re-planning and with design-to-cost programming within each stage.
The 1980s saw the introduction of Adaptive Programming. In 1985 the Spiral Model was introduced and in 1986 F. Brook wrote in “No Silver Bullet”:
Much of present-day [1986!] software acquisition procedures 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.
From the mid-1980s IID in software development gained momentum. In 1987 Royce introduced the precursor for IBMs Rapid Unified Process (RUP). J. Sutherland and K. Schwaber were at Easel Corp in 1986 and were working in what would became known as Scrum.
1994 saw the introduction of Rapid Application Development (RAD) and Dynamic Systems Development Method (DSDM). In 1995 RUP and Scrum were introduced, followed in 1996 by eXtreme Programming (XP) and in 1997 by Feature Driven Development (FDD).
From K. Schwaber “SCRUM Development Process”, 1995:
The stated, accepted philosophy for systems development is that the
development process is a well understood approach that can be planned, estimated, and successfully completed. This has proven incorrect in practice. SCRUM assumes that the systems development process is an unpredictable, complicated process that can only be roughly described as an overall progression. SCRUM defines the systems development process as a loose set of activities that combines known, workable tools and techniques with the best that a development team can devise to build systems. Since these activities are loose, controls to manage the process and inherent risk are used. SCRUM is an enhancement of the commonly used iterative/incremental object-oriented development cycle.
The Crystal family of development methods was also introduced. And all this came together in 2001 where the agile values and principles finally emerged.
So here we are. Yes, agile is quite old.