The Agile software development methodologies were the first attempts to improve the software development situation, with Lean coming onto the software scene much later.
Most of the Agile methodologies, like Extreme Programming (XP) and Scrum, actually predate the Agile Manifesto (which we will discuss shortly). In fact, using the term “Agile” to refer to these methods of software development was coined at the famous Snowbird meeting that created the Agile Manifesto.
In the 1990s there was a growing dissatisfaction with the prevalent heavy software development methodologies and processes. Using these processes did not solve any of the endemic problems of software development: high project failure rate, low software quality, and generally unhappy customers.
This spawned a number of alternative methodologies, including XP, Scrum, Dynamic Systems Development Method (DSDM), Crystal, and Feature Driven Development (FDD), that were collectively known as Lightweight methods. The term “Lightweight” was meant to distinguish them from the predominant heavyweight methods of the time. Their creators were not happy with the term “Lightweight” because it seemed to imply that these methods were less comprehensive or less important.
It became increasingly apparent that these Lightweight methods had a lot in common with each other. So, in February of 2001, a group of 17 of the leading independent thinkers about software development gathered at the Snowbird ski resort in Utah to try to find common ground. The roster of this two-day gathering included many of the most prominent personalities in software development at the time: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, and Dave Thomas.
Three significant things came out of the now-famous Snowbird gathering: the decision to use the term “Agile,” the Agile Manifesto, and the Agile Alliance. The Agile Alliance (http://www.agilealliance.org/) is a nonprofit organization that exists to further the development and dissemination of information regarding Agile processes.
As stated earlier, no one was happy with the term “Lightweight.” Alistair Cockburn articulated this nicely when he said, “I don’t mind the methodology being called light in weight, but I’m not sure I want to be referred to as a ‘Lightweight’ attending a ‘Lightweight methodologists’ meeting. It sounds like a bunch of skinny, feebleminded people trying to remember what day it is.” And thus, we now have “Agile.”
The Agile Manifesto (formally called the Manifesto for Agile Software Development) is a model of simplicity. Written by Kent Beck et al., it eloquently states the four core values that form the philosophical bedrock of all Agile methodologies:
We 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.
The wording of the Agile Manifesto was carefully crafted to communicate the intended message. By saying, “We are uncovering better ways of developing software,” they showed that they didn’t have all the answers and were still on a learning journey of discovery. Just as important was the next part, “by doing it and helping others do it,” which meant that they were actively engaged in using these “better ways” (no ivory-tower theoretical advice here) and were sharing what they learned with others (not telling people what to do).
Each of the four value statements in the Agile Manifesto lists two things and states that both items are important, but the first item is higher priority. Martin Fowler and Jim Highsmith described this very succinctly in their August 2001 article in Dr. Dobb’s Journal titled “The Agile Manifesto”:
The Alliance recognizes the importance of process and tools, with the additional recognition that the interaction of skilled individuals is of even greater importance. Similarly, comprehensive documentation is not necessarily bad, but the primary focus must remain on the final product—delivering working software. Therefore, every project team needs to determine for itself what documentation is absolutely essential.
Contract negotiation, whether through an internal project charter or external legal contract, isn’t a bad practice, just an insufficient one. Contracts and project charters may provide some boundary conditions within which the parties can work, but only through ongoing collaboration can a development team hope to understand and deliver what the client wants.
Plans are important, but they shouldn’t be rigid, unchanging plans. The ability to respond to changes is critical to the success of most software development projects.
In addition to enumerating the four Agile values, the authors of the Agile Manifesto further refined what they meant in those value statements by listing a number of principles that they follow as a direct result of those values:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity—the art of maximizing the amount of work not done—is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
There are a fair number of formal software development methodologies that fall within the Agile camp. While they vary in their specific activities and artifacts, they all use short time-boxed iterations that deliver working software at the end of each iteration (the length of the iterations varies between methodologies). Figure 1-3 shows the typical Agile process.
All Agile methodologies share a number of core practices (either formally or informally). These core practices also support Lean software development and are the subject of the second half of this book.
Some of the more commonly used Agile methodologies include:
Scrum
XP
Crystal
FDD
Unified Process (UP)
DSDM
These methods all began at different times in the 1990s as a response to the failure of the Waterfall method. There has been a great deal of cross-fertilization of ideas and techniques between these methods.
Scrum has successfully taken the Agile approach and stripped it down to the essentials. The result is one of the simplest and easiest-to-implement Agile methodologies that still provides the benefits of Agile software development.
XP has a rich set of interlocking practices that can feel overwhelming to those uninitiated in the Agile way, but XP gets credit for popularizing most of the core practices that have been adopted by the other methodologies. XP has probably done more to raise the awareness of Agile software development than any other methodology.
Crystal is actually a family of methodologies created by Alistair Cockburn. The actual processes and practices vary depending on a project’s size and criticality or complexity.
FDD is unique among the Agile methodologies in that its perspective centers on creating domain models for the system being developed, which then organizes development around features that implement the model.
UP is generally considered to be one of the more “heavyweight” of the Agile processes, although it was intended to be tailored and not implemented in a heavy manner. Regardless, this has led to a number of variants, including the Rational Unified Process (RUP), the Agile Unified Process (AUP), and the Enterprise Unified Process (EUP).
DSDM is more formal than most of the other Agile methods, fully specifying many different roles, processes, and artifacts. A notable feature is the prioritizing of requirements according to the MoSCoW rules:
Get The Art of Lean Software Development now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
