Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve Mellor

Arie van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunningham Jon Kern Dave Thomas

Martin Fowler Brian Marick

© 2001, the above authorsthis declaration may be freely copied in any form,

but only in its entirety through this notice.

http://agilemanifesto.org/

1

http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

Interview: Jim Johnson, Standish Group Chairman - Aug 2006

InfoQ: Your work on project failure is really a search for “how to succeed”, isn't it? I noticed your list of Project Success Factors includes #5: Agile Development.  As in, Agile Software Development?

JJ: Oh, absolutely!  I'm a big believer in Agile, having introduced the iterative process in the early 90s and followed with the CHAOS reports on quick deliverables. We're a real flag waver for small projects, small teams, Agile process.  Kent Beck has talked at CHAOS University, and I have talked at his seminars. I am a real fan of XP.  My new book “My Life is Failure” looks at Scrum, RUP, XP and talks about those methods.

GD:  Agile has helped by chunking projects into small pieces. Even if you start to get it wrong, you know it early on. Not like the old waterfall projects where you go into a cave and find out the bad news two years later...

JJ: I think that's the secret - incremental. I think that's why we're seeing improvement. A big problem was project bloat, causing projects to go over time, over budget, and creating features and functions not required. Especially in government. Agile really helps this - small increments. You know: they say “I need this”, but by next sprint: “it's not as important as I originally thought it was.”

GD: Yes, prioritizing features helps... always asking: what's the business advantage? Identifying low value items and putting them at the end... and then maybe the project never gets there, so you didn't need them after all.

InfoQ: Agile must bring in new issues: how do you say when “planned” scope is accomplished, for a project using adaptive planning?

JJ: That's a good question. With companies like Webex, Google, Amazon, eBay, it's a challenge - they're doing something called “pipelining” instead of releases. “Whatever is done in 2 weeks, we'll put that up.” They're successful because users only get small, incremental changes. And their implementation is proven - remember, some projects only fail after the coding is finished, at the implementation step.

http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS

[Gordon Divitt, Executive Vice President of Operations for the Acxsys Corporation]

Manifesto for Agile Software DevelopmentWe are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck James Grenning Robert C. MartinMike Beedle Jim Highsmith Steve Mellor

Arie van Bennekum Andrew Hunt Ken SchwaberAlistair Cockburn Ron Jeffries Jeff SutherlandWard Cunningham Jon Kern Dave Thomas

Martin Fowler Brian Marick

© 2001, the above authorsthis declaration may be freely copied in any form,

but only in its entirety through this notice.

http://agilemanifesto.org/

6

Principles behind the Agile Manifesto 1. Our highest priority is to satisfy the customer

through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work togetherdaily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and usersshould be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective,then tunes and adjusts its behavior accordingly.

http://agilemanifesto.org/principles.html

7

Agile methods are a family of development processes…not a single approach to software development. In 2001, 17 prominent figures in the field of agile development (then called “light-weight methodologies”) came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They created the Agile Manifesto, widely regarded as the canonical definition of agile development, and accompanying agile principles.

Some of the principles behind the Agile Manifesto are:• Customer satisfaction by rapid, continuous delivery of useful software • Working software is delivered frequently (weeks rather than months) • Working software is the principal measure of progress • Even late changes in requirements are welcomed • Close, daily, cooperation between business people and developers • Face-to-face conversation is the best form of communication • Projects are built around motivated individuals, who should be trusted • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams • Regular adaptation to changing circumstances

The publishing of the manifesto spawned a movement in the software industry known as agile software development.

In 2005, Alistair Cockburn and Jim Highsmith gathered another group of people — management experts, this time — and wrote an addendum, known as the PM Declaration of Interdependence.

From Wikipedia 5/28/07 8

The Known Agile Processes

Spiral – Barry Boehm (1988)

Evo – (Evolutionary Project Management) – Tom Gilb (1988)

RAD (Rapid Application Development) – James Martin (1991)

DSDM (Dynamic Systems Development Method) – DSDM Consortium (1995)

SCRUM – Ken Schwaber (1996)

RUP (Rational Unified Process) – Booch/Jacobson/Rumbaugh (1998)

XP (Extreme Programming) – Kent Beck (1999)

ASD (Adaptive Software Development) – Jim Highsmith (1999)

FDD (Feature Driven Development) – Jeff DeLuca (1999)

(Agile Manifesto – 2001)

Lean Software Development – Mary and Tom Poppendieck (2003)

Crystal Methodologies – Alistair Cockburn (2004)

AUP (Agile Unified Process) – Scott Ambler (20??)

Pipelining / Perpetual Beta – ??? (???)

Name shown is strongly associated with the concept and writes on its employment extensively; often, not always, is considered the “inventor/founder”

Most popular

“The spiral model was defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. [Wikipedia, May 28, 2007]

“A Spiral Model of Software Development and Enhancement,”Barry W. Boehm, Computer, IEEE, 1988

Waterfall

Vee Model

Vee Base

Vee Left

Vee Right

The Spiral ModelThe steps in the spiral model can be generalized as follows:1.The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system. 2.A preliminary design is created for the new system. 3.A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. 4.A second prototype is evolved by a fourfold procedure: (1) evaluating the first prototype in terms of its strengths, weaknesses, and risks; (2) defining the requirements of the second prototype; (3) planning and designing the second prototype; (4) constructing and testing the second prototype. 5.At the customer's option, the entire project can be aborted if the risk is deemed too great. Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product. 6.The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above. 7.The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired. 8.The final system is constructed, based on the refined prototype. 9.The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Applications: The spiral model is used most often in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program.

Advantages:Estimates (i.e. budget, schedule, etc.) get more realistic as work progresses, because important issues are discovered earlier. It is more able to cope with the (nearly inevitable) changes that software development generally entails. Software engineers (who can get restless with protracted design processes) can get their hands in and start working on a project earlier.

From Wikipedia 5/28/07

RUP GraphicFairly Indicative of Agile Processes

Fine print per Wikipedia: This is a screenshot of copyrighted computer software, and the copyright for its contents is most likely held by the author(s) or the company that created the software. It is believed that the use of a limited number of web-resolution screenshots qualifies as fair use under United States copyright law. The use of this image in educational material describing the Rational Unified Process does not diminish nor infringe upon the potential of IBM to profit from the use of this image or other copyright components of the Rational Unified Process through the sale of software, educational material or consulting services.

From Wikipedia 5/28/07

CMMICapability Maturity Model Integration

Wikipedia 5/28/07:

A growing body of software development organizations implement process methodologies. Many of them are in the defense industry, which in the U.S. requires a rating based on 'process models' to obtain contracts. The international standard for describing the method of selecting, implementing and monitoring the life cycle for software is ISO 12207.

The Capability Maturity Model (CMM) is one of the leading models. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMM is gradually replaced by CMMI.

…The CMMI is the successor of the CMM. The CMM was developed from 1987 until 1997. In 2002 version 1.1 of the CMMI was released: v1.2 followed in August 2006. The goal of the CMMI project is to improve usability of maturity models for software engineering and other disciplines, by integrating many different models into one framework.

CMMI Maturity Levels

“Introduction to the Capability Maturity Model Integration (CMMI),” Eric Buchholtz and Andy Cordes, SPIN Meeting, 2003,

http://www.rtpspin.org/Information/IntroCMMIv5.ppt

CMMI Practices vis-à-vis Agility

“LEVEL 1” Identify scope of work Perform the work

“LEVEL 2” Organizational policy for plan, perform Requirements, objectives and plans Adequate resources Train the people Assign responsibility and authority CM for designated work products Identify and involve stakeholders Monitor and control to plan and take action if needed Objectively monitor adherence to process and QA products/services Review with upper management and resolve issues

KEY GREEN : Supportive, Black: Neutral, RED: Rough Edges

Appurva Jain, Annual Research Review & Executive Workshop Post Workshop Progress Report, March 14, 2002, http://sunset.usc.edu/events/2002/arr/presentations/AGILE%20Methods%20and%20CMMI.ppt

CMMI Practices vis-à-vis Agility

“LEVEL 3” Maintain as a defined process Measure the process performance to support environment

“LEVEL 4” Establish and maintain quantitative objectives for the process Stabilize the performance of one or more sub-processes to determine its

ability to achieve

“LEVEL 5” Ensure continuous improvement to support business goals Identify and correct root causes of defects

KEY GREEN : Supportive, Black: Neutral, RED: Rough Edges

Appurva Jain, Annual Research Review & Executive Workshop Post Workshop Progress Report, March 14, 2002, http://sunset.usc.edu/events/2002/arr/presentations/AGILE%20Methods%20and%20CMMI.ppt

Ken Schwaber's letter to IEEE ComputerI read with dismay “The Agile Methods Fray”, where two of the luminaries of software

processes discuss traditional (defined) and agile approaches. The discussion was irrelevant to those attempting to understand the distinction. A sentence characterized the apparent purpose of the article, “ …found a sensible middle ground and identifying some baby to be saved and some bathwater to be replaced.”

There is no middle ground between traditional and agile processes. The practices of traditional software development processes are inadequate to control projects with complex technology and sophisticated requirements. Agile processes are based on empirical process control, a technique widely adapted by competitive manufacturing and development environments over the last twenty years. I quote from the bible of process control (Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992), “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.”

Empirical process control relies on frequent inspection and continuous adaptation to minimize risk and produce quality product. Agile processes implement empirical process control through iterations, frequent increments of working, tested functionality, emergence of requirements and architecture, self-organization of multiple small teams, and collaboration. These are not spot practices shared by defined and agile processes since the underlying theory is different … using a defined approach for a complex problem is like using algebra to solve complex, non-linear problems.

We indeed are in the middle of a revolution, as we shed traditionally weak inadequate practices and adopt agile processes. The issue isn’t merging the two, but successfully managing the change. Those who wish to tinker with either to reach a middle ground tread a dangerous path toward misleading those who rely on them for informed advice.

Ken Schwaber

http://jeffsutherland.com/scrum/2002/06/agile-processes-ken-schwabers-letter.html - JUNE 16, 2002

Are SE tools in conflict with

reality?

"..the MCC Elevator Study is significant because, for the first time, we have a model of the process that people actually follow when they tackle hard problems. And it is not the orderly, linear process we have assumed is proper.

"The non-linear pattern of activity that expert designers follow gives us fresh insight... It reveals that in normal problem-solving behavior, we may seem to wander about, making only halting progress towards the solution.

"This non-linear process is not a defect, not a sign of stupidity or lack of training, but rather the mark of a natural learning process. It suggests that humans are oriented more toward learning (a process that leaves us changed) than toward problem solving (a process focused on changing our surroundings).

Wicked Problems: Naming the Pain in Organizations, E. Jeffrey Conklin & William Weil,http://www.touchstone.com/tr/wp/wicked.html

Problem

Solution

Analyze data

Formulate solution

Implement solution

Waterfall MethodActual DesignerGather data

ControversyAgile development has been widely documented as working well for small (<10 developers) co-located teams. Agile development is expected to be particularly suitable for teams facing unpredictable or rapidly changing requirements.

Agile development's applicability to the following scenarios is open to question:

• Large scale development efforts (>20 developers), though scaling strategies and evidence to the contrary have been described.

• Distributed development efforts (non-co-located teams). Strategies have been described in Bridging the Distance and Using an Agile Software Process with Offshore Development

• Mission- and life-critical efforts

• Command-and-control company cultures

It is worth noting that several large scale project successes have been documented by organizations such as BT which have had several hundred developers situated in the UK, Ireland and India, working collaboratively on projects and using Agile methodologies.

While questions undoubtedly still arise about the suitability of some Agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success.

From Wikipedia 5/28/07

Agile Software Development – The Process

“A Practical Guide to Seven Agile Methodologies,” Rod Coffin and Derek Lane

You know that Agile methodology is the right thing to do, but trying to parse all the different methodologies is a major research endeavor. How to know which one is right for your organization? In this two-part article, you'll learn all the ins and outs of the seven most popular methodologies so you can pick the one that's best for you.

In part 1, we cover XP, Scrum, Lean, and FDD.

http://www.devx.com/architect/Article/32761/

In part 2, we cover AUP, Crystal, and DSDM. 

http://www.devx.com/architect/Article/32836