Agile Fundamentalism Or why to tell some "Agile Coaches" to touch grass
Before the word “fundamentalism” became derogatory, it referring to a movement in American Protestantism that insisted upon a return to 5-10 ‘fundamental’ doctrines of Christianity (the number varies as the movement evolved).
The idea was that there were a small number of relatively simple to understand and essential doctrines to Christianity and if you found yourself building an elaborate theological or philosophical scheme that reached contrary conclusions, then this was a sign that you had gone wrong some where. You needed to return to the fundamentals and start over.
Hence the name “fundamentalist.” Emphasizing the role of fundamentals as an error checking mechanism.
The way this became derogatory was that one of those fundamentals was the total inerrancy of all parts of the Bible, and this quickly came to mean that any natural science that concluded the Earth was substantially more than a 5-10 thousand years old had to be wrong.
I’ve been thinking about that a lot lately in the context of Agile processes in development.
Agile is starting to acquire a bad name in software engineering, and for a counter-intuitive reason: more and more developers working in agile shops (often without realizing it), some of them very good agile shops, getting tired of the seemingly endless supply of AgileTM Certified Coaches that show up at conferences and on YouTube preaching process hacks. And they are concluding: “if this crap is Agile, I want nothing to do with it.”
It’s ironic because the Agile Manifesto is (in the original sense of the word used above) a fundamentally (ahem) “fundamentalist” document. It’s basically 4 sentences. And they are short sentences.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
It is very probable that if you read those sentences for the first time, and then had a conversation with an Agile Coach, you would be at a loss to describe how anything they described related with those sentences. The manifesto talks about collaboration, responsiveness to change (that’s where the agile word comes from), interactions between individuals. An Agile Coach (depending upon their Agile sect) will rant about how imporant it is never talk about how long anything will take in a form that could be mistaken for days that appear on a calendar or how sprint/iteration/release-train planning is a highly ritualized negotiation that should be locked in stone at the end.
How could this be?
It be because every Agile process implementation is a solution to a different kind of malformed business process. None of the Agile Coach’s normal bits of advice are bad, in the right context. For example, there still persist, to this day (though they are rarer) the sort of simpleton manager who, despite years and years of experience, still cannot understand or accept that no one can reliably predict how long it will take to invent a new machine to solve a non-trivial problem. So there will never, ever, ever be reliable software estimates for non-trivial projects. The estimates are fuzzy guesses. Good managers know that, so they ensure there is plenty of margin in their plans. But, there are still simpletons who take our estimates, drop them one after another into a Gantt chart, and freak out when everything is chaos 6 months later.
For those people, Agile invented “t shirt size” estimation. T-shirt size estimation is not a best practice. It is a shrink-wrapped, “best practice” labeled middle-finger that says to a manager “You are too incompetent to be trusted with our good information. So, stick this in your Gantt chart.” That is its sole and only virtue. It exists to give a software team the tools to solve a specific type of bad manager: the guy who thinks developers are working on an assembly line instead of inventing new machines.
If you don’t work for such a manager, if your manager understands that estimates are like hurricane paths (uncertain, far out, uncertain almost to the point of uselessness), then basically, almost any estimation process is a good process. So if an Agile Coach shows up and says that your estimation process is wrong and you should be using t-shirt sizes and relative story pointing and planning poker, the answer is “touch grass.” Tell them to return to the fundamentals, because they don’t even understand the basics of the thing they purport to teach.
blog comments powered by Disqus