I came of age in a professional environment that was excessively clunky. Information technology, having had its way with the financial industry, was making its way into the inner workings of all sorts of organizations. The people, however, were still very much accustomed to the thought processes and organizational methods that emerged from the ‘productivity’ thinking of the 1960s and 1970s. The emphasis was very much on strategic planning, rigidly defined bureaucratic specialization, tremendous amounts of documentation and detail, and a privileging of process above all else. It was, from an experiential perspective, slow.
And as often is the case with disruptive technology, it is commonly the set of people who introduce it that are first forced to actually accommodate the new ways of thinking and processing information that said technology necessitates.1 And so, several forward-thinking software people were forced (really) to create the Agile Manifesto. Building software the old way, let along getting people to use it, just did not scale.
Our teams (and my current and many past employers, including myself) make use of Agile methods. I am a believer in these methods. I believe in them because they work better than most. Like any method, they must be adapted to the practitioner’s local context to be effective, and therein lies several cycles of adaptation and experimentation, much of which is usually painful and illuminating.
Lately, I’ve been thinking a lot about how people tend to focus on the post-adaptation and post-experimentation phase of applying methods for dealing with work problems, often to the detriment of the actual problem the method was trying to solve. A wise man pointed me to the concept of orthopraxy, defined in contrast to orthodoxy, as an emphasis on conduct and actual practice as opposed to ritual and accepted belief. I’m probably butchering (or appropriating) these terms when I say that orthopraxy is about doing what works and orthodoxy is about doing what’s commonly accepted as working.
Recently, one of our teams had a Come to Rabbiâ„¢ conversation2 about their delivery vs. their clients’ expectations. The outcome of this conversation was a recognition that requirements needed to be better defined. Some of the members of this team come from Agile backgrounds, but many do not. And so the dreaded Waterfall words were uttered: “functional specification.” And the classic texts get distributed: Spolsky on Painless Functional Specifications and Fried on No Functional Spec, and Atwood on Dysfunctional Specifications. The dance begins. What works? What’s commonly accepted as working?
Given a long enough perspective, you can begin to see the same dialectic cycle which produced Agile beginning to generate the need—or at least the desire—for new approaches. This is no startling insight, just common sense and observation. Things which are radical answers to the previous cycle’s orthodoxy inevitably become the new orthodoxy. And that’s where the danger arises. Organizational structures evolve in ways that are at odds with their initial intent. Teams get stuck in patterns of orthodoxy, where the noble intent of their methods are reduced to cargo cultish repetitive behaviors. It’s the opposite of pragmatism.
I have seen this pattern before. It was present when I worked in the world of User Experience, where the orthodoxy of what were once radical design sensibilities came into conflict with the need for new methods presented by digital products. I’m seeing it now, with increased frequency, around words like “design” and “long-term roadmap” and phrases like “what are we really trying to solve for?” when mixed with Agile development.
So the interesting thing here, going back to all the annoying “Old Guy Having Seen It All Before” talk at the beginning, is that these things have a way of working themselves out. Quickly, call out the pattern and come to grips with the cracks in the edifice of orthodoxy. The sooner you focus on what works as opposed to what’s commonly accepted as working, the sooner you come to a better synthesis and move on. Until the next time, when down will go back up, forevermore!3
- Back in Graduate Schoolâ„¢ we used to call this an epistemic community. [↩]
- The astute reader will recall, of course, that the Savior in question was in fact, a Rabbi. [↩]
- Thanks, Uncle Bob. [↩]