Vitaliy wrote:

>> But most customers don't really care that much about small deliveries.
>> While these are good in many aspects (and one of them is to make sure
>> the customer sees progress and remains confident), the customer's
>> satisfaction comes only with the final delivery, of the full scope,
>> within budget and schedule.
> 
> I strongly disagree. 
> 
> With Agile, the customer makes a list of features, and prioritizes them.
> Then you go down the list. Each iteration resulting in yet another
> feature. It's up to the customer to say, "OK -- that's enough" at any
> point in the project (even early), and he ends up with useful, *working*
> software. Agile helps avoid feature creep.

It seems you're not working much for customers -- are you? Or are you doing
more in-house development? Those are two quite different situations. I bet
you won't easily find a customer who hires a team, pays the team, and just
takes whatever comes, and says "well, if I can't get it all, I'll just be
happy with less"... :)

Most want to have up-front a scope, a schedule and a price (with payment
terms based on delivered scope and schedule). All three may be staged, but
I haven't yet met a customer who was happy to pay and just take what he'll
get.

> With traditional development, the customer may end up with a pile of 
> out-of-date documentation, and software with lots of features that don't 
> work.

Same can happen with Agile -- just the docs will be missing :)

Believe me, you've got to do it right. If Agile helps /you/ to get there,
that's very good. But it might not be that helpful for someone else.


>> I need to make sure up front that I can meet the final, full delivery
>> within budget and schedule. This requires early scope clarification
>> (would you bid on a project without this?) and budget and schedule
>> estimates.
> 
> How often do your estimates turn out to be correct? Agile recognizes
> that estimates are just educated guesses, which are often wrong -- and
> helps you deal with it.

Again... are you bidding for paid projects? There /is/ a difference between
in-house projects and for-hire projects. With in-house projects, you trust
the team -- it's the team you have --, and if things don't go with that
team, they just don't go (or you increase the team). With for-hire
projects, this tends to be different.


> I will take "never-ending small Agile cycles", each of which results in 
> WORKING software, over any of the the waterfall methodologies, anyday. 

See, maybe this is our misunderstanding. I see a world of possibilities
between and around Agile and Waterfall -- it's not an either-or situation.

>> But in most real-world development projects, scope clarification and
>> overall effort and schedule estimates up front make things easier for
>> everybody.
> 
> Why do you think scope clarification and overall effort and schedule
> estimates are not part of Agile?

Because you may need to decide the scope of the delivery after the eighth
iteration cycle before you start with the first. That's not Agile. For
Agile, you need a customer (or boss) who wants to work Agile. That's a lot
easier to find with in-house work than with work for hire.

> What you're saying sounds logical, but my limited experience with 
> distributed development has for the most part been negative. 

I have largely positive experiences. But you need to adapt to the
situation.

> "The most efficient and effective method of conveying information to and
> within a development team is face-to-face conversation."

This is true, if you only take the project. I, like most other people I
know, don't live my projects, I work on them. I have other things to care
for in my life, and the most effective method for running a project may
clash with the most effective method of running my life. So again, it's
about finding the overall maximum -- just with more dimensions :)


>> Rather than "Agile", I prefer "flexible" (note the lower-case "f" and
>> the upper-case "A"; I think it's the case that makes a religion, not a
>> deity -- everything and everybody can become a deity :)
> 
> If a bunch of smart, experienced programmers got together, and came up
> with a simple set of principles that they all agree work, wouldn't you
> want to at least investigate what their methodology is really about? 

What tells you that I didn't? Besides, some of these smart, experienced
programmers already left the Agile train and are now in post-Agile
movements. The whole software development methodology area is full of
groups of smart, experienced programmers who have found something that
works -- to some degree, under specific circumstances, and for certain
purposes. 

For Agile, two of the requirements that kill it for me in most cases are
the physical proximity of the team members and the fact that the customer
has to want it and work in the Agile way. 


> You can label any set of useful principles "religion", and reject it on
> that basis.

Maybe you're getting a bit defensive here. I marked my respective comment
with a smiley, it was in a tongue-in-cheek context from a previous message
-- and I never said I rejected Agile, much less that I do it because I
could label it as "religion". I just think that while it has a few good
thoughts worth thinking about and considering, it's not a silver bullet. 

Gerhard

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