The authors of Episodes, Scrum, XP, DSDM, Adaptive Software Development and Crystal, plus some other similarly experienced people, such as Ward Cunningham, Martin Fowler, Robert Martin, Steve Mellor, David Thomas, Andrew Hunt, etc., gathered at Snowbird to discuss what they had in common. The group decided on the word "agile" as capturing the rapid-reaction, high-manoeverability of these methodologies, and that that word could be applied to each of the methodologies discussed. They agree and wrote as follows (some editing may occur before final signing).
Manifesto for Agile Software Development: -- www.AgileManifesto.org 
We are uncovering better ways of developing software by doing it and helping others do it. We value
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
-- to be signed by the various crafters of the statement.
The term Agile Software Development is often used to describe the way proponents of the Agile Manifesto work.
Agile Processes include...
Extreme Open Business (a generalized Agile Process, applied to Open Business, inheriting much of the principles and experiences of Extreme Programming)
XBreed (www.realsearchgroup.org )
FDD (Coad's Feature Driven Development)
Open Source As Agile Process: and maybe Open Source style development [quoting Martin Fowler in The New Methodology]
Shai Ben Yehuda's Tgp Methodology focus on integration of business professional to the development process
Is Shlaer Mellor Method among them? I seem to recall Steve Mellor is a signatory...
As mentioned elsewhere, if you're looking for a good overview of agile processes, check out Jim Highsmith's book Agile Software Development Ecosystems.
So, what is it?
What makes Agile Processes different from those that are not Agile? If I was trying to convince someone to employ an Agile Process versus a non Agile Process how would I do it? What benefits are there, and how do they directly flow from that which defines an Agile Process? (i.e. could I theoretically get all the stated benefits of an Agile Process with a process which isn't "agile"?)
Can I get something besides the Buzz Words of "High-Manoeverability","Individual Oriented","Working Software","Collaboration" and "Flexibility"?
You might find Agile Software Development helpful.
I think maybe one way to get started with this is to ask yourself (or your team, or your manager) the 4 questions....
"Do we really put our money on individuals and their interactions, or do we put our stress on processes or tools? Do we really put our money and milestones around seeing working software, or around the documentation? Do we really collaborate with our customers? Do we stress responding to change, or do we rate people on how well they are following the plan?"
When you pose these questions, the answer should be rather clear, and they will indicate a lot. -- Alistair Cockburn
Do we sense false dichotomies in here?
I like to think of Agile Processes as a highly disciplined approach to coping with constant unexpected change. I've worked on a number of complex, mission-critical telecoms systems and often fallen into the trap of trying to eliminate change (e.g. waterfall practices) or anticipate change (e.g. abstraction and configurability). Neither has ever been a satisfactory approach in the long run. I've found time and again that the most important characteristic of a system is actually the abililty of its development team to evolve the design rapidly, safely, and sustainably. This may be stating the obvious, but I believe Agile Processes are about expecting the unexpected.
-- Mike Howells
I've been working with a small, collaborative team under most of the ideas of the www.AgileManifesto.org . I didn't realize this until this week, when we were assigned a new manager who enjoys exactly the opposite. Right now, work doesn't get done -- and is justified (to our manager's eyes) because there are no contracts nor papers which state what has to be done -- but we still have over 800 users stalled.
We do outbound telesales, so we get contracts and need to get things going in a matter of days, which means we have to deliver working software right now, even if we're unsure about the exact details and have to rework them.
Not every business gets the same benefit from agile processes. Most of our software is for internal use only, and several parts of it are ad hoc and can't be reutilised, so these agile processes really do make a difference. If we ever break something, we get to know in a matter of minutes, so, in a bit of a mischievous though, we have 400 testers online. Which means our software always fulfills both their needs and wishes.
I'd even dare to claim that the opposite are Dull Processes or something like that. -- Ricardo Urbina
Is this related to Agile Modeling? Yes, Agile Modeling is the title of a book by Scott Ambler, and if you visit his site www.agilemodeling.com you will see that it supports the Agile Alliance.
On the Agile Alliance page it says that the most effective architectures (among other things) emerge out of self-organizing teams. Is there anything that could be done upfront to help create a fertile environment for this kind of Agile Architecture to emerge? -- Bill Barnett
---- Has anyone noticed that the terms XP and Agile being used by Microsoft?
I've talked to a couple of people recently who seem to define "agile" as "I write tests". Given the emphasis on Test Driven Development that is promoted by many agilists, I suppose this isn't a totally unexpected misunderstanding.
"I liken the difference between classic development methodology and agile development as the difference between a boxer and a streetfighter. The boxer is constrained by the rules, whereas a streetfighter will hit you with a brick if that is the most effective way to bring you down. Results are the touchstones of successful software development projects."
- Lodragandraoidh on Slashdot - developers.slashdot.org
I have an idea for an agile documenting strategy, Write The User Manual First -- Skip Sailors. Unfortunately, this is a poor idea, because it directly implies Big Design Up Front. Read the page and you'll see that it does not.
Do Agile Processes subsume Literate Programming?
Is there an agile process that covers allows management to complete the Management Cycle?
The Management Cycle manages Management Issues employing Contemporary Development Roles to provide some Business Solution taking into account Enterprise Issues.
Some discussions at groups.yahoo.com have looked at a variety of translations from Agile metrics and documentation into other forms of external presentation. There may be some meat here for looking at fulfilling Management Cycle requirements. -- Christian Edward Gruber
This role has a senior position where the individual acts as a mentor for larger teams. The junior position involves the individual who refactors software and performs code analysis, code reviews and basic refactoring. As a team they audit and improve the development code with the senior mentor coordinating the improvement of developers.
Humor:
www.dilbert.com
Commentary:
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
Methodologies therefore differ by the size, criticality, scope, optimized quality, and the grounding beliefs of the authors. Comparison of methodologies should focus on these different dimensions, and their relationship to the needs of the project or organization.
-- Alistair Cockburn
See Agile Software Development, Alternative Processes, Unified Lightweight Methodology, Methodological Pluralism, Agile Methods
See original on c2.com