Musing on Agile’s Built In Caveat Emptor
First things first. I’d like to thank the folks who submitted “Ask Erik” questions (I’m thinking I might need to come up with a title that’s not as lame — iterate all the things!) I’m pleased with the results so far, and early returns on my hypothesis look good. Interestingly, I received more than one question related to my take on capital-A Agile as a movement. I plan on answering these questions directly, but I have opined on this subject a bit in the past:
Reading the questions I received and letting them kick around in my head a bit as I was jogging earlier today, I started to think obliquely about the topic and how it’s approached and regarded in the industry. What’s going to follow is fairly raw riffing on this topic, and please forgive me if I seem a little loopy. It’s about 1:30 AM, I just got back from a concert, and, given that I’ll be off the grid for a couple of weeks starting September 5th, I didn’t want to let a Friday lapse sans post.
1 Agilius
So, story time. What would you think if I laid the following narrative on you?
17 well known, well respected elders from different villages came to realize that the prevailing methods for tending and cultivating crops were not sufficient to feed the growing populations of their villages. These elders had some ideas, both mystical and practical, for how to solve that problem. They’d gained much knowledge on their own and needed to spread the word.
They decided to convene a summit, but the odds were stacked against them. Each village had its own ways of doing things and cultural preferences, and the elders were each accustomed to those around deferring to them. Initially, they could not even agree on a location for the summit! How were they ever going to agree on providing food for the known world?
Against all odds, however, they made progress. They retreated into the mountains and toiled for 2 days and 2 nights, expecting little to come out of the gathering, but when the sun rose on the 3rd morning, not only had they made strides — they’d all agreed, as if by Divine Providence. What emerged from this gathering were stone tablets containing the 4 Core Values and the 12 Principles of food cultivation.
Over the years, the Word spread far and wide. What started as 17 quickly became dozens, and eventually hundreds, thousands, and hundreds of thousands. Great centers of learning and cultural exchange emerged, devotees made annual pilgrimages to important sites, and the new methods for food cultivation spread far and wide. And, lo, it was good. There was much rejoicing.
In case this doesn’t ring a bell with you off the cuff, it’s basically the history of the Agile Manifesto. And, before you bristle, read that history that I linked. It says epistle in there to describe one of the communications between signatories, for goodness sake — if that doesn’t invite religious comparisons, I don’t know what does. Try googling that word and finding a reference in the top 10 that doesn’t prominently mention the Bible.
This post isn’t actually about comparing capital-A Agile to religion. This is well trod ground, and a well placed google search will let you tread it to your heart’s content. But if you temporarily accept the premise as axiomatic, there’s an interesting plank to the agile canon that’s generally missing from religion, at least in my experience with it. What I’m talking about is self-reference in a way that isn’t begging the question.
Framework Self Reference
Religions refer to themselves only to state that they’re right and thus invite escalating fundamentalism. Agile implicitly defines “too agile” as a concept.
To understand what I mean, picture a hypothetical conversation about software process in which two people are arguing about what should be done. Alice says, “remember principle 7, that working software is the primary measure of progress. We must insulate the developers from the BAs and analysts for the next few days so that we can ship next week.”
“Alice, Alice, Alice,” Bob says. “You need to remember principle 4, which states that business people and developers must work together daily.”
Knowing she’s been out-maneuvered, Alice whips out the trump card. “Bob, YOU are forgetting that the first value of agile is favoring individuals and interactions over processes and tools. Check and mate!”
You might be thinking that this is just a contradiction and religions are often littered with those. But this isn’t just any contradiction — it’s a foundational, self-invalidating contradiction. Agile is a process**, and, right there, at the top of the manifesto, is something that states, or at least implies, that processes aren’t always worth following. It’d be like adding an 11th commandment to the existing 10 that read, “using your own judgment is sometimes better than obeying commandments.”
It remains to be seen how this will fare over the course of time, but I personally think that this is why Agile has proven to have so much staying power compared to other trends that have come and gone, good ideas or not. I also think that, whether by accident or design, this sort of framework self-eject button is a really good idea. It reminds me of something I often say when giving advice or coaching people.
I say something along the lines of, “you’ve read all of this that I have to say, and I hope you find it valuable and helpful. But, in spite of my best efforts, it’s always possible that I’m completely wrong.” Caveat emptor, for my advice, and for advice and guidance you get from anyone. There’s no process out there that’s always right for you.
