I was having dinner with some people at a conference and one of them turned to me and said “If you weren’t doing agile what would you be doing?” I remember looking very blank and giving a somewhat vague answer.
In retrospect this was because the question made no sense to me. I don’t “do agile”. I build software that (hopefully) helps people more successful in their other endeavors. Agile is part of the picture but it’s not what I “do”.
By the same token I’m not a fan of "agilist", or "agilista", which is even worse. Although to be fair I’m uncomfortable with any word that ends "ista", with the possible exception of Barista.
Why do these make me cringe? Because they’re descriptions of the means and not the ends.
The continual focus on the means. I’m so tired of hearing ‘You’re not agile unless you are doing …", "You’re only agile if …"
"You’re only doing agile if…" is the means justifying the ends (deontology). In other words dogma. Do these things, their rightness is not in question and the result is largely irrelevant to the discussion. That’s an easy road to follow, as it doesn’t require much thought. At the end of it you’ll find people being burnt as witches. Have fun with that.
The opposite of this is the ends justifying the means (consequentialism). I don’t care how you do it the result is all that matters. An approach popular with dictators and project managers who think that the odd death march here and there and high attrition are "just part of doing business".
Neither of these seem that sensible to me. In fact they both seem "downright unhelpful". This is British understatement, insert your favorite series of expletives here.
To be honest I’m pretty wary of the agile manifesto too now. Not because I don’t like it. I do. But it seems to get misinterpreted too often and often forms huge a rat hole for debate and descent into dogma. All too often I hear people who choose to take "Individuals and interactions over processes and tools" to mean tools (and tool vendors) are in some way bad. This isn’t true. Next it’s back to "You’re not agile unless you plan with cards and sticky notes".
I prefer thinking about good, not agile, software development in the following way:
"I want solve the problems of software development in a rapidly changing environment. I would like to deliver a continuous stream of value to customers and allow my team(s) to say "yes" to changes demanded by their customers’ business. I value the people on my team(s) and want them to continue working with me. We will adapt and improve our ability to say ‘yes’ to new challenges."
Now it just so happens many of the practices proposed by the agile movement seem to have helped teams I’ve worked with deliver good software to people who didn’t know quite what they wanted up front. More importantly it turns out that the values and principles that defined those practices can help adapt them to (new) practices applicable to new domains. I can adapt the principles and augment the values too, if I so choose. This is especially helpful as I never seem to end up working in an environment where all the preconditions apply; my team is distributed, I have legacy code the client can’t be in the room.
Oh and that last bit about adapting and improving is really important. If I can go home thinking that we’re building better software this week than we did last week, even if we still have a long way to go to say we’re doing good software development. Some of the people I talk to from time to time here at Microsoft are on a multi-year journey to improve their process, they certainly don’t need a lot of religion.
I’d rather argue about how you can improve your team’s ability to deliver to customers than how agile you might or might not be. Check out the BeyondAgile group. It’s tag line “*people* making software that *works*” makes a lot of sense to me.
“Be agile rather than do agile”
Hopefully this is food for thought.