What was this? Some of the comments were lame. No code comments???? Typing speed tests for developers? Sounds like a work culture I would not want to be involved in. Gold stars? Social rewards?! This sounds like grade school practices! As a software manager, I do what I can to avoid this nonsense. This was the only session of SD2008 for which I had negative comments. Very little content here.

With the other comments offering to sooth my ego — “Excellent presentation, I wish every member of my team could have attended” and “Great information, much more than expected” among the most gracious — I have the luxury of equanimity when considering this negative feedback.

The result is that I’m very grateful to this commenter for reminding me of the dissenting voices, the ones I mostly don’t get to hear.

In my daily life most interactions are with people who think very similar thoughts and our disagreements are largely trivial. It’s easy to forget that we’re still the minority. Agile has certainly crossed the chasm, but while we’re working our way through the early majority there’s many more people out there unconvinced and unimpressed. (… or maybe just uninformed? Last night at the Santa Cruz iPhone Developers meetup I met an experienced programmer who had literally never heard of big-A Agile software development.)

In the big echo chamber of the Agile community I sometimes find myself losing interest, for lots of reasons. We seem really good at spending a lot of words to capture subtle differences in technique. If someone tells me they “do Agile” I have no idea what they mean any more. Doesn’t “agile” just mean “do good things” now?

So I thank this Lone Dissenter. I needed his reminder of just how different the world can be.

1. Developer regression testing, better yet TDD.
2. Active stakeholder participation.
3. Regular delivery of working software.
4. Self-organization.

I had special interest Scott’s criteria because I’d just posted my own attempt to the CITCON mailing list the week before. I wasn’t trying to put together a magic recipe but rather to come up with a list of practices without which — or their equivalents — you will fail. My list was:

• Iterations
• Planning game
• TDD
• Automated acceptance tests
• Continuous integration
• Retrospectives

I think these two lists are pretty compatible, but there are two outliers: self-organization and retrospectives. I was surprised that Scott didn’t have retrospectives on his list. I’m naturally a lumper not a splitter, so I’m tempted to say that retrospectives are a vehicle for self-organization and call it a day. But I don’t think that’s honoring what Scott had in mind. By self-organization Scott meant the team should be organizing the work, deciding who does what. But is that really needed to be Agile? I can imagine using all the practices listed but having a manager assign the work for each story. I can imagine it… but it isn’t something I’ve ever done. I don’t remember having the need, though this may be selective memory on my part. Certainly the majority of the time who should do what is obvious to everyone, and when there are multiple people who could do the work then it is divided easily enough. So I’m not sure that self-organization is a requirement but I clearly believe it is better. Better to have people sign-up themselves and have feel a greater ownership in the project.

So is this it, do we have our list? If you’re not doing these you’re in trouble?

My interest in topics like continuous integration, developer testing and mundane excellence have the common thread of “how do we maximize our sustainable (and sustained) velocity?” All too often I’ve worked with teams who find their velocity (and their sanity!) suffering because their codebase has grown beyond unwieldy into unlivable. These seems especially common on projects that are long lived, have large teams, or long lived projects with large teams — the common denominator really being the code passing through many hands.

Paul and I think CruiseControl provides an interesting study here because it is a long lived project that has had over 200 successful contributors. The patterns and practices that enabled this would help many of the projects I’ve seen.

(If you’re interested in SDBP but aren’t registered, this a gentle reminder that Early Registration ends this Friday.)

I’ve always intended to write a longish blog/article/thing explaining and expanding on the ideas from the original talk and what I’ve learned since (including what came up at the Agile 2007 discovery session). But this isn’t that thing. Instead David Smart, one of the facilitators of the CITCON session, reminded me that I said I’d share the slides. So here are the slides as pdf, and a public commitment to provide more explanation in a future entry.