Last week while attending Scott Ambler’s talk on Agile in Practice at SDBP I tried and failed to share his Agile Criteria slide in real time. Apparently there’s a limit to what iPhone, Twitter and sloth can accomplish in a dark lecture hall. So here, only one week and one day later are Scott’s criteria, the things he looks for when evaluating a team that claims to be agile:
- Developer regression testing, better yet TDD.
- Active stakeholder participation.
- Regular delivery of working software.
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:
- Planning game
- Automated acceptance tests
- Continuous integration
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?