The Memorable Power of Agile Storytelling

I like reading books about corporate dysfunction when they come in the shape of a compelling (fictional) narrative. Business writers know how storytelling can spice up dry theory and support their argument. Patrick Lencioni’s The Five Dysfunctions of a Team and Gene Kim’s Unicorn and Phoenix projects are good examples. It works for popular science too. In Snakes in Suits, psychologist Robert Hare, a renowned authority on psychopathy, explains for a lay readership the manifestations and biological foundations of this dark human design flaw. He interweaves the science with a chilling fictional narrative of a parasitic young suit slithering his way up the corporate ladder. So, when a coworker told me the other day about an especially glib colleague who lied, cheated, charmed, and flunked his way to job security, I immediately thought: psycho!

In software, any rule or recommendation, whether it’s the Law of Demeter, SOLID principles, or the Agile Manifesto is the distillation of years of experience, spirited discussion, and plenty of compromises. Observing how teams work has led us to certain recommendations that boil the specific down to the generic. Stories are a wonderful aid to explain and justify such rules because they can show how the rules were arrived at in the first place. They supply the back story that reconnects the specific back to the generic. You need these to know and respect the justifications behind a principle. It’s not enough to learn a rule by heart if you want to apply it well. Concise lists of opinionated statements make for pithy posters, but the necessary back story is missing from the text. 

Demeter’s Law Is Nothing Like Newton’s

Some bits of the software developer’s rulebook make it into laws – well, that’s what we call them in the case of the Law of Demeter. This is doubtful at best since they’re hardly laws of nature. They are recommendations. Laws are our best efforts to describe how some part of the natural world works, and these belong to the realm of science. If the definition of natural law doesn’t fit observations, it must be amended or rejected. Rules, on the other hand, express how we want humans to behave in certain cases. Rules and laws are derived from careful observation, but rules allow for exceptions and leeway. Laws don’t. Demeter’s law is different from Newton’s in that it needs your judgment to decide when it shouldn’t apply. There’s a good reason why Donald Knuth didn’t call his highly mathematical magnum opus the science of computer programming. 

Still, rules about software development practices should be rooted in proper science. Any established Agile way of working (whether the original manifesto or the new Agile 2) is still an agreement between fallible humans, with all their likes and dislikes. Therefore, their rules must have a sound scientific justification, drawing from research on psychology and sociology that shows how individuals and groups actually function rather than how they should according to your biased preference.

There’s no better way to expose the fallibility of our presumed failsafe recipes than by reading stories of disasters, especially when they are not fictional. The Mythical Man-Month and Dreaming in Code are humbling accounts of teams who played by the book and failed badly. The best minds in the field and their dedication to solid craftsmanship can’t save a project when reality gets the better of their ambition.

The educational benefit of stories has a neurological explanation. We’re terrible at remembering random data.  Any amateur musician knows that the words of a song are much easier to memorize than its chord scheme, even though it’s a fraction of the informational content – another reminder not to make simplistic comparisons between computers and the human brain. To make something stick, stories are the most natural and effective way to process and store data.

The Famous Ruling of the Diluted Milk

On the topic of effective memorization, allow me a little segue into the realm of ‘the’ law. As a fresh Eng. Lit. graduate planning his next move in life I took some courses in Dutch criminal law, a lifetime ago. As a student, you are supposed to know many seminal supreme court rulings, on top of all the other stuff you’re supposed to memorize. This is not as tedious as you may suspect.

It's easy to presume that a judge can simply go ‘by the book’ once the facts of a case are established. Surely the legislature has expressed their intent in a sufficiently generic fashion to apply to many hypothetical circumstances and is precise enough to leave no room for differences of interpretation? The court need only rule whether the facts of the case apply to the words of the law text. It’s not always that clear cut.

Sometimes the prosecutor or defendant challenges the supreme court to pass a verdict on how the law itself should be interpreted. There was the famous case (1916) of a milkman who was fined for diluting his milk (a common scam). Since it was his unwitting clerk who had sold the product, the boss (though clearly in the wrong) thought he could be let off on a technicality. He argued that the law did not demand that criminal intent be proven for minor misdemeanors (which the clerk clearly did not have) and that therefore the clerk was also guilty, merely for being the distributor of the impure product. This argument was rejected, as you may expect. But trivial though the case seems, it forced the judiciary to rethink the very notion of guilt. You can never be punished without a reasonable degree of culpability. Every law student knows the ruling of the diluted milk, the Melk en Water Arrest.

I hope the relevance to this article is obvious. After 25 years I still remember several of these crucial court cases. They make the abstraction concrete. They tie together in a single story both the specific law texts, the legal concepts underpinning them, the practice of passing law, and the facts as they happened. 

Stories illustrate the need for compromise which is so easily forgotten. Do self-governing teams produce the best work? Well, I have stories in support and stories to the contrary. So do you, most likely. Whenever you find yourself newly in love with a tool X, language Y or pundit Z, bring yourself back to earth with a simple web search on ‘Why X/Y/Z sucks’.

No Worries, We’re Only Going to the Moon and Back

I’ll leave you with a story about courage, the first value of Scrum. Have you ever fixed a crucial bug prior to deployment? How did it make you feel? Not too confident, I bet. Go watch the amazing Netflix documentary Apollo 11 for some perspective. Billions of dollars were poured into the biggest and most hazardous engineering feat of all time. The possibilities for mishap that would mean certain death for the brave astronauts were too many to contemplate. Already kitted up and on their way to the launch platform, the engineers who were running final tests on the Saturn V rocket had discovered a malfunctioning fuel valve and were frantically tightening some bolts (12 minutes into the film). Not to worry, they were only going to the moon and back with the whole world watching.