what is a practical Agile Process

Originally by Martin Fowler:
His book, Surviving Object-Oriented Projects remains my number one book recommendation for running iterative projects.

Alistair,
You are an experienced practitioner of iterative process. Your iteration period differs from other Agile process practitioners. Also Agile community has given a new term "deliver".
So my question is: In your views, what is the definition of an iterative, a release and a deliver?(the period and the practising of each?) How to define milestones?
Thanks.
[ February 19, 2002: Message edited by: Doug Wang ]
[ February 20, 2002: Message edited by: Doug Wang ]

I personally distinguish betwee increments and iterations. It might not always be so, but I try to "deliver" after what I'd call an "increment". Conceivably someone would define a "release" as some number of increments, but I haven't worked with projects that have such short increments yet.
At the core,
- "increment" means "add to."
- "iterate" means "revise"
- "release" and "delivery" mean just that.
I got some flack at the Snowbird meeting because I'm comfortable with a 3 month increment (consisting of several iterations) - turns out it was just a confusion of terms, because the XP "iterations" don't actually result in any "delivery". Actually delivering is a "release", and releases happen - guess how often - about every 3 months or so.!
Actually, there was a so-called XP project I won't name that did successful "iterations" for a year. then my contact mentioned that everyone was on edge, because coming up was the first "delivery"!!! Imagine my surprise - I can't imagine going for an entire year without a delivery, but this group was betting it's entire output on one delivery.
Alistair

Alistair,
Thanks for your reply.
In your book you said, We feel we hava "uncovered" practices more than invented them, and want to be clear that we will continue to work by helping as well as by telling. What will you do to accomplish that? (Actually, this book is more about the philosophy and rules of Agile methodologies than a how-to book, right?

)
Agile methods people think process should be adaptive not predictable, then how to do planning for a Agile process? What is your solution to achieve better understanding of business and quicker response to business changes?
Thanks.

Originally posted by Doug Wang:
Alistair,
Thanks for your reply.
In your book you said, We feel we hava "uncovered" practices more than invented them, and want to be clear that we will continue to work by helping as well as by telling. What will you do to accomplish that?
Agile methods people think process should be adaptive not predictable, then how to do planning for a Agile process? What is your solution to achieve better understanding of business and quicker response to business changes?
Thanks.

That's a bunchof questions...
All of us both code, run projects, and also visit projects. I personally learn more from good developers/managers telling me what they do that I've never seen before than by inventing it on my own. My learning is listening to others. Then I pass along the ideas to others who tell me how they worked, or I get to try them out myself. Working this way, I "uncover" better ways of working, I don't invent them.
"Responding to change" rather than "Following a Plan" is the operative comparison.
Planning is important. By doing the planning activity, you learn where dependencies like, uncover possibly problems, pick a path to go forward on. "Responding to change over following a plan" means changing the plan when circumstances change, rather than sticking to the out of date plan.