What the heck does Agile mean anyway?
I’m currently looking for a new contract and every time I see a job ad with the word “Agile” in it, I’m faced with a conundrum. I don’t really know what it means and as a result I’m not sure if I actually have Agile experience. I certainly have _agile_ experience and I’ve done lots of the things that make up what they call Agile development. Stuff like iterative development, TDD, pair programming, refactoring, continuous integration, working with user stories and backlogs, working with and developing coding standards, participating in stand-up meetings and retrospectives, being on self-organizing teams (with mixed results) and dealing with highly volatile requirements (not to mention customers). I have actually only been on one project that was a ‘by-the-book’ Scrum project, but that was only about 9 months of my 8 year career and for a good chunk of those 9 months I was on a team of 1 which seems to go against the whole idea of ‘Agile’. I’ve never been on a real XP project, though I’ve interviewed with a couple and had many second-hand conversations with people who have. I’ve read alot about Agile development and obviously written a bunch about it on this blog.
And yet, I still don’t know if I have Agile experience because I don’t know what it is. I hope the people writing the job ads realize that they may be missing out on a good chunk of the developer population when they require ‘Agile’ experience and don’t expand on what they mean by that. Of course I’ll still apply and if it turns out they want ‘Agile as in XP/Scrum’ experience, I’ll just turn tail and run. Here’s hoping they actually want ‘Agile as in adaptable, flexible problem solver using a large set of tools and experience to deliver customer value on accelerated schedules’.
on August 17th, 2007 at 5:09 pm
Isn’t it just a clever marketing term to line the pockets of consultants, tool vendors and third-rate authors? ;)
on August 20th, 2007 at 1:19 pm
It always though it was ironic that the most popular Agile process (XP) is a brittle, hard to change, all-or-nothing process. There’s usually little room to adapt the process to your context.
For doing a minimal design, you need constant refactoring, for doing constant refactoring, you need extensive unit tests. As the documentation is the code, and to ensure the quality of the unit tests, you need to pair program always…
(you get the idea… A Self-Referential Safety Net)
It’s very hard to change any practice without affecting adversely the others… that doesn’t sound much agile…
Note: Edited to fix the link - tbeck
on September 28th, 2007 at 2:52 pm
I don’t think it’s worth worrying about if you apply The Thesaurus Heuristic: assume that people mean different things by the same words, and the same things by different words. “I may have worked on an Agile project, but perhaps not by that name.” THEY think they mean something by “Agile”, so the quickest way around the problem is to note that you’d like to avoid misunderstanding, and to ask what they mean by it.