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.
Posts
I almost agree with every word. Agility is also often misused as an excuse for the lack of following a process. In such scenarios, one definitely encounters contradicting practices under the name of agile.
3/13/2012 @ 11:31 pm
“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?”
Something like what I’ve had going on my own. Since I have to wear the hats of stakeholder AND developer, I have to be super conscious about what tasks/features/stories I choose to be working on.
Since I don’t have a lot of practice with it, I’ve found that my focus on the engineering side takes over. I thought I could do way more than I could in a sprint, and then delays set in, and I insist on pushing through the delays instead of sitting back and saying, “Wait, no, obviously I bit off more than I could chew and I need to reprioritize or think about the deadline more.”
And it takes me longer to put out a release than it should.
So I have decent test coverage in my project, yet it can be argued that the feature set I focused on wasn’t providing the best business value.
3/14/2012 @ 5:04 am
Okay, I am going to reveal some of my ignorance here. When you say “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,” are you talking about internally or externally?
Because, and maybe this is just my inexperience with professional development (i.e. getting paid to code), that doesn’t seem like a good idea for some projects. For web development, which I’ve been doing on and off (read: mostly off) for the last seven years, that is great. Priority features can be rolled out as new releases break in the support structure over time in the code. However in game development, which is what I assume GBGames is talking about too, that isn’t always possible.
Speaking as an (amateur) indie developer myself, we set our own deadlines more often than not. Our “every day” might be once a week or even “maybe this month.” That constant iterate and release schedule doesn’t really work for a reason I am about to bring up: testing.
For me to use test-driven development depends a great deal on which language I am using at the time. In Java, this is pretty easy. I can use JUnit tests throughout development and tests classes as I write them. For my recent Flash work… well, I haven’t been doing it. Not because I don’t know how, but more because, at least for games, it’s more seeming endless cycles of make-test-change as I have to ‘feel’ it is done more than the code can tell me.
The level code could pass every test I can think of but if it doesn’t ‘feel right’ to me, it’s useless. I think that idea, of being “agile” in that they play-test-iterate, is more what was being talked about. I know that is how I do it anyway.
3/14/2012 @ 5:41 pm
@GBGames: That’s a great example! I was thinking that maybe a skunkworks project might be an example, but I like the specific example of yourself even more.
@Dan: Externally is much better than internally. Internally can work, but it’s way easier to fool yourself if you’re only releasing internally, to have agile processes without an agile feel. Maybe one touchstone is to ask yourself: at any given moment, can I run the build command and get the most releasable game that we could have gotten if we’d decided up front to spent however many weeks we’ve actually spent on the project now? If the answer is “yes”, then I would say you’re doing a good job of being agile (at least according to that criterion); and then when to pull the trigger and do your initial release is a business decision. If the answer is “no”, then I’m more dubious.
Which doesn’t mean that, if the answer is “no”, you’re doing a bad job or making bad choices; like I said at the start, I want to treat agile as a label rather than a value judgment.
As to TDD: partly I agree, partly I don’t. When writing frontend code for one of Playdom’s RPGs, I didn’t write nearly as many tests as I did in other code that I’ve worked on. Part of that is because, in that instance, a lot of the test of the frontend code was whether it looked good on the screen: I don’t know how to automate “looking good”, and the bits that I do know how to automate testing of (the details of the DOM) weren’t actually useful to automate. But part of that was laziness and the poor quality of the code base: there was a decent amount of logic in that code (e.g. moving items around in a scrolling leaderboard), and when I wrote tests for that, it helped me not make mistakes and helped me write more modular code.
And gameplay logic is, I think, similar: when you’re trying to figure out, say, the enemy AI, ultimately what matters is how fun/interesting it is when put in front of another person. That I don’t know how to test; but I’m confident that any implementation of that would have a lot of code that _would_ benefit from testing here.
The XP concept of “Spike solution” is helpful here: that’s code that’s explicitly intended to test some sort of design hypothesis. You don’t spend too much time on the quality of spike solution code, the goal is to figure out your approach as quickly as possible. But you also don’t treat the spike solution as production code: in fact, the XP rule is that you throw away the spike once it’s served its purpose and reimplement it properly. (Which usually goes quickly, because you’ve learned a lot while doing the spike!)
And, again: different reasonable people may make different tradeoffs, it’s perfectly fine for people to do something which I wouldn’t label as agile.
3/14/2012 @ 6:52 pm
I’d give the manifesters the benefit of the doubt and suppose that when they said “individuals” they really meant “people.”
My reading of Scrum is that the prioritized backlog in the hands of the Product Owner is supposed to be exactly that business/engineering split. It doesn’t work if the nominal product owner is unwilling/unable to do a linear ordering. Not sure how common that is.
I think Scrum calls for team decision-making (retrospectives and planning), but shared ownership of code is definitely not part of the Scrum practice I’ve read about. Most of what I have read emphasizes Scrum as orthogonal to development practices like TDD or pair programming.
I believe “done” is supposed to be part of Scrum, but refactoring and avoiding technical debt buildup fall into that not-in-scope category of development practices.
The reality may be that Scrum is not enough by itself, in the sense that you can’t successfully do Scrum if you just do Scrum. Or maybe it’s just that there are a lot of people who are going through the motions.
3/14/2012 @ 10:11 pm
Yeah, that read of Scrum sounds right to me. And I suspect that there are a lot of people who are going through the motions of Scrum, though I also suspect that many people who are doing that aren’t aware that they are doing that.
3/15/2012 @ 8:42 pm