Agile Processes

The AgileAlliance --

The authors of Episodes, Scrum, XP, DSDM, Adaptive Software Development and Crystal, plus some other similarly experienced people, such as WardCunningham, MartinFowler, RobertMartin, SteveMellor, DavidThomas, AndrewHunt, 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

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 work.

AgileProcesses include...

Is ShlaerMellorMethod 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"?

-- DevilsAdvocate

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. -- MikeHowells

I've been working with a small, collaborative team under most of the ideas of the . 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? Yes, AgileModeling is the title of a book by ScottAmbler, and if you visit his site 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 -

I have an idea for an agile documenting strategy, WriteTheUserManualFirst -- SkipSailors. Unfortunately, this is a poor idea, because it directly implies BigDesignUpFront. Read the page and you'll see that it does not.

Do AgileProcesses subsume LiterateProgramming?

Is there an agile process that covers allows management to complete the ManagementCycle?

The ManagementCycle manages ManagementIssues employing ContemporaryDevelopmentRoles to provide some BusinessSolution? taking into account EnterpriseIssues?.

Some discussions at 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:

-- MikeDunlavey

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 AgileSoftwareDevelopment, AlternativeProcesses, UnifiedLightweightMethodology, MethodologicalPluralism, AgileMethods

CategoryAgileMethodology CategoryOpenAgile

EditText of this page (last edited February 16, 2014) or FindPage with title or text search