[al_biglan]

"agile vs. Agile" you mix the cases in this :-) I wasn't "there" in 2001, but it seems to me that Agile (the proper noun) is nothing more or less than :

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

Where do sprints and iterations fit into this?

I think way too much has been made from the Agile ideal. Many things try to codify Agile into practice, Iterations are great, but why timebox them? Is timeboxing an Agile pattern? Then does a process like Scrumban fail out of being Agile? Does this differentiation help us as practitioners?

IMHO: an Agile organization is one where all the members agree to the Agile Manifesto and use it to help guide their methodology and process selection and optimization.

[dkarl]

I use big-A Agile to talk about the codified and sclerotic form of Agile taught by cookie-cutter consultants. Somewhere there is a sacred text, an Agile Leviticus, containing ceremonial forms that people adhere to with religious faith. Even if the forms fail and are adjusted or abandoned at one company, they will be revived in their original form at the next company, citing success at the first company as proof of their power. Thus Agile never changes no matter how often it fails, which is why it deserves to be a capital-A proper noun.

Little-a agile is a characteristic of software development organizations that programmers and managers strive to achieve, pragmatically adopting the processes that help them achieve it.

The Agile Manifesto can be used in service of either agile software development or Agile the consulting religion.

[Someone]

I know that in the more generic form:

  methodology is good, Methodology is bad.

I think this applies to any methodology, including waterfall. Another way to phrase this is "never stop observing, never stop acting on observations". Acting does not equate doing something, however. Even if you do nothing, and let the wagon roll on, you must know why you are doing nothing.