The authors of Episodes, Scrum, XP, DSDM, Adaptive Software Development and Crystal, plus some other similarly experienced people, such as WardCunningham
, 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:
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 AgileSoftwareDevelopment
is often used to describe the way proponents of the AgileManifesto
among them? I seem to recall SteveMellor
is a signatory...
As mentioned elsewhere, if you're looking for a good overview of agile processes, check out JimHighsmith
's book AgileSoftwareDevelopmentEcosystems
So, what is it?
What makes AgileProcesses
different from those that are not Agile?
If I was trying to convince someone to employ an AgileProcess
versus a non AgileProcess
how would I do it? What benefits are there, and how do they directly flow from that which defines an AgileProcess?
(i.e. could I theoretically get all the stated benefits of an AgileProcess
with a process which isn't "agile"?)
Can I get something besides the BuzzWords
of "High-Manoeverability","Individual Oriented","Working Software","Collaboration" and "Flexibility"?
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. -- AlistairCockburn
Do we sense false dichotomies in here?
I like to think of AgileProcesses
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 AgileProcesses
are about expecting the unexpected
I've been working with a small, collaborative team under most of the ideas of the http://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 DullProcesses?
or something like that. -- Ricardo Urbina
Is this related to AgileModeling?
is the title of a book by ScottAmbler
, and if you visit his site http://www.agilemodeling.com
you will see that it supports the AgileAlliance
On the AgileAlliance
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 AgileArchitecture
to emerge? -- BillBarnett
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 TestDrivenDevelopment
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 - http://developers.slashdot.org/comments.pl?sid=119135&cid=10059154
I have an idea for an agile documenting strategy, WriteTheUserManualFirst
. Unfortunately, this is a poor idea, because it directly implies BigDesignUpFront
. Read the page and you'll see that it does not.
Is there an agile process that covers allows management to complete the ManagementCycle
to provide some BusinessSolution?
taking into account EnterpriseIssues?
Some discussions at http://groups.yahoo.com/group/scrumdevelopment/
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 ManagementCycle
requirements. -- ChristianEdwardGruber
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.
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