Agile Manifesto Not So Bad After All

29 September, 2006. 955 words.

I read (most of) Steve Yegge’s blog post on Bad Agile, and thought it was great to hear someone ranting against Agile Development for a change. (Unfortunately, it quickly devolved into a “golly, Google is such a fun playground for programmers, it’s the greatest place to work ever!” rant.)

I admit I haven’t studied Agile Development very much, because it just sounds like another consulting company gimmick. And, frankly, it is. But Yegge’s post got me thinking that maybe, just maybe, there was some technical value to Agile before it was malformed by greedy salesmen into the business fad that it currently is. So I looked up the official Agile Manifesto and looked through their principles. It’s clearly a consulting gimmick, but there is some value in there, too.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Sounds good and vague. A great quote to put on a consultant’s business card.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

I have mixed feelings about this one. Changing requirements are inevitable, but I don’t like allowing the customer to think they can just change anything at will. I expect changes early in the process, but the farther you go, the more expensive the changes get (in both time and money). If the customer doesn’t mind paying the costs of the changes, then fine. Otherwise, don’t change stuff.

That being said, I always try to write code that can be changed fairly easily. Because no matter how much you tell people not to change things, they’re going to throw some kind of monkey-wrench into your project at the end. (“Hey, you need to use MySQL instead of SQL Server, because we heard it’s, you know, free, so our profit margin will be higher.”)

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

In my Amiga days, I’d often release production versions every week. At BrainTrain, there was an unspoken expectation that there should be a working build of the software available every day. Now, I can’t stand stopping a programming session with any non-working sections of code hanging out there, so I’m all for frequent working deliverables.

Business people and developers must work together daily throughout the project.

Daily?? I personally don’t like to talk to business people unless there’s a reason to, and that should only be near the beginning of the project or near the end. The more you talk to them during the process, the more likely they are to question your methods or change their requirements (and, of course, they don’t want to pay for the time it takes to make the changes). But since Agile can be a consulting gimmick, I can see where that would actually be a good thing, because changing requirements means prolonging the consulting work and thus increasing profits.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

I like the concept, but I worry about how one might measure “motivation.” As for environment and support and trust, hell yeah. Nothing is more annoying than having a better development environment at home than at work. Unfortunately, providing good development tools to developers is a rather difficult concept for business people to wrap their minds around. (“Why can’t you just build my new inventory tracking web site with NotePad??”)

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

I disagree. Some people are good at verbal communication, some people are good at written communication. Also, I find it much easier to convey programming concepts, which often involve strange, nonsensical words and acronyms and cryptic punctuation, through the written word. This part of the manifesto was clearly created by a chatty extrovert.

Working software is the primary measure of progress.

Duh.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I have no idea what that means. I guess Agile processes shouldn’t burn people out, which sounds like something that should apply to all of life.

Continuous attention to technical excellence and good design enhances agility.

That seems self-evident to me now, though I admit “good design” is a learned skill. Young programmers never want to design; they just want to dive in and start coding.

Simplicity-the art of maximizing the amount of work not done-is essential.

I agree completely. I hate busy work, but I’ve also learned that there are times when you can get off-track working on a shortcut when you should just buckle down and do it the hard way.

The best architectures, requirements, and designs emerge from self-organizing teams.

I think that means clueless managers shouldn’t interfere with development teams, which makes perfect sense to me.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Makes sense to me. I’m always trying to think of better ways to do things.

So in conclusion, based on the Agile Manifesto, I guess I can get behind many of the concepts of Agile Development, and have in fact been doing many of them for most of my career. I think where I have trouble is in the implementation details I hear about. For example, I think Pair Programming, which is often cited as an example of Agile development, is just about the dumbest thing I’ve ever heard of. (“Say, let’s pay two programmers to sit at the same workstation and do the work of one person! What a great idea!”)

Related