What does "Agile Development" mean to you?

[jducoeur]

[Not strictly aimed at programmers, this time -- I'm interested in hearing from anyone in the software field who has an opinion.]

I was in an interesting discussion on one of the Scala mailing lists last week, and we wound up off on a tangent about "Agile". My correspondent described how he strongly dislikes Agile, and why -- and the interesting thing to me was that his definition of Agile not only didn't match mine, it was in some ways directly *contradictory* to mine.

I've been starting to realize that, 15 years into the process-management revolution in software, the term "Agile" has become ever-squishier. This hasn't been helped by management consultants who sometimes spout complete nonsense, or more often take a specific dialect of the idea and say "This is what Agile means".

So here's a quick question, aimed at my many techie friends: what does the word "Agile", in the context of software development, connote to you? What are the two or three *most important* aspects of it? I'm not looking for answer just from the experts here -- I'm at least as interested in the viewpoints from the people who have only been reading about it in the trade press or blogs, and what impressions you have gotten. And I'm curious whether the viewpoints and priorities differ between, eg, the programmers and the project managers.

(I have strong opinions about this myself, of course -- I've been an active proponent of some of these ideas from almost the beginning. But I'd rather hear your viewpoints first, before I spout off...)

Comments

[curiositykt.livejournal.com]

I'm going to crib off what votexofchaos said:

I was brought into an "agile" project after having been through many "six sigma lean" projects. This is what I was promised:

1. Stories that define the development, with specific tests to verify success/completion.
2. A well maintained priority list of this sprint's stories and beyond, that get reprioritized after each retrospective.
3. Short scrums.
4. A good way to track progress on a story.
5. A burn down chart that shows progress overall.
6. Unit tests that I can use to verify that my code works, and that I haven't broken anything.
7. A real retrospective, that talks about process improvements.

What I got was
1, hey, can you write down everything everyone does in their job functions as "user stories", but I've never done their jobs? that doesn't matter! you can just muddle through and see if you can figure out their workflow from how the system should work!
2, Your priority today is X, no, wait, Y, no wait, Do both of them as fast as you can as we are behind on Q (which I had never heard of)
3, Our Scrum meetings were on the phone and lasted upwards of 2 hours. A complete waste of time for most of us, as we just had quick updates to talk about, but there were always people who wanted to talk in detail about every little thing they found....... I was surprised when I told one of my friends about our scrum meetings that they were supposed to be 5 minutes, standing up.
4, Our progress charts generally got left for last to update, so generally we'd go in and highlight everything green in one big spree
5, see 2, and 4, this generally was very badly managed.
6, I wrote the testing protocols and ran them, my theory was use the scientific method to divine what had been build and how it worked, in doing so I found some seriously giant problems in the code and actually got the entire 3 year project scrapped because it was evident from my methodical testing that the updates (which were on top of bad, rotting code) would not in fact work.
7, This was by far the best part. I got to sit in on a meeting with the high ups and share how I felt the whole thing had gone. I'm still shocked no one was fired, including me.