When the hair-afire call came in, for the next hour I talked my longtime colleague down off his metaphorical ledge. One of the world’s foremost quality experts, he’d been tapping into Agile discussions on Twitter; and the religious-like logic-resisting parroted irrationality being promulgated drove him to the brink. Not only did he feel they were spouting nonsense, they automatically resisted any questioning or contrary information; and they seemed incapable of comprehending let alone critically analyzing anything except their single almost mechanically-voiced view of truth.
Welcome to today’s world of what I call “conventional we’s dumb.” Up is down, alternative facts abound, and perpetrators of truly fake news have convinced their followers that all the other (actually factual) news is fake (see “Unconventional Wisdom V4–Testing’s Donald Trumps” at https://huddle.eurostarsoftwaretesting.com/unconventional-wisdom-v4-testings-donald-trumps/.
No Requirements?
One of the things that most irked my colleague was when Agile folks claimed they had no requirements and then merely kept repeating their claim when my friend tried to engage them in dialogue and, heaven forbid, reasoned analysis. My friend knows all too well that requirements are the key to quality and thus are essential to any project. Confronted with what he felt was unabated noise, ultimately he snapped and phoned me to vent.
Why would hopefully-otherwise-sentient beings seem to act so mindlessly? First, it’s pretty likely that because many Agile projects do not have things called “requirements,” these folks assume there are no requirements. Second, to many of them, “requirements” means some particular probably-cumbersome document they associate with waterfall projects, which Agile generally knee-jerk rejects out-of-hand; so they indeed don’t have such documents.
Third, when asked about user stories, which many people do consider requirements in Agile, some Agile folks repeated incantation-like the disingenuous nostrum that user stories are not requirements but rather “placeholders for conversations.”
We’ve Seen this Before
“Unconventional Wisdom V10: What Is A Test Case Anyway? No Test Cases, No Way” at https://huddle.eurostarsoftwaretesting.com/unconventional-wisdom-v10-no-test-cases-no-way/ describes how exploratory testing (and some Agile) folks similarly and irrationally claim they don’t have test cases. Because they assume test cases must be written and in a particular format, absence thereof must mean they don’t have test cases.
However, as with test cases, requirements need be neither written nor in some particular format. Just as executing a test means there is a test case, the existence of a project means there is at least an assumption of what the requirements are that the project is intended to satisfy. Written or not, though, requirements often are incorrect and/or incomplete. Projects rely on reasonably accurate and complete requirements.
Writing as Enemy
From its Manifesto on, Agile repeatedly proclaims that writing interferes with understanding whereas face-to-face conversations enhance it. Nonsense! Thousands of years of human history and countless personal experiences tell us differently. Oral communications are notoriously unreliable. Consider the children’s game of telephone, which ironically Agile folks often cite as somehow supporting their contentions.
Writing in fact aids understanding, especially across time and multiple persons. That’s why the Statute of Frauds is fundamental to law and says certain agreements, such as for real estate, must be written to be enforced. Writing alone can be relied upon as the way for everyone to see equally what the agreement is. Different understandings and interpretations still can arise; but the writing reduces the number and extent of disagreements, and ultimately the writing enables objective resolution.
Yes, some writing can obscure meaning. Some people assume requirements always exhibit factors such as length, content complexity, and unclear writing styles that indeed can impede understandability. Recognize the difficulty comes not from the writing but rather from how they are written. Unlike evanescent conversations, tangible writing can be reviewed and revised to improve understandability.
Giving Face-to-Face its Due
My guess is that Agile’s intent was to focus on questioning and clarification, which face-to-face can facilitate and indeed can aid understanding. That’s essential and should be encouraged, especially when identifying requirements. That’s what a business analyst is expected to excel at. We know such skills vary widely. Too often, though, nobody is good at it, especially those charged with carrying out Agile’s conversations.
Moreover, questioning and clarification should not be the end of the process. Findings need to be captured in a more observable, shareable, and reviewable form. We can’t rely on “Do you understand?” to assure what’s in each participant’s head matches what’s in the others’ heads.
That doesn’t mean the form has to be cumbersome. User stories are a good start but need to be retained and augmented efficiently rather than lost in “conversations” of questionable capability. My forthcoming book captures unconventional wisdom, concepts, and techniques in my popular seminars on Writing Right User Story and Acceptance Test Requirements Right. Email me to learn more.
“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.
