Overview of Agile Development

This chapter explains why an Agile team doesn't have explicit phases of development, and how it delivers valuable software by encouraging direct dialog between the customer and developers. These ideas are then presented in terms of a software development life cycle that summarizes the self-governing activities of an Agile team during an Extreme Programming (XP) project. After completing the chapter, you should understand the basic nature of Agile development and therefore have a much better appreciation for the material presented in the rest of this book.

This chapter is from the book

What Is Different about an Agile Project?

The thing that most surprises people when they first encounter an Agile project is the absence of traditional phases such as design-code-test. In a traditional project, these activities are performed separately over weeks or months, but in an Agile project, they are repeated many times each hour as part of test-driven development (TDD), as we will explain in Section 5. Another thing that surprises people is the Agile approach to analysis, which is done throughout the project by developing short stories rather than attempting to capture all requirements upfront and then putting them in large documents. In the next few pages, we'll explain why Agile teams approach software development in this way and perhaps encourage you to adopt these ideas on your own team.

No Separate Development Phases

The trouble with phased development processes such as Waterfall1 is that teams typically spend many months working exclusively on each phase so that their feedback loops are too long. For example, only when the analysis is complete do they proceed to design, and only when the design is done do they move into the coding phase. Although exhaustive checks at the end of each phase attempt to validate the work, it is only during the testing phase that anyone actually knows whether the program meets its objectives. Therefore, the only real feedback about your work comes many months, even years, after it was completed. Waterfall treats software development like a production line, requiring perfection at each stage of the process. If there is any mistake or if the requirement changes during the process, the resulting software will not be correct. This may work when you're maintaining or adapting a mature software product, but not when you're developing new products in the face of changing or unknown requirements. In these sorts of circumstances, you need to increase the amount of feedback by drastically reducing the time between code creation and its validation.

NOTE

The Rational Unified Process (RUP) tries to improve feedback by repeatedly cycling through its core workflows,2 but as these requirements, analysis, design, implementation, and test phases often last months, you still don't get enough feedback for Agile development.

The emphasis on perfecting a design before it is put into code results from people's fear that cost of change will rise steeply as the project progresses. In a traditional Waterfall project, this fear is justified because the long feedback loop between design and test means that any mistakes will result in a significant amount of rework. However, as Scott Ambler3 points out, in an Agile project, the feedback loop between design and test is very short, so mistakes can be corrected much more cheaply.

An Agile team eschews the whole idea of phases so that it can get valuable feedback continuously from the very start of the project by producing the only thing that really counts: working code. Indeed, by the end of the first week, many teams will have demonstrated running software to the customer with some feature that has business value. The price paid for this rapid delivery of working code is that the team doesn't produce thick documents or detailed models of the system. Instead, it just concentrates on writing the tests and code necessary to implement its customer's stories, as summarized on 6-by-4-inch index cards.

NOTE

Agile teams still produce models and documents, but only when they add value. Therefore, later in the book, you will find us describing the sorts of models that may be useful to an Agile team (Section 6) and documents that can contain customer tests (Section 7).

Specifying Requirements with Customer Stories

A customer story (also known as a user story4) defines a feature of the software that has value to the business funding your project. It takes the form of some executable acceptance tests and a written memo that aims to summarize the various discussions about the feature that are held between a developer and someone representing the interests of the business—in other words, the customer. In this way, a story provides a specification for a particular requirement in terms of what Ron Jeffries5 calls card, conversation, and confirmation:

Card—The most important information about what a feature must do is captured as bullet points on an index card; see Figure 3-1. The intention is to remind people about the general issues rather than to write some legally binding contract.

Conversation—The customer and developer must talk to each other if they are to really understand the requirement. The customer usually writes the card during this conversation.

Confirmation—Executable acceptance tests are written as a formal specification of the feature and define it when it has been successfully implemented. These tests contain the actual details of the requirement; see Section 7.

NOTE

Customer stories (or user stories) are not the same as the Use Cases described by Ivar Jacobson.6 Although they both aim to do broadly similar things, Use Cases are more concerned with formally defining things, so they tend to encourage a more prescribed approach.

The customer owns the stories (what the software must do) and the developer owns the tasks necessary to implement them (how the software will work). At the beginning of the project, the customer will come up with a few initial stories, the ones that seem at the time to give the most value. More stories are generated as the project progresses. Sometimes stories will also be discarded as a consequence of changes to the business environment or due to the customer acquiring a better understanding of the requirement. This flexibility is the source of the Agile team's strength; it is able to respond to change. There is no need to identify all the requirements upfront, and the feedback given by working code allows the product to evolve in a way that is driven by fitness for purpose within the confines of a simple architecture.

In the next part of the chapter, you will see how customer stories are used in an XP project. However, they can also be used in a similar way by other types of Agile approaches, such as Scrum.