Agile Development

[magazine]
Volume-Issue: 
Summary:

Technical Editor Brian Marick explains the values behind the Manifesto for Agile Software Development. Above all, Agile practitioners value: individuals and interactions; working software; customer collaboration; and responding to change.

In February, I participated in a convocation of people who've created or worked on "Agile Methods." You may not be familiar with that relatively new umbrella term, but individual Agile Methods have been gaining attention lately—the most well-known of these being eXtreme Programming (XP). Other examples include Adaptive Software Development, Crystal, Dynamic Systems Development Method, Feature-Driven Development, Scrum, and XBreed. Our group's goal was to find what these different methods had in common. The resulting Manifesto for Agile Software Development offers the statement of values shown in Figure 1.

For me, two key imperatives underlie these values.

Working Code
In his fine book Hackers, author Steven Levy describes the Hands-On Imperative. It says to get your hands on the computer and make it do something. Programmers are often in the grip of the Hands-On Imperative; that's why they don't like to write documentation. Agile Methods accept the Hands-On Imperative, but extend it to the users.

Why? Author Reinhard Keil-Slawik puts it this way: "Thinking does not take place inside our heads...Most of our mental activities need external resources." Different resources lead to different ways of thinking. Someone who adds with an abacus thinks differently about addition than does someone who uses the Indian decimal numbering system and a pencil and paper. And a user asked to evaluate an abstraction like a requirements document or a design model thinks profoundly differently than one presented with working software

As German researchers Reinhard Budde and Heinz Züllighoven have written, "When we formalize, we explain how an object functions; when we work purposively with a thing, we understand what it means." So when we sit a user down in front of the screen for the first time, her reaction—"Wow, this is not what I expected"—doesn’t represent any sort of failure. It's not that we didn't do a good job "capturing" requirements, or that the reviews weren't planned carefully enough, or that the user wasn’t properly trained in our modeling notation, or anything like that. It's just that we humans simply cannot imagine the real experience by studying an abstraction.

Because Agile projects understand that, they deliver working software (or perhaps executable prototypes) as quickly as possible and as frequently as practical. Development is organized into a rapid series of functionally complete releases, each one made available for the user to try. Since each such release is really the first chance the user has had to think about the new features, rework is just part of the job—not a crisis.

Conversing People
With less documentation, how do Agile projects keep everyone in synch? With an imperative toward human contact: face-to-face conversation and collaboration. XP has people program in pairs and tries hard to have a customer representative working every day in the same bullpen as the developers. Another Agile method, Scrum, relies on carefully crafted daily standup meetings that create and preserve group understanding. Crystal, perhaps the least dogmatic process conceivable, nevertheless insists on frequent retrospectives. These techniques foster the communication that documents cannot replace.

All Agile methods want customers to be part of the team. With a suitable customer representative at hand, you don't need a detailed requirements document. When you have a question, you turn around and ask. Worried that you won't know to ask the right question? Implement something and show it to the customer for a quick reaction—you'll quickly learn if you're going off track.

In an Agile project, conversation is carefully designed to avoid a lot of idle chatter. Talk will be pragmatic, concentrating on some object of work. But there'll be a background of tacit understanding of the

About the author