I’ve had a few experiences recently (e.g. at one of the GDC talks that I attended) where somebody uses the word “agile” to describe a process that doesn’t sound particularly agile to me. So I figured I’d take some time to try to understand that difference, and in particular to think about what attributes will cause me to label a process as agile.

I’m trying to make these descriptions neutral, to treat “agile” as a label rather than a value judgment. I won’t claim to be successful in that, because the truth is that I prefer the agile approach in everything that I list here, and I’d be surprised if that isn’t coloring the list at some level. But it’s also true that I’ve happily worked on projects where any one of these is missing. So this response is, I hope, mostly coming from the mathematician side of my brain instead of the pro-agile side: definitions are important, and it’s more important to use a definition correctly than to use a word that you like to apply to a situation that you like.

With that aside, here are some attributes that I see agile processes as having:

  • Iterative and incremental development. You release software no less frequently than once a month or so; more frequent than that is better, with releasing multiple times a day not being a crazy idea.
  • Business / Engineering split. The business side decides what features are the highest priority and what it means for them to be done; the engineering side decides how many of those top priority features they can do in any interval of time. There’s a preference for stack ranking instead of priority buckets, and for the stack to be as small as possible.
  • Team focus. Decisions (e.g. about team processes, about estimates) are made by the team instead of individuals. Code is owned by the team instead of individuals.
  • Focus on quality. The team tries to write good code, code that won’t be a burden on them in the future. They have a fairly stringent definition of what it means for a task to be done. They care about testing and refactoring.

I’m sure there are times in my life when I would have come up with a much more philosophical approach: you can map the above to the manifesto if you squint hard enough, but the manifesto is much more abstract. (And I’m not sure what to make about the fact that, if you do that mapping, my “Team focus” maps to “Individuals and interactions over processes and tools”: “team” and “individuals” are rather different words!) I think what’s going on there is that recently I’ve been reacting to descriptions of how teams work rather than reacting to philosophical treatises: so when people say “agile” in one sentence and talk about individual ownership in another sentence, my brain does a sort of pattern matching, hits upon a mismatch, and responds “why are you using those words together”?

And, of course, I could go more concrete as well: test-driven development, pair programming, etc. It’s possible that the main reason why I’m not doing that is that I don’t actually like pair programming (though I love TDD!); I hope that’s not the reason why I haven’t picked that level of specificity, though. Certainly I don’t want a definition of agile that nothing but eXtreme Programming can match; I guess, though, that I am happy enough with a definition of agile that Scrum alone doesn’t do a particularly good job of matching.

(Hmm, how does Scrum compare against this list? Certainly Scrum has the first item on the list; it should have the second, but my guess is that teams labeling their activities as Scrum are less likely to be good about the second item, though that’s probably a sign that they’re not doing Scrum well. And still less likely to be good about the third, and my vague memory is that Scrum is essentially silent about the fourth item. It’s been way too long since I’ve read the Scrum primary literature, though, so I could easily be wrong. Which makes me wonder if the reverse ever happens: what would a process be like that cared a lot about the fourth item but less and less as you went up the list?)

Post Revisions:

This post has not been revised since publication.