When I hear the term "Agile" I think of no more or less than the principles from the Agile Manifesto. http://agilemanifesto.org/
I know some people translate "Agile" to a specific instance of Agile (Scrum, XP, Crystal, what-have-you) but I feel like that's a mistake. If somebody wants to criticize Scrum, I wish they'd criticize Scrum directly, not "Agile." Same for Crystal or XP or whatever.
Would I do pair programming all the time? Shit no, but does that mean I should make fun of it? Not unless I want to sound like an idiot in ten year's time.
Or, if you're anything like Steve Yegge, if you like engaging a lot of hyperbole to "stir the pot" and elicit discussion, or to make a point. I don't know if you read a lot of Steve's stuff or not, but his writing style is often loaded with hyperbole and is somewhat inflammatory.
Agile adoption has generated a lot of hate. That's a shame, because as Steve points out, there's good in there too. (Although he's not hitting on a lot here, the article is nicely done)
The thing with Steve is, you have to look beyond a lot of the specific things he says, and try to generalize to the overall point. That's not always easy and not everybody gets it. I know this well, as I tend to use a lot of hyperbole as well, and I often find people get hung up on the details and skip the more abstract bits. Whether using that style or not is a Good Thing is an exercise left for the reader. :~)
Interesting testimonials. :)
It's a year-long project. One book down, several to go. Wasn't really sure what to do with the other pages.
Well you can point to the manifesto. A statement of 4 core values. That is all it really is.
I agree with you on the "Agile adoption sucks" bit. I think the coders and even managers have abandoned that crowd long ago, leaving the conferences full of coaches and consultants free to waffle on about fluffy ways to communicate and argue about whether the complexity model is better than the systems model or something.
It has been hijacked, and it is now a racket.
I believe this is why the title is "...5 years later and you're still doing it wrong". It's probably worth discussing why things haven't really changed in the past 5 years regarding this.
edit: relevant for historical reasons, but less so for 2012, which is what I thought when I read it. [2006] on the title would be helpful.
When I read this, I thought, "this guy is selling something".
> It combines the code review and the code creation into one step -- brings the review as far forward as possible, so there's no wait.
The only programmers I know who half-heartedly believe that are trying to convince themselves of it in order to sell pairing to pointy-haired bosses. Two things cannot become one thing, if they are meaningful. If you make them one thing, it's because they aren't meaningful to you. In this case it's peer review, and I don't want what you're selling.
My understanding of it is that the intention isn't to combine the two things, it is to interlace them so the feedback loop between them is as tight and short as possible.
Note: I don't really care for pair programming except in short bursts.
Second, let's get definitions straight. Agile is best practices around iterative and incremental development. The word is a marketing term and can cover all sorts of different (and contradictory) concepts. Scrum is a certified way to manage Agile projects. You write a check, there's a board, a class, and a nice little certificate you get.
So it's really hard to jump up and down and yell too much about "Agile" -- the term is just too slippery. (I note he includes a picture of a ScrumMaster class) Or to put another way: ten years ago companies hired me because I was really good at running iterative and incremental projects and could not only do it well, but help train project managers and teams. Now the same companies hire me for the same reasons, but the word "Agile" is attached. If you want to slam all external consulting as being a waste of money, that's fine, but let's be clear what you're ranting about.
Second, because it's best practices, not all of them are going to work for you. And as you grow, you'll find out how to use some (and ignore others). Hell, I'm still struggling with TDD. But I grok pair-programming: it's the same kind of coding you did in college where a couple of people would sit around figuring out a problem. It combines the code review and the code creation into one step -- brings the review as far forward as possible, so there's no wait. Would I do pair programming all the time? Shit no, but does that mean I should make fun of it? Not unless I want to sound like an idiot in ten year's time.
The biggest point to be made here is that Agile adoption is not the same as Agile principles. Agile adoption sucks -- it's full of zealots, religious wars, highly-priced seminars, and feel-good happy talk. It can be just another way for management to micro-manage your project. The terms can mean different things to different people. Consultants make lots of money and provide very little value. And so on. Trust me, I know this: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-...
But all of that is just a study in how screwed up most organizations and movements are. Agile as a set of best practices is awesome. If I want to learn about data modeling, I'm buying some kind of book with a title like "Agile data modeling" because I know it's going to have an incremental and iterative context -- I won't have to do as much mental gymnastics to fit it into what I'm doing. (Disclaimer/shameless plug: I just published the first in a series of e-books to try to teach people without them having to pay so much for consulting. http://tiny-giant-books.com/scrummaster.htm)
Agile adoption has generated a lot of hate. That's a shame, because as Steve points out, there's good in there too. (Although he's not hitting on a lot here, the article is nicely done)