Download
1 / 18
180 likes | 318 Views
Agile Archeology. 1. Introduction. Agile principles did not all come from a single source. Arose from many - each from specific experiences. They were experiences by their own works. Ideas arose from various ‘communities’ and adherents. The four main areas of thought are:
E N D
1. Introduction • Agile principles did not all come from a single source. • Arose from many - each from specific experiences. • They were experiences by their own works. • Ideas arose from various ‘communities’ and adherents. • The four main areas of thought are: • 1. Waterfall process • 2. Iterative and Incremental Development (IID) • 3. Agile Software Development, and • 4. Lean Software Development
Introduction • Many management ideas harken back to William Demming and Jay Forrester. • In fact, most management ideas came from two distinct differentiating generations of software engineering: • 1. SDLC 1.0 – the Waterfall • 2. SDLC 2.0 – the Iterative Method Wars. • This last generation includes Agile.
Introduction • Historically, we can view the evolution as either being derived • from issues faced in projects that led to the careful articulation of methods or • From personal preferences or philosophical / cultural differences. • Did ‘natural selection of approaches’ take place or did we simply lose a valuable set of practices.
2.1 Accidental Waterfall • The Waterfall Method - not intended to be a big deal nor a landmark publication • Originated via Winston Royce’s landmark paper that addressed • simplicity, • iterative development, • risk reduction, and the • accrual of knowledge from working software. • His paper was misinterpreted, so some can assert that Agile is the ‘correct interpretation of his paper.’
Comments • To our author and others, it is amazing how strongly ‘traditionalists’ adhere to this process. • According to leantechnologythinking, these advocates refer to traditionalists as Type II Muda – that is, waste necessary due to the way the work is currently performed. • Upon looking at the Waterfall process, we can see that it is essentially a one-pass, serial, and batched process. • This is a very slow and deliberate process – likely the ‘slowest’ where there is no concurrency. • In truth, its only virtue is its simplicity and lack of coordination / integration activities.
SDLC 1.0 Background • Upon direction of the federal government in attempts to develop better methods and best practices, approaches to evolutionary and iterative practices were of interest. • Please note that DOD was very heavily involved with Waterfall methodology for most of its contracts. • The undersecretary for DOD admonished single-pass and batch processes • See p. 23 for a copy of the letter.
U.S. Government & DOD - heavyweights • Large contractors with big projects and huge organizations developing software were at the basis for Customer Collaboration over Contract Negotiation, a fundamental value of Agile. • Butbecause everything in the government required big contracts, Waterfall model was perpetuated with all of its documentation. • What resulted were huge Ghantt charts used for tracking and predicting development, among other things.
Another Heavyweight • SDLC 2.0 arose from experiences of developers combined with the (mis) application of the waterfall method. • A lot of research took place via Barry Boehm at TRW Systems and research at USC. • Barry’s methodology turned into the Spiral Method, a variation of the waterfall method, which bases continuation of development primarily upon the risks encountered on each ‘cycle.’ • Observe the next figure
