Agile Methods

Agile methods are, in some measure, a reaction to the excesses of deliberate methods that place more emphasis on ceremony (checking those steps off and reviewing those documents) than on the content of software delivery. These methods are called "agile" because "extreme" can be seen as, er, extreme, while "lightweight" is too, well, lightweight. The best known of these methods is XP.^[1] Others include Cockburn's Crystal Family, SCRUM, and DSDM.

^[1] See Extreme Programming Explained by Kent Beck (2000).

Some proponents of agile development met in 2001 to form the Agile Alliance.^[2] The primary output of this meeting was the Agile Manifesto, which begins, "We are uncovering better ways of developing software by doing it and helping others do it." It then asserts four "value statements" of the form "We value: <left> over <right>." The key point here is not that <right> is bad, but that <left> deserves more emphasis.

^[2] For information on the Agile Alliance, see their website, www.aanpo.org.

Let's look at the four value statements in turn.

Individuals and interactions over processes and tools. Processes and tools are not silver bullets not even model-driven development and MDA. You can build a system without processes and tools, but you can't build a system without people. And the better the people, the better the result by far. None of this is to say that process and tools are unimportant; the point is that people and their interactions need to be valued more.

The focus on interactions also emphasizes that using documents, even models, as a one-way interface between people reduces the bandwidth of the communication and increases the likelihood of error.

Working software over comprehensive documentation. If you intend to drive to the local hospital, you wouldn't write a document that says exactly how to do it first. Certainly, you need a map that lays out the most effective way to do the task, and you should listen to the radio for up-to-the-minute information on whether a particular route is blocked, but documenting the intended route first is unlikely to stop the bleeding.

Taken literally, preferring working software is unassailable. How could anyone prefer to have a document instead? But there's a subtext here: Is documentation unimportant? Unnecessary? A hindrance? This subtext has led to the deprecation of models and modeling in general, though how one interprets that depends on what one means exactly by a model, a topic we take up in the next section.

Customer collaboration over contract negotiation. We've all heard of projects where the spec has been "frozen," often with unfortunate results. To increase customer involvement, agile processes encourage customer participation even during development.

To eliminate the verification gap and enable immediate delivery of fragments of the system, what we need is a highly abstract modeling language that focuses on a single subject matter the subject matter of interest to the customer and yet is specific and concrete enough to be executed. In other words, we need an executable model. This executable model abstracts from concrete programming languages, such as Java et al., and in the parlance of MDA, it is platform independent.

Responding to change over following a plan. A plan tells us how to get from where we are to where we're going, but it doesn't tell us if where we're going is the right place to be. If the plan is correct today, it doesn't mean it's going to be right tomorrow. Technology and markets change far too quickly for that. Achieving the plan milestones doesn't necessarily relate to customer success.

This value statement distinguishes predictive and adaptive approaches. In the construction industry, execution of the plan the construction phase takes relatively longer than the planning and design phases. We use the plan to predict when the project will be complete. In software, the design and coding phases take much longer than execution. Even if we define "execution" to be the act of writing code, it is still a small percentage of the total time in the project. Consequently, the plan doesn't predict much of value. Instead, we must recognize that we must adapt as circumstances change.

As usual, this is not to denigrate having a plan. Plans for software projects should include all phases, not just planning for coding. If interaction with the customer is included during the early phase(s), then the plan should also include time for these interactions. In fact, if you value responding to change, you had better darn well plan for it. The key here is to exploit change to ensure that the product is as close as possible to what the customers need. Reality provides real feedback.