Don't get me wrong: I believe in the Agile Manifesto. I think that its principles are laudable and that its advice is sound. I think that the Agile movement has done a great job of unifying and marketing unconventional approaches to software development. The problem I have is that it is not a cogent philosophy: "Value people over processes & tools", blah, blah, blah -- so what?
Lately, in preparation for a set of presentations on XP, I've been going back and thinking about the White Book; asking myself "why is it that we do all this stuff again?" I know, I know that we tend to fixate on the practices and wax poetically about the values. However, in doing so, I think that we lose sight of the fact that, at its core, XP is about change ("Embrace change" is the subtitle of the White Book, after all). As a system of thought, XP is built on 3 tenets:
- change is inevitable
- change is essential
- change cannot be predicted
Everything in XP is built around this core philosophy: accepting that we must embrace change, how can we minimise the cost of change (remember the much maligned "cost of change" curve?). The values are nothing other than general mechanisms for helping us deal with change:
- Why do we value feedback? Because feedback tells us whether or not we need to change and whether or not the change is working.
- Why do we value communication? Because communication ensures that we all know what is changing and helps us identify what to change.
- Why do we value simplicity? Because simpler things are easier to change than complex things.
- Why do we value courage? Because change always requires courage.
So, in this light, what are the XP practices? The practices are merely a set of concrete patterns for helping us deal with the cost of change. I'll leave the exercise of reframing each practice with respect to how it minimises the cost of change up to you.
Many people object to XP as being too prescriptive: you know, the usual malarky about whether or not our team is doing XP cause we're only doing 8.5 of the 12 practices. To these people, I say that they're missing the point. The point is to understand the motiviation behind the practices (ie. how they help you deal with the cost of change) and then decide if your team is doing enough to manage it. So, you're not doing pair programming -- fine. So then how are you dealing with the cost of introducing new members to the codebase, for example. I don't know your team and I don't know your organisation. Maybe for you the risk of these things changing is minimal. Maybe you only have one developer who never gets sick and will never, ever quit and a detailed process for conducting code reviews. Unlikely, but I don't know. In my opinion, as long as you are actively managing the cost of change in your context and you want to say your doing XP: fine. It's the philosophy, stupid.
Now, back to Agile. Yes, I know that Agile accepts the importance of change. The problem that I have is that is that the principles are not connected to this overarching idea. Are the principles examples of sound advice for running a software project? Yes. Do they help you deal with change? Not exactly.
Lately we've been having a number of conversations about the Myers-Briggs personality indicator around the office. I'm still trying to decide if I'm an introspective extrovert or an extrospective introvert.
I attended the
Linux Bangalore conference last week and sat in on a session on Wiki dynamics. The speaker cited some study on the Myers-Briggs indicators of common Wiki contributors. Apparently INTPs and INTJs make up the vast majority of Wiki contributions -- unfortunately I didn't catch the reference. He then went on to castigate all ENTPs as either politicians or liars. Ouch! Typical judger :P.
Last night I was catching up on some of my blog reading and I read Rachel Davies'
post on MBTI. She references an
interesting article on the subject of personality tests by Malcolm Gladwell. I forwarded the article to
Rajesh who, of course, had already read it.