1. Those that are working to be agile but recognize problems in their development that don't fit the manifesto and attack those problems, usually implementing best practices from XP, Scrum, Crystal Clear, or the resources available at www.agilealliance.com
2. Those that want to be agile so they declare that they are agile and tout the buzzword around, but for the most part continue to 'do business as usual' under some type of waterfall method.

note: there is no true agile team that does everything perfectly, because agile is always about recognizing problems and attending to them. The biggest problem i've faced in any organization is their inability to recognize a problem as something that they should do anything about.

So, how do i know if i've found a team that is #1 on this list?

1. They have an XP coach, scrummaster, or someone who is an expert on and facilitates agile practices.
2. The team is allowed to recognize problems and bring them up to the group through having daily scrum/standup meetings (use the term standup meeting or scrum meeting… or timeboxed meeting) where people say only 3 things “what they are doing” “what they did yesterday” “what is blocking their path”
3. The development team HAS a customer on it (or a good proxy of a customer – good means: Not marketing, not ceo, not project manager, but someone close to the real users of the product)
4. Everyone on the team is a “developer”, there is no ‘testers’, “architects”, “QA as their own roles. Everyone does everything, it’s ‘crossfunctional’

how do i know if they're #2?

1. they'll tell you they're agile
2. they have an architect, probably draws diagrams but never actually codes
3. they work from designs instead of from communication directly with the customer. (designs are 3 times removed from the words of the customer)
4. the developers are always getting hit with a fire drill of some sort "Oh we have a demo in 3 days that needs primary attention"
5. the source code doesn't clearly communicate the intent of the software so it's supplimented with pages and pages of documentation.
6. they don't have daily (or at least bi-daily) standup meetings
7. they don't have unit tests
8. they don't have acceptance tests
9. they dont' automate ANY tests
10. they work from a set scope (this means they have to forsake quality to meet time commitments often unless their PM is clairvoyant)