Unified Lightweight Methodology

Jan. 5, 2001, AdamLi asked the question of "Do you see a UnifiedLightweightMethodology in the future" in the XP egroup. You can follow that thread at http://groups.yahoo.com/group/extremeprogramming/message/18764.

Feb. 2, 2001, JimHighsmith, author of AdaptiveSoftwareDevelopment, and AlistairCockburn, author of the forthcoming SoftwareDevelopmentAsaCooperativeGame decided unify their work on light and self-adaptive methodologies. They set up the http://www.CrystalMethodologies.org website (no longer working -- try http://alistair.cockburn.us/crystal/ instead).

The week of Feb. 15, 2001, the big names of the LightweightMethodologies met in Snowbird to discuss these AgileProcesses (look in that page). You can find more information from Ron J.'s post in the XP Yahoogroup http://groups.yahoo.com/group/extremeprogramming/message/21457, the manifesto for AgileProcesses at http://alistair.cockburn.us/crystal/wiki/AgileSoftwareDevelopmentManifesto

Why don't they just use XP??

Because XP is only one of the AgileProcesses, not universally applicable, accepted or appreciated. There are other AgileProcesses, DSDM, Scrum, Crystal, Adaptive, and FDD being some. There are others, still, which haven't turned up yet, and more that have never received names.

If they're all different, then what's the point of unifying them?

Actually, this page is a misnomer. They're not being unified. The question was, "what do they have in common and where do they differ, and if they have enough in common, what would it mean for the authors to collaborate in some way?" That's a far cry from unifying. --AlistairCockburn

So if there isn't any kind of unification imperative, how does this initiative apply to us mere mortals -- the ones who use these lightweight methodologies or a deviation of one ore more of them -- who are trying to build better software? This splintering could overcomplicate it for someone who doesn't have enough time to read through all this content.

If you believe that unification will create less content to read, then have a look at the size of the RationalUnifiedProcess. --anon

Where there is no imperative (thank goodness), people always get around to asking, How are so and so similar or different / the same? We got together to compare notes. The value in putting our ideas together is to give greater awareness of the idea that AgileProcesses actually work and that thoughtful people are using them. There is, by the way, no way out of the conundrum you are setting up - - if there's only one, it's too narrow or too big, and if there are several, it's all too confusing. The answer is that you have to think about what's best suited for your project.... a group not prepared to do that, is scarcely prepared to produce valuable software for their organization. --Alistair

Your efforts would be valuable as long as the common denominator provides a meaningful contrast with methodologies such as RUP. But if it got overly complicated to understand this contrast, or sense how each of the AgileProcesses differ, then I'm not sure it would help much. Your final sentence is what it's all about . . . at the end of the day we're here to deliver, and we strive to reuse knowledge and tools that help us do that. It's the decisions made that seem to cause success or failure to emerge (i.e., a group prepared to think about what's best but not having the skills or experience to make the right decisions can cause failure too).

Is the best approach to take the existing methodologies and try to unify them, or to fundamentally understand agility and create a set of unified principles instead of a catch-all process? Isn't there a danger of ending up with a methodology that is 99% appeasement of vested interests and 1% insight? Lest agile methods become as irrelevant as UML...

CategoryMethodology