I just got back from the eXtreme Tuesday Club, XTC ( www.xpdeveloper.com ) where I had an interesting chat with Austin Iduoze, Romilly Cocking and Adewale Oshineye about what is Agile.
We evolved a single sentence to describe Agile. "Agile is about delivering Business Value (with Software) through learning via continuous feedback.
Tom Gilb and Lindsey Brodie joined us and I told him the definition. Tom disagreed. He said Agile is about keeping it simple (small) and direct. It is about stripping away the pointless documentation that clogs up projects. It is the opposite of non-agile processes such as CMMI.
Overall a really nice evening with some great conversations.
XTC reminds me of the description of the early days of the Royal Society in Neal Stephenson's Quicksilver. A group of people keen to learn and discuss the latest thing in software development that meets in the back room of an old London pub.
Posted by chrismatts at March 2, 2004 11:07 PMJust been discussing this with Adewale over lunch.
Clearly a lot of people have a different view on what ‘agile’ is, so I thought I'd throw in my view:
Inspired by Martin Fowler's 'New Methodology' article, I would argue that agile is just the principle that no single methodology will ever always deliver great software, so the best approach is to hire smart people, judge them by the results (rather adherence to a particular method) and let them choose their own mechanism to deliver the results.
Therefore, I think that to insist that someone uses 'learning' and 'continuous feedback' is inherently unagile, because you are prescribing an approach. The fact that I cannot think of a single project where I would not want to use them is not really the point.
Sorry for being anal.
Posted by: Tim Velvick at March 3, 2004 1:12 PMI was at last Tuesday's meeting that held in the back room of an old London pub and this is a brief comment on the discussion at the pub, and an issue raised in an article (or comment) on this web site namely that a rename of eXtreme Programming would accelerate its uptake and contrubute to its "crossing the chasm". (see comment titled "What's in a name").
Of course it goes without saying that stripping away pointless documentation that clog up projects is desirable but the positioning of eXtreme Programming as a cure to this ailment begs the question of whether other approaches to developing and delivering software are always guilty of this without justification. Pointless documentation in this case may be regarded as an impediment to good progress of development effort. Perhaps the dynamics of developing good quality software (with a net gain for all parties concerened) is not as simplistic as merely promoting a prospensity for less documentation. On the other hand, it may be worth considering whether a particular 'ideology' or approach is suitable for all types of projects.
Regarding the aforementioned comment (on this web site), embracing change may be slow for many reasons, not least because there are uncertainties involved sometimes. The adoption of the Object Orientated Programming (OOP)paradigm as opposed to using procedural language tends to support the saying that "the taste of the pudding is in the eating" - i.e. the main driving force in the adoption of a solution is in its effectiveness and benefits. This in turn suggests that the major determinant of eXtreme Programming "crossing the chasm" has to be well proven benefits that outweigh other considerations rather than a name change.