Agile Processes
Agile ProcessesThe AgileAlliance -- http://www.AgileAlliance.org
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: -- http://www.AgileManifesto.org
We are uncovering better ways of developing software by doing it and helping others do it. We value
-- 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...
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"?
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 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? Yes, 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 -- 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 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.
Humor:
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:
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
EditText of this page
(last edited February 16, 2014)
or FindPage with title or text search