I've been doing "agile" (so called: iterative, milestone based, spiral, 
scrum, XP, lean, etc.) development in some form or another since the 
late 80's - rapid build, test, acceptance cycles - all important well 
before the agile manifesto was drafted. Kelly Johnson's 14 Skunkworks 
rules from the early 1950's embody most of the elements of agile 
development - Strong architecture ("hardware requirements") going in, 
small, flat teams, low decision overhead, flexibility for change, focus 
on inspection ("acceptance"), burn reports, trust, tech and business 
joined at the hip, no kibitzers ("chickens"), etc. But I digress. See: 
http://www.lockheedmartin.com/aeronautics/skunkworks/14rules.html

One point that's often missed is that agile (et al) is as much (more?) 
about managing the customer as it is about managing the development 
team. Hence the focus on "product owner" and VOTC (voice of the 
customer) roles, product backlog, stories, and all that; specifically to 
avoid the 18 month "oh no" moment. Deliver early and often. The rest 
supports this.

Alden


Vitaliy wrote:
> Steve Willoughby wrote:
>   
>> I've seen some real horror shows of teams claiming to have done "Agile" 
>> projects, and like any other technique, Agile isn't the panacea for 
>> everything, but I would also point out that what you've described is in 
>> violation of the Agile values and would be seen as poor and 
>> unprofessional (if not outright dishonest) in the Agile camp as well as 
>> anywhere else.
>>
>> The biggest proponents for Agile methodologies I've spoken with all say 
>> you do as much architectural planning and careful work to make sure you 
>> don't end up with a bandaid-smattered mess when you're done with Agile 
>> as with other methods, but the difference is that you do it in a 
>> different order and in a different way, so you're better able to respond 
>> to changes in the work conditions (who hasn't taken on a large project 
>> only to find after 12-18 months of development that business has changed 
>> in that time, or that the customer *now* realizes that, once they see 
>> the product, they misunderstood or misstated what they were asking for?)
>>
>> The successful teams I've seen have taken more of a pragmatic approach 
>> to the whole thing instead of a philosophical or religious one, though, 
>> it's not about "doing Agile" or "doing whatever" as much as it is "doing 
>> software development" and if Agile has some things to offer, so much the 
>> better, whether you do them strictly by the book or adapt some things 
>> into your work model to suit your needs.
>>     
>
> Well put.
>
>
>   

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist