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.
Subscribe to:
Post Comments (Atom)
Posts
Steve, I like your post (and others). I have been pondering what appears to be a similar problem in that I want to introduce a few people to each other, to help them work together and I think I need to understand their respective level of 'mastery'. They are all smart, capable and keen but they have different backgrounds and past experiences.
ReplyDeleteI think the martial arts figured out mastery a while ago and they simply used different coloured belts. I like this analogy because of the Kung Fu series where Grasshopper is learning. Some information appears to be withheld because Grasshopper isn't ready for it - he needs to go through the process to get to the higher levels of wisdom. There is a cycle of consciousness and competence.
For my problem, I think I need to find the common denominator then build a common set of knowledge amongst the new group. Grasshopper seemed to go through some pain to reach each level of enlightenment but hopefully we don't have to lose fingers as part of our enlightenment.
Are you suggesting that you want to apply agile without ever having a master software developer in that environment or that you want to introduce or create a master software developer in that environment. Obviously introducing a master into the environment is teaching them how to fish (in metaphor).
I'm suggesting we need to acknowledge that not every environment will have a master, or even someone who aspires to mastery, and figure out how we can best support those teams.
ReplyDelete