Gerhard Fiedler wrote:
> It seems you're not working much for customers -- are you?

The project I've been working on for the past few months is for an external 
customer. In the end, any project is for a customer -- even if it's you.

> Or are you doing
> more in-house development?

Most of the time, yes.

> 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"... :)

I think you and Nate are missing the point.

By definition, projects involve uncertainties. If you remove all uncertainty 
from a project, it stops being a project and turns into a manufacturing 
activity.

With Agile, you still have a schedule and a plan. The difference is, Agile 
recognizes the fact that schedules are guesstimates, and that plans tend to 
change.

> 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.

You misunderstood what I said.

With Agile, you still define those things with the customer. You know that 
you're working with limited resources, so you rank the features (with 
customer's help) in order of priority, considering cost/benefit of each 
feature, etc. You end up with a Users Guide, a requirement spec, whatever 
else you end up with that you use for quoting.

With traditional "waterfall" development, you just follow these steps, in 
the order shown, until the project is done:

1. Requirements
2. Design
3. Implementation
4. Verification
5. Maintenance

You have a schedule which reflects this. So you have a 10-month project, and 
you divide the time up evenly, after 4 months you have nothing but paper.

With Agile, you have short development cycles (usually 2 weeks). You pick a 
set of tasks (or just a single task) that you can complete in one iteration. 
Each iteration includes test & debug phase, so at the end of the two weeks 
you end up with fully functional, tested and debugged software.

Now, what I said was, if you're doing Agile development the customer can 
easily terminate the project pretty much at any point. They can do that for 
a number of reasons, for example:

- They ran out of money, or
- They decided that the software has enough features, and that the remaining 
(low-priority) features are not worth spending their money on, or
- They decided to devote the resources to another project

Whatever the reason, you give the customer SOFTWARE THAT WORKS.

Depending on where you are in the waterfall model, you give the customer 
either a pile of PAPER, or a heap of non-functional, bug-ridden, untested 
code.

--> By the way, another advantage of Agile is that you can ship the product 
early (whenever you decide that the feature set is sufficient). In the 
meantime, you continue development and implement those fun and exotic 
features you wanted to implement from the start.

Also, with Agile, you know from the start that the plan will change. So when 
it happens -- customer changes their mind about which features they want 
most, you encoutner some external limitation, etc -- with Agile you can turn 
on a dime, figuratively speaking. With traditional development, your 
schedule and your plan come crashing down at the first sign of change.

>> 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 :)

Not true (see above).

> 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.

What does "right" mean to you?

> 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 don't understand why you bring bidding into this. You make your educated 
guesses, bid on the project, and THEN development begins.

>> 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.

I'm not married to Agile. I don't even have much experience with Agile. It 
just makes sense to me. For those of you who are familiar with Eli 
Goldratt's ideas, I believe that Agile is an extension of Critical Chain, as 
applied to programming. Improve the process repeatedly.

I look at past projects and see that projects that were done in the "Agile 
spirit", succeeded. Others, where we spent months documenting and speccing 
out every little detail, failed. I read about the same thing happening to 
other companies, all the time.

What I'm trying to do now, is consciously practice the common-sense Agile 
principles.

>> 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.

You can do the quoting the "traditional" way, then switch to Agile for the 
actual development. Your up-front estimates will always be wrong, anyway. If 
that's not true for you, you're not in the project development business.

> 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.

Sure, having a customer who wants to work Agile helps, but it's not a 
prerequisite. I would have to agree with you on the boss part, as long as by 
"boss" you mean person with decision-making power, closest to the 
programmers.

>> 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.

What kind of projects were these (complexity, duration)? How many people 
were involved?

I'm genuinely interested in hearing about your positive experiences (maybe 
you can start a separate thread?). My limited experiences with outsourcing 
involved relatively small projects, requiring no more than one man-month of 
effort.

>> "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 :)

What if you already have people in the same building, what's the problem 
then? Most companies work this way.

By the way, there are examples of executing successful distributed projects. 
But you still have face-to-face conversation and theory building --  
documentation is not enough, you need to fly one of your team members to 
Russia to explain the theory to the Russian programmers. Always-on video 
links can also be helpful.

The problem with documentation is, some things are difficult to explain in 
writing, and some are impossible.

>> 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?

The comments you make about Agile, of course. I think you're confusing Agile 
with a twisted version of XP.

> Besides, some of these smart, experienced
> programmers already left the Agile train and are now in post-Agile
> movements.

Who are those programmers? Which 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.

I'm yet to hear you offer an alternative methodology. What works for you, 
personally? How do you approach a project?

What do you think works for other programmers?

> For Agile, two of the requirements that kill it for me in most cases are
> the physical proximity of the team members

That makes it more difficult, but certainly not impossible.

> .. and the fact that the customer
> has to want it and work in the Agile way.

Helpful, but not required.

>> 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".

It was Nate who said: "Welcome to the church. Agile is just another 
methodology/religion."  The sentence above was my reply to his statement 
(which you echoed). I'm not paranoid. :)

> I just think that while it has a few good
> thoughts worth thinking about and considering, it's not a silver bullet.

Brooks already proved that silver bullet doesn't exist, so no point arguing 
it.

However, some methodologies are better than others.

Vitaliy 

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