|| seamonkeyrodeo ||
| k a r a o k e | m i n d | c o n t r o l |
Sunday, March 12, 2006
 
Agile Business: The One True List
Being the first part of...oh, I don't know...probably two or three posts over the next couple of weeks on the topic of "Agile" being worthwhile even if it is a "Software Development Methodology," and also why it's not really a development Methodology so much as it's a business Methodology.

Matt has already posted a couple of times on Return Path's adoption of an agile methodology in a variety of areas, so it's probably time for me to weigh in. Here it is:

Overall, I've been happy with we've gotten out of using this methodology.

Now before people start rummaging through my basement in search of Whitney-sized cocoons, let me make a statement for the record: in many cases the phrase "did I tell you that we've adopted a new software development methodology?" still makes me as uncomfortable as phrases like "hey, did I tell you that I got syphilis last weekend?" and "no, no, it's totally not a cult -- why don't you come by the compound tonight so that the Leader can explain it all to you?"

Has everyone processed that statement and continued reading down to this sentence before sending me a "you can't be serious about buying into some bullshit capital-M Methodology" email? No, I didn't think so. Oh, well, don't worry about it. I expected those emails, you punks.

Anyway, why don't you all sit down, make yourselves comfortable, and read on. Here -- do you want a cup of this excellent Kool Aid? Let me tell you about this "one true list" deal...

The One True List of Things to Do
This is a big factor for me. Huge, actually. I'm sure that many of you, whether or not you work in technology, are familiar with the corporate ritual of "the splitting of the list." In the case of software development it usually works something like this:

After reviewing the list of projects that need to get done and the technical resources available to work on projects, a company finds that there's no possible way to get everything on that list done. So the project list is split into two sub-lists, with separate business people responsible for the tasks on each of the new lists. Those people, in turn, then split their lists in sub-lists, delegating responsibility for each resulting list to a different person; the process continues until you have approximately 214 business people holding short but critical-to-them to-do lists -- and 98% of those people are justifiably pissed off because they can't understand why the fuck tech can't accomplish the two simple things that are on their to-do list in a timely fashion. Great.

Following an agile approach you can avoid a lot of this: you have one list of stuff that you're going to be working on for the next few weeks. I'll happily admit that doing this isn't as easy as saying it, and that we (Return Path) are still spending a reasonable chunk of time making sure that the list is and remains the one true list, but having a defined <shudder>methodology</shudder> actually helps here. You've got a process that everyone can understand. For lack of a better metaphor, you've set your rules of engagement, and everyone can either accept those rules or get gunned down like dogs in the street. Metaphorically speaking, of course.

This does mean that you've got a potentially difficult meeting every couple of weeks, where the people with juice need to agree on what's going to get done and what's not, but...well, at the end of that meeting you've come to some sort of agreement; as conflict-averse as I am, I'd much rather have a heated argument leading to (sometimes grudging) consensus about what needs to be done than have smiles, flowers, and puppy dogs leading to N different understandings of the priorities.

And now we come to the part of the post that I probably shouldn't write. I really want to be able to take at least partial credit for "Engineering productivity [being] way up," but there's a dirty little secret hidden in the agile approach.

You see, even if you're putting in a lot of time and effort to do the agile thing effectively, your Engineering folks probably aren't accomplishing much more than they would be otherwise. It may seem like more is getting done, but that's because a strange and wonderful thing has happened: your newfound agility hasn't added more people to your team, or more hours to the day, it's just helped you spend more time on the things that you as a company have decided are the big concerns for you right now. Interesting, huh?

More anon. And one of the issues to follow in a later post is addressing the issue of "we've been doing the agile thing, okay, and it sucks ass in cases where the scope of the project falls outside of an (iteration|release), so you can bite me, agile boy," so you just keep your pants on and don't send me email about that one, okay?

Eh. Who am I kidding? Go ahead and send those emails. Punks.
- posted by whitneymcn @ 4:54 PM
  rate this post, complements of NewsGator Online:
  
Comments: Post a Comment

<< Home

Powered by Blogger