Agile Software Development

A movement for change within the domain of Software Development methodologies, which came to be formally named at the creation of the AgileManifesto. Sometimes abbreviated ASD. The AgileAlliance was formed in 2001 to promote the concepts of agile software development, and help organizations adopt them. However, the concepts themselves were being refined and shaped throughout the 1990s.

Also, a seminal book within the Agile Software Development movement: Agile Software Development by AlistairCockburn is discussed at TheBookAgileSoftwareDevelopment.

See AgileCaseStudy for a real-world application of AgileDevelopment.

A Definition

AgileSoftwareDevelopment is a movement within the Software Development community, away from traditional process-heavy methodologies and toward "relatively light, effective, human-powered software-development techniques." ++

Some of the central ideas it encompasses are:

a focus on skills, communication, and community to allow projects to be more effective and agile than when the focus is on processes; ++
a clarification and revision of the roles of customers, managers and developers for more satisfying and productive relationships;
an assertion that different projects need different processes or methodologies. ++

++ These portions are adapted from the preface of TheBookAgileSoftwareDevelopment indicated above.

I find that pictures help. This one was derived from Jim Highsmith's Agile Project Management book.

NoCopyrightsOnWiki?: FrankKlucznik

Another Definition:

"Heightened attention to:

individuals and interactions,
working software,
customer collaboration and
responding to change."

(source? cited below)

Discussion of the definition of AgileSoftwareDevelopment

Pinning down one definition of this term has proven difficult (discussion below). And see AgileProcess and TheRealDefinitionOfAgile for yet more discussion.

No more discussions and debates! The more bosses out there who simply get the message "Agile doesn't suck", the better!!! -- ScapeGoat

I found a useful Roadmap to AgileSoftwareDevelopment at: http://www.agilealliance.com/programs/roadmaps/Roadmap/general/general_index.htm. -- DeborahHartmann

Other things you may like to look at are contributions to this Wiki made by some of the leaders in the Agile movement. (Many of whom are listed at the Agile Manifesto site and have WikiHomePages here - so as usual you can just click on the title of their home page to see all their signed contributions to this Wiki). I've also included my favourite links in on my web site, which is reachable from my own WikiHomePage. -- JohnRusk

Oh, and here of course: AgileProcesses. - John

: Actually, John, I have a little trouble with the title (only the title) of the AgileProcesses page. (Am I the only one?) I suspect that AgileSoftwareDevelopment is a newer catchphrase for this same group of methods, and I find it more suitable: I'll explain. For those of us very familiar with Agile, the AgileProcesses title is fairly transparent, because we have made the paradigm shift from Process-Driven to Agile methodologies. But I feel that it may convey, to the newcomer, the false impression that Agile is still about "adopting the right process", whereas I understand it to be about applying values and principles to grow our own customized processes for our own unique contexts. The AgileMethods page is better, although it seems quite programming-related whereas Agile acknowledged to cover project management as well... -- DeborahHartmann

Good point, about conveying the false impression that it's about "adopting the right process". Perhaps, once the content of the discussion here, on this page, stabilizes, a page could be created to summarize the result - with links to it from both AgileProcesses and this page... -- JohnRusk

I guess eventually we'll condense all this back down to just the facts. But it's an interesting conversation for the moment... What do you think of the definition I've put together, up top? -- DeborahHartmann

Yes, I like your definition, particularly your point about the clarification and revision of roles. Your third point, "an assertion that different projects need different processes or methodologies" is an interesting one. Some agile methodologies come across as "one size fits all" - at least that's the impression that I get from XP. Particularly in advice along the lines of "you must adopt all our practices, and turn all the knobs up to 10". Perhaps that's an overly-simplistic summary, but there does seem to be at least a hint of that attitude. On the other hand, AlistairCockburn strongly advocates that processes should be adaptable and self-tuning. -- JohnRusk

There have been two workshops at OOPSLA aimed at deriving, "just what exactly is agile software development?" Both, and particularly the first, failed spectacularly at finding "the" common thread or definition. I expect that to continue. The background to the term is that a bunch of people, some of whom knew each other and some of whom didn't and some of whom didn't show up, got together in a room for two days to ask the question, "Is there anything we 'light process' advocates have in common, and oh by the way I can't stand the phrase 'light weight process' because it's not what I'm about". The answer to the first part is Yes - the 4 values, and the the response to the second was a word search for a term that somehow instinctively seemed to evoke in all the people close to whatever they internally thought they were about - or they at least weren't embarrassed to be characterized by (more the latter than the former).

Once the word was chosen, then instead of that being the endpoint from an internal sensation, it became for everyone else the starting point into a set of internal sensations. Those in general aren't far off what the 17 people felt, but there doesn't seem to be a common thread much beyond the 4 values. We 17 could scarcely agree on the 12 principles, and have diverged every time we try to wordsmith those into better shape.

The best we've got so far is "heightened attention to individuals and interactions, working software, customer collaboration and responding to change." MartinFowler in his wonderful NewMethodology paper characterizes it as lightweight, adapting and people centric, I believe. -- AlistairCockburn

Ignoring intuition is illogical. -- CmdrSpock

For your delectation: Organizational Patterns of Agile Software Development http://slashdot.org/article.pl?sid=04/10/13/1817241 --hfx_ben

DaveOlson's book applying ChaosTheory and CatastropheTheory to SoftwareDevelopment: ExploitingChaos - ISBN 0442011121 - written in 1993, captured many of these concepts. In it, he describes what he calls a "fractal development process", designed to achieve:

Periodic and probably frequent emission of a product
Quick ramp-up for the first product
Intimate customer involvement
Supportive environment for nonlinear efforts (e.g. "splinter" department, SkunkWorks)
Exploitation of existing strengths of standard SoftwareDevelopment
Improved innovation and response to market needs

and also gives lots of examples of what not to do! -- PaulMorrison

I'm a newbie to this Agile stuff, and not to toot my own horn (much), but this sounds a bit like my Linguistic Method. Wikipedia link: http://en.wikipedia.org/wiki/Linguistic_Method I tried to publish it with limited marketing savvy in my out-of-print book Dunlavey, "Building Better Applications: a Theory of Efficient Software Development" International Thomson Publishing ISBN 0-442-01740-5 , 1994, which I can send zipped copies of to whoever wants one.

Basically, my initial reaction to Agile is what seems to be a relative paucity of theory. I've always felt that if something is really true, not just a hot idea, then there is a scientific reason behind it. I always thought things like Agile were true, so I wanted to find the reasons behind them. This shows up (at least for the people I know who can do stuff like this) as not only the desire to write software in an Agile way, but a set of technical skills by which they do it, such skills as:

can easily create domain-specific languages
know truly effective performance tuning methods (not just profiling)
know how to use partial evaluation when the problem calls for it
can invent new control or data structures when the problem calls for it

I've never seen a project done in a truly Agile way (doesn't mean they don't exist) that didn't make use of some such techniques which maybe some programmers have yet to learn.

Just my $0.02 -- MikeDunlavey

What I'm constantly pissed off by advocates of agile methods: the lack of any business considerations. I know agile methods supporters say we should collaborate with the customer instead of making a contract, but business as a SW dev services provider doesn't work that way. You need a contract, or else in some legislations the customer isn't even allowed to pay you.

Now, it is obvious to anybody who wrote software for a living that you cannot say in advance how much effort will go into a particular project. However, customers usually are reluctant to close a contract on a time and material basis for software development, but want a fixed price statement. They are willing to accept a change management process, which can change scope and consequently cost for the project, but in order to do things this way, you need to have a very well established scope definition at any time in the project. My problem is: how do you set up an agile process under these circumstances? The problem I see is the following: user stories are not detailed, fixed, uniquely implementable coding instructions, and with the right customer you could end up investing a lot more time in a simple user story than initially estimated, without getting paid. But agile methods rightout shun documentation, especially documentation maintenance. There is also no well defined scope definition from the beginning, and a scope definition only for the next iteration won't cut it.

This is the reason why I don't like agile methods. On the other hand, although we use - don't laugh - a strongly changed version of the waterfall model (provisions for change and iterations, and strongly simplified), we use quite a lot of the techniques recommended/emphasized by agile methods. I can see value in these techniques, I just can't see value in a process which, to me, seems completely different to what any other cast of engineers does in the conception phase. After all, the process of getting from vague customer requirements to a finished application is more or less the same process of getting from vague customer requirements to the blueprints of a house or of a custom-built machine.

IMO, after a few decades in which people confounded writing source code with producing products, instead of producing the blueprints for the products, agile methods are a reaction exaggerated in the opposite direction. Also IMO this is a consequence of SW development being a relatively young industry, and one which is significantly different from whatever was done before (except, possibly, ellaborating law systems or physics theories, which is something done by very few people, and therefore didn't require a dedicated methodology). I think in time agile methods as they are seen now will be forgotten, and a more heavyweight, systematic process will be established, which will use techniques employed by agile methods where appropriate, standardize code artifacts to a much larger extent than we can imagine now, and include new techniques, supported by tools, to ensure proper traceability and controllability of software development projects. Only, we just aren't there yet.

A_flj_

CategoryOpenAgile