Read an Excerpt

CHAPTER 1

Introduction to Agile Methods

Agile methods are an important new paradigm for maximizing the business value of creating new software products. They are part of the fields of innovation, new product development, systems engineering, and software engineering. Agile methods are a contemporary form of concurrent engineering, cross-functional teams, and overlapping development. They are useful for creating software products in both the commercial marketplace as well as the government sector, particularly for rapidly developing innovative product ideas.

Consisting of right-sized, just-enough, and just-in-time processes and documentation for developing software, agile methods have just enough discipline to capture customer needs, plan projects, and develop high-quality software products. Focused on creating software products that satisfy customer needs without unnecessary bureaucracy, they are the perfect tool for maximizing business value by rapidly responding to market needs with innovative solutions. Agile methods are a win-win solution for most stakeholders.

Agile methods bring high-quality, innovative software to market in the fastest and most cost-effective manner, solving issues such as how to: (1) innovate, (2) manage product development, and (3) ensure quality. Rather than a 19thcentury, industrial-era manufacturing process, they are a customer-focused way to develop products and an efficient alternative to traditional document-driven process improvement and systems engineering standards.

1.1 What Are Agile Methods?

Agile methods are contemporary approaches for creating new software based on customer collaboration, teamwork, iterative development, and response to change. Combining communication and interpersonal trust with a flexible management and development framework, they contain just enough process to capture customer needs in the form of user stories and to rapidly create working software. However, the keys to agile methods are rich, high-context communications with customers along with cohesive teamwork.

There are numerous forms of agile methods, such as Extreme Programming, Scrum, Dynamic Systems Development, Feature Driven Development, Crystal Methods, and many more. Open source software is also considered an agile method. Four values are common to all agile methods: (1) customer collaboration, (2) teamwork, (3) iterative development, and (4) adaptability. Each of the major types of agile methods embraces these values in a unique way. However, it is the best elements of each that represent the body of knowledge for agile methods.

For instance, Extreme Programming utilizes the practices of release planning, user stories, pair programming, and much more. Scrum brings us backlogs, sprints, daily standups, and retrospectives. And open source software uses right-sized, just-enough, just-in-time documentation and collaboration. Although proponents of each feel their method is sufficient for software development, it is the basic premise of this book that the best practices among all of the methods represent the essence of agile methods. Furthermore, this book posits the notion that the values of agile methods outweigh the rules and practices of any one agile method. And we are not alone in that viewpoint.

1.2 Why Agile Methods Emerged

Agile methods emerged in the 1990s for a specific reason: to successfully create new software that satisfies customer needs. Agile methods are really the convergence of multiple phenomena: inexpensive computers, powerful and easy-to-use information technologies, and the desire to succeed. Agile methods are also the result of a convergence of technologies: large process improvement models, large software engineering standards, and large methodologies. Although the creators of agile methods tried to use these large models, standards, and methodologies to create new software products, these projects failed time and time again.

This was an auspicious beginning for what we now know as agile methods. When agile methods were born, large software engineering models, standards, and processes were getting even larger. Rapid Application Development, the Software Capability Maturity Model, and IEEE standards were hitting their stride with more to come. Traditional methods were based on documented project plans, large-requirements documents, and multi-year project life cycles. However, traditional approaches to software development based on manufacturing processes led to minimal project success. Not even the good ones based on earned-value management and quality-control processes, resulting in zero defects seemed to help.

From 1991 to 1998, at least five major types of agile methods emerged to help projects succeed in lieu of the old ones: Crystal Methods, Scrum, Dynamic Systems Development, Feature Driven Development, and Extreme Programming, in that order. It was a quiet counter-revolution to mega-standards such as the Software Capability Maturity Model and IEEE standards, against which agile methods were pitted.

1.3 How Agile Methods Emerged

At first, the creators of agile methods attempted to use some of the early traditional methods to manage their software projects. However, these were ineffective, projects were failing, and the creators of agile methods weren't obtaining new business, which often led to lawsuits. Thus, the creators of agile methods started with a clean slate, threw away the old methods, and did what was necessary to succeed. One of the first agile methods was Scrum, which was based on product backlogs, sprints, daily standups, and product owners, and which adapted ideas from new product development approaches from the 1980s, such as iterative development and teamwork.

With an odd mix of customer interaction, iterative development, teamwork, and not much more, Scrum projects began to succeed. Scrum opposed the major values of traditional methods: contracts, processes and tools, documentation, and project plans. Project success was a major result of agile methods such as Scrum, because it was created to save failing projects. Success within traditional methods used manufacturing metrics, such as effort, cost, productivity, schedule, quality, and reliability. However, the creators of Scrum valued project success much more, because it translated directly into customer satisfaction.

The creators of Scrum felt that detailed project plans, requirement documents, and methods didn't contribute to successful projects. Instead, they advocated requirements, such as informal features, product backlogs, and sprints, as well as project plans, such as release and sprint plans. They believed in processes, as long as they didn't stand in the way of delivering valuable software in 30-day sprints. However, Scrum's creators felt that documentation led to poor communication and that informal daily standup meetings and sprint reviews were a far better alternative.

1.4 First Agile Methods

Crystal Methods came to light as an offshoot of object-oriented methodologies from the 1980s merged with other agile practices. Created in 1994, Dynamic Systems Development, an offshoot of Rapid Application Development, was classified as an agile method, as was Feature Driven Development, an object-oriented method created in 1997 to save failed projects. Extreme Programming, originating around 1998, was clearly the capstone of the era of the 1990s when agile methods emerged. Extreme Programming was a confluence of Scrum, Participatory Design, Rapid Application Development, and many others.

Extreme Programming was created to save a failed payroll system at the Chrysler Corporation. There is some evidence to show that Scrum may have been used as a basis for the creation of Extreme Programming, which was an amalgamation of practices, including release planning, user stories, test-driven development, refactoring, pair programming, and onsite customer. In 1999, Extreme Programming was introduced to the masses, and the rest, as they say, is history. Although Extreme Programming seemed to enter the scene with a whimper rather than a bang, it soon became the favorite among methodologists.

In 2001, 17 methodologists gathered to discuss agile methods and their newfound success, and to decide the future of agile methods. They defined the Agile Manifesto consisting of four major values: (1) customer collaboration over contract negotiation, (2) individuals and interactions over processes and tools, (3) working software over comprehensive documentation, and (4) responding to change over following a plan. Although these values seem superficial, they represented a fundamental revolution in software engineering. They are not just opinions but engineering principles.

1.5 Agile Methods Explosion

Four key events precipitated the explosion of agile methods: (1) the creation of Scrum; (2) the creation of Extreme Programming; (3) the emergence of Crystal Methods, Dynamic Systems Development, and Feature Driven Development; and (4) the creation of the Agile Manifesto. However, the marquee event had to be the publication of Extreme Programming in 1999. Extreme Programming did three things: it (1) promised project success, (2) introduced 13 simple practices, and (3) was a big departure from traditional process-and document-driven methods.

The international community was yearning for something new, and Extreme Programming was the fulfillment of those basic desires. Since the 1950s, the software community had been applying traditional methods, and it simply couldn't stomach another one. In particular, the Europeans took to Extreme Programming because it was well-suited to their culture of Participatory Design. They started pair programming, enlisting onsite customers, and knocked down the cubicle walls to open up the workspaces.

By 2002, approximately 67% of leading-edge software developers who elected to use methodologies preferred Extreme Programming. European, Canadian, and Middle Eastern universities began researching, teaching, and writing about agile methods. Conferences dedicated to agile methods sprung up overnight, attracting thousands. Hundreds of papers and 75 books emerged on various topics associated with agile methods. Over the years, Scrum has become the most popular agile method, and agile methods are being applied in ways not previously imagined.

1.6 Summary

Agile methods are fundamentally new approaches created in the 1990s for developing software and to save failing software projects. They are based on customer collaboration, teamwork, iterative development, and adaptability to change-values not unique to agile methods but common in the fields of innovation and new product development. In fact, Scrum was based directly on new product development paradigms and served as a basis for other agile methods. Agile methods amount to right-sized, just-enough, and just-in-time processes and documentation for creating new software products.

Agile methods stand in direct opposition to the values of traditional methods, such as contract negotiation, processes and tools, comprehensive documentation, and following a plan. More importantly, agile methods were created to ensure project success rather than simply adherence to industrial age manufacturing measures such as earned value, programming productivity, and defect density. Communication is valued highly within agile methods, whereas documentation is seen as the key to quality and maintainability in traditional methods.

Within the value of individuals and interactions are principles such as teamwork, interpersonal trust, and communication quality. Attributes such as talent, skill, experience, and programming ability are also buried deep within this agile method value. When you add this up, agile methods amount to extremely talented individuals; just-enough, just-in-time communications, processes, and documentation; and frequent software deliveries. This creates a double-loop feedback system, resulting in project success and maximum business value for all stakeholders. Agile methods fulfill what traditional methods simply cannot do.

Values of Agile Methods

Agile methods are somewhat unique in that they are based on a set of values and principles. In one sense, agile methods are an outgrowth of the plethora of rapid development methodologies emerging in the 1980s. Some of these software methodologies, notably Rapid Application Development and its successor, Dynamic Systems Development, came replete with their own manifestos, values, and principles. In effect, agile methods are a values-based, or a principles-based, development approach for creating new software products.

Five major types of agile methods emerged in the 1990s: (1) Crystal Methods, (2) Scrum, (3) Dynamic Systems Development, (4) Feature Driven Development, and (5) Extreme Programming. While some were direct spinoffs of rapid and object-oriented methods in the 1980s, others were simply spinoffs of one another. At first glance, the five major types have little in common. In 2001, the creators of agile methods came together to study the commonalities of their approaches and formed the Agile Manifesto.

The Agile Manifesto outlined four major values of agile methods, along with 12 broad principles. What the creators learned in those fateful days in Snowbird, Utah, is that their methods had a lot in common. They also learned something else: that they shared a common disdain for the values of traditional methods (e.g., contracts, processes, tools, documentation, and project plans). Traditional methods became known as plan-driven methods. Agile methods had a better answer which led to project success.

2.1 Major Values of Agile Methods

The four major values of agile methods are: (1) customer collaboration over contract negotiation, (2) individuals and interactions over processes and tools, (3) working software over comprehensive documentation, and (4) responding to change over following a plan. These basic values are repeated again and again in this book. This is no accident. The theme of this book is how to achieve business value (e.g., return on investment) using agile methods. Be prepared to recite the values of agile methods.

First, we're going to tell you what we will discuss in this book. Then, we're going to tell it to you. Finally, we're going to tell you what we told you. That is, there is business value to be obtained from using agile methods. And why not? Isn't a new software product supposed to provide customers with an exciting new capability? That is, without the software product, there is little or no capability. And, with a new software product, there is more capability. Why else would customers pay for such a product? Besides, aren't agile methods supposed to ensure project success every time? If so, then using agile methods creates business value.

Who is the recipient of this so-called business value? Is it the developer? Is it the customer? Well, the answer is both. That is, both the developer (supplier) and customer (buyer) gain business value from the use of agile methods. So, what are these so-called values of agile methods? They are customer collaboration, individuals and interactions, working software, and responding to change. OK, let's slow down a bit. The values of agile methods are communicating with customers, teamwork, iterative development, and flexibility with just-enough process and product.

2.2 Customer Collaboration

The first major value of agile methods is customer collaboration over contract negotiation. What does this mean? In a sense, it means asking the customers what they want. It may also mean listening to and interacting with customers to ascertain their needs. How does this add business value? It's quite simple really. Business value is created by asking customers what they want and then giving it to them. Customers get what they need — that is, some sort of business advantage — and developers get paid and secure even more business.

Traditional methods recognize the need to capture customer needs but in an entirely different manner. Generally, the customer or developer must document, in advance, all of the needs. Although that doesn't seem so bad, this assumes that all of the needs can be documented. Next, this assumes the developer can satisfy all of the needs at once. Finally, this assumes the customer will pay for whatever the developer conjures up in the end. There are a lot of assumptions in traditional methods and little human-to-human communication.

How is customer collaboration performed in agile methods? With right-sized, just-enough, and just-in-time interaction. With Scrum, customer needs are captured in the form of features within a product backlog. After some features have been implemented, customer collaboration takes place after 30 days in what is known as a sprint review. Within Extreme Programming, customer needs are captured in the form of user stories. The customer is actually a full-time member of the project and communicates with the developers throughout the project.

---

Excerpted from "The Business Value of Agile Software Methods"
by .
Copyright © 2009 J. Ross Publishing.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

---