Monday, May 08, 2006

Nutshell definitions of Agile development

Over on the Extreme Programming Mailing list, someone asked "Could any one tell me what's exactly Agile Methodology(method) is?", a couple really good responses followed that I rather liked (italics are mine in the excerpts below).

Phlip wrote:
Agile development means using feedback to prevent waste and optimize development.

Software development follows an inner cycle of writing code for new features, and an outer cycle of delivering versions to users.
  • The inner cycle risks waste when we debug too much, or write too many lines. Larger teams also cause waste when one person must wait for another to upgrade their modules.
  • The outer cycle risks waste simply because when customers wait a long time for new features, the odds increase that they will request changes to existing code.
Feedback" means you set up a cycle so your project can tell you about its current status, early and often.
  • The most important feedback for the inner cycle is automated tests. They prevent wasting time debugging, and they help you remove lines of code that are not needed. And they make your code safe for others to change, so they don't need to wait for you.
  • The most important feedback for the outer cycle is frequent releases to end users. If you give them the high value features first, then the odds they will request rework are low. (High value features tend to have obvious specifications.) Then, the odds they will request new features are high, so you repeat. Each new release will reinforce and fine-tune the high value features.
Put together, these processes allow teams to move rapidly to new territory, and to not trip or make mistakes getting there. The dictionary's word for such fleet and sure-footed behavior is "agile".

John Roth wrote:
Agile is a style of project management which lets the project respond quickly to changing requirements. It also usually incorporates frequent releases, or at least the possibility of frequent releases without undue extra project management overhead.

Ease of handling changing requirements naturally leads to leaving the definition of detail to the last responsible moment, rather than having to have all details completely specified up front.

Most named agile methodologies don't specify much outside of project management. Scrum, for example, specifies a lot of project management, a small amount of team practice (put the developers in a room and do daily standups) and gives essentially no guidance about how to actually construct the software.

XP is the only one I know of that specifies all three (project management, team practice and software construction practice) in detail.

C. Keith Ray wrote:
Agile methods react well to changing requirements, permit delivery of working, tested, software at frequent intervals, and generally require less "overhead" than older document-driven formal methods. To enable this reduction of overhead, Agile methods rely on "social" tools and practices (such as shared-workspace, "information radiators", and retrospectives) as well as technical tools and practices like automated builds and automated tests.

Someone referred to James Bach's definition of an agile methodology:
agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.

Steven Gordon wrote:
What makes this question so vexing to so many is that being agile is contextual rather than definitive.

Being lean and principled is not necessarily sufficient to be agile - one must garner feedback from the context (from customers and management as well as ourselves) and adapt appropriately to that feedback to remain agile. Doing the exact same things could be agile in one context and not particularly agile in another.


4 comments:

Anonymous said...

I also liked Tim Haughton's take:
--------------
When clients ask me what 'Agile' development is, I tell them it is any
development method that revolves around 4 key pillars. In today's
lingo, we might refer to them as "The Axes of Agility", namely;

- Short iterations, circa 2 weeks.
- Automated accetance tests.
- A 'war room' style programming environment.
- Test Driven Development.

If you have these things in place, other agile practices will almost
inevitably follow.
---------------

Scott W, Ambler said...

My definition is:
Agile is an iterative and incremental (evolutionary) approach to software development
which is performed in a highly collaborative manner with "just enough" ceremony
that produces high quality software which meets the changing needs of its stakeholders.

Anonymous said...

I like your defintion Scott. My only complaint would be that it's quite long, for a "soundbite".

I had a go at making a shorter soundbite, here http://www.agilekiwi.com/definition.htm

To me, there are two important aspects to any definiton:

1. It must encompass those of use who, as Alistair Cockburn puts it, "Came to agility through the door marked 'efficiency' [of process] not the door marked 'changing requirements'". (Both are about minimising total cost over the whole lifecycle - both development and maintenance - so there's plenty of common ground).

2. Be about _agile_ in the broadest, sense, not specifically XP. For that reason, I specifically disagree with the kind of definition given by Tim Haughton, above. (Click my signature for the reasons why).

By the way, we had an interesting discision of this topic on the Cystal Clear newsgroup some months ago.

Marty said...

Rediculous. Reminds me of how I wrote web applications (and responded to new requirements) in 1997.

Someone would make a valid comment on the feedback form which cc'd to webmaster@....com, and the next day, I'd make the change in dev, unit test, and update prod.

Granted, things aren't the same now that I work at a global financial institution, but still seems petty considering how we used to react back in the boom years...

Sending hundreds of people to training, to learn a "methodology" for rapid-response releases...

Yeah yeah, i know... Millions of dollars are at stake now, not just a potential IPO price. Sigh... still seems like two steps backwards... considering all we spent training folks on Six Sigma and DMAIC.

I long for the days when I could make a needed UI improvement directly to prod, based on a single email to feedback@...com, without asking for anyones permission! :P