Unconventional Wisdom V6: Gurus Often Least Likely to Understand Good Ideas

Have you noticed that much of what I call “conventional we’s dumb” is touted by gurus? Gurus are Testing’s Donald Trumps and the main servers of Exploratory’s Kool-Aid. Albeit with the best intentions, gurus lead us into the Testability Trap and over-relying on traceability and poor practices that are certainties rather than risks. Conventional wisdom suggests such supposed subject domain experts would best recognize, understand, and espouse good ideas; but too often they’re least likely to.

Conventional Wisdom’s Common Undesirable Outcomes

In case you haven’t guessed, I use, teach, and advocate several methodologies that differ considerably from conventional wisdom promoted by gurus and their followers. My methodologies generally incorporate the same low-level techniques that often constitute the bulk of conventional guru methodologies; but my methodologies apply the techniques within different more effective models and approaches.

When I present one of my methodologies and its models in a seminar or featured conference presentation, I find that a large portion of the working practitioners in attendance understand it and appreciate its benefits. They frequently express comments such as, “Thank you, I finally understand why conventional supposed good practices keep producing poor project results; and I see how your methodology provides a way to get the better results I want and need. I wish I’d known about it before.”

In contrast to the working practitioners, though, the purported expert gurus often have much more difficulty understanding my methodologies, recognizing how mine differ from theirs, and why mine can and do produce such better results.

Why Gurus Can’t Comprehend

Someone more cynical than I might simply attribute the gurus’ resistance to basic competitive market economics. That is, the gurus make handsome incomes selling their particular conventional wisdom through books, speeches, training, and consulting. It would be understandable for them to resist and even attack any methodology that might compete with theirs, especially one that may draw their’s into question.

However, I’ll give gurus the benefit of the doubt that they are not simply resisting competitive risks to their incomes. Rather, while some are simply self-absorbed, I think it’s more likely that most gurus are so fully invested mentally in their own conventional wisdom that they truly are incapable of comprehending anything different. Perhaps even more than the average person, it’s very hard for them to shift their paradigm ways of interpreting the world to see, let alone appreciate, a different view. Some examples follow.

REAL Business Requirements

I wrote my book, Discovering REAL Business Requirements for Software Project Success, to address an important aspect that I believe the conventional requirements community misses. As institutionalized in IIBA’s BABOK®, most requirements gurus’ books and courses, and probably your own organization, consider requirements to be features of the product, system, or software being created. They commonly say that creep (changes to requirements that had been agreed upon) is due to such requirements that are not sufficiently clear or testable. That’s not wrong, but it’s not the full story.

Many also adopt what I call the “levels model,” which says that business requirements are high-level and vague, mainly objectives, that decompose into detailed product/system/software requirements. To this model, the only difference between business and product requirements is a level of detail or abstraction.

I think a different model is more appropriate. My model recognizes that products do not themselves provide value. Rather, value comes from satisfying what I call REAL business requirements—business deliverable whats that provide value by achieving objectives when satisfied by some product/system/software how. Creep occurs when products do not satisfy the REAL business requirements, usually because the REAL business requirements have not been defined adequately, in turn usually because gurus and conventional wisdom say product requirements features are THE requirements.

The guru in charge of editing BABOK v2 [IMHO condescendingly] assured me that he fully understood and had incorporated my subject expert review comments in the final version; but of course neither was true. Nor have I detected any trace in v3, despite numerous review comments. Another leading guru who best articulated the product and levels views, and for whom I have the highest regard, nonetheless cannot see the difference between the levels model and my model where product hows respond to (rather than decompose from) REAL business requirements whats that indeed are driven down to detail but remain whats no matter how far down in detail they are driven.

Proactive Testing™

A prominent Trump-like testing guru who is famous for trying to usurp control of other people’s presentations berated me in a conference seminar for what he deemed the sin of “requirements-based testing,” ironically because documented requirements tend to be so often inadequate. Like some other self-obsessed gurus, he didn’t seem very good at input, and never did catch on that the seminar title and topic involved “21 Ways to Test that Requirements Are Right,” not testing that the software meets the requirements.

One of his equally self-impressed and closest colleagues once out of the blue included a slide lambasting Proactive Testing in his keynote at another conference. This guru had never attended any of my presentations and apparently drew his damning but quite erroneous conclusions merely from looking at my slides in the conference proceedings. It took a series of six emails before the guru even acknowledged the possibility that maybe one could not tell from the slides alone what I actually say about Proactive Testing™. After all that, he still showed no interest in learning, let alone understanding, what I do say about Proactive Testing™.

We shouldn’t be surprised when less-informed folks have difficulty with different ideas, but often they can and do understand and learn from other views. I’d expect more-informed gurus to thrive on other ways of thinking; but I find (hopefully not all) gurus too often instead are unable or unwilling to comprehend concepts that differ from their own. What a pity!

“It isn’t what we don’t know that gives us trouble, it’s what we know that ain’t so.”
– Will Rogers

Welcome to my Unconventional Wisdom blog. Much of conventional wisdom is valid and usefully time-saving. However, too much instead is mistaken and misleadingly blindly accepted as truth, what I call “conventional we’s dumb”. Each month, I’ll share some alternative possibly unconventional ideas and perspectives I hope you’ll find wise and helpful. Read the previous posts in this series here.

About the Author

Robin

Consultant and trainer on quality and testing, requirements, process measurement and improvement, project management, return on investment, metrics
Find out more about @robingoldsmith