Thursday, August 27, 2009

How I learned to stop worrying and love Enterprise Agile

I spent Wednesday at the Software Craftsmanship North America Conference and the evening at a cocktail party hosted by Thoughtworks. It was a very interesting day, and in the evening a chance comment by Ward Cunningham helped dispel a misconception I've held for a decade. For the last ten years I've been conflating agile and what I'll loosely call mastery. I think it's fair to say that mastery helps you do agile well, but it's not essential to labelling your project agile.

So I sat down and tried to figure out what "agile" was from my perspective. There are clearly lots of ways that you can attack that problem, but for the moment I've settled on this - a project is agile if it uses scope as the control variable and incorporates feedback mechanisms to facilitate that control.

That's a pretty broad definition, but it helped clear something up for me right away. I've been annoyed by resumes that said "agile experience", because I didn't think the people claiming agile experience met the cut. The problem was that saying "has agile experience" is like saying "has programming experience" - it may be true, but it's not terribly useful. You need a lot more detail before you can form any judgement on the claim - what practices has the person been using, how long have they used them for, can they describe the pros and cons? Almost exactly the kind of information you'd want to have about someone's programming experience.

Mastery, on the hand, is about continual learning and improvement, in this case in the agile context. I try to pursue mastery of agile software development, and I prefer to work with people who aspire to be masters, but that's not the only way to approach agile. Most people in any field are not masters, and many do not aspire to be masters in that particular field, but that doesn't mean they won't benefit from understanding and using agile practices.

So while I will personally continue to pursue mastery of agile software development, and want that to be the focus for Cogent Consulting as well, I hope to spend more time thinking about how to apply agile development in environments that don't have access to master software developers.