[abalashov]

Ahhh it actually sounds like your team was originally being Agile

This statement is unfalsifiable; this kind of retroactive defense makes Agile out to be an ever-moving goalpost. If any effective, basically "good," organic team behaviour was "Agile" to begin with, there is no identifiable differentiating criterion of Agile methodology from any other mode of small-scale collaboration.

[Rabidgremlin]

Interesting point. The thing is, any Agile method is supposed to evolve with the team. Long running Agile teams are often not following any one methodology but rather using the best bits of a bunch of them, in a way that works for the team.

This stuff is mostly common sense so you will find that many small teams are often Agile even if they don't know it. Modern software dev is really more about effective communication and collaboration then technology and tools.

My take on it is: If what you are doing aligns with the Agile Manifesto and its Principles, then you are Agile even if you are not doing TDD, peer-programming, daily stand ups etc. No matter what the zealots are telling you to the contrary.

[DanielBMarkham]

Agreed. Another way of putting this: Agile is best practices for iterative, incremental development. Applied agile means borrowing/stealing practices from others, and more importantly creating and adapting your own processes to your particular team.

[DanielBMarkham]

While I think you're trying to be critical, you've actually hit on a key point in agile.

Agile is about principles, not procedures.(I speak of litte-a agile, not big-A agile). It also emphasizes people, not artifacts. Because of this, two things naturally occur: 1) Whether or not you are "doing" agile is a judgement call, not discoverable by a formal prof or checklist, and 2) agile is more like playing the piano than learning calculus. You don't learn it by watching a film about it or reading a book: you learn by doing it and getting better over time.

You can look at this as "moving the goalposts" if you like, or you can look at it as optimizing for each circumstance. I think realizing that there are no goalposts is one of the stages of actually getting it. (and there are many folks in the agile camp who have not gotten it yet)