I love stories - always have.
In high school, I didn’t do English Literature, assuming it was the land of flowery poetry and enormously dense 19th century European texts, with essays several thousand words long expected at every juncture. Yet I was for a time part of a creative writing club, watched a great deal of fantastic movies and documentaries, and remain to this day a voracious reader. Likewise while I am an avid sports fan, it is not just the act of kicking a ball or shifting gears that continually draw me to the TV screen or stadium - it’s the overarching drama and story of courageous drivers, players fighting back against all odds, or small teams springing the upset of a lifetime.
Perhaps then it’s no surprise that I find the world of software delivery is enormously enriched by the presence of storytelling. This includes the idea of “Agile User Stories”, one of these terms that makes me confused and suspicious, considering the idea of User Stories were around before the Agile Manifesto itself, or the many Agile consultancies and certifications that have resulted from it. To borrow a couple of phrases from the late nineties;
“A user story is a promise for a conversation”
~ Alistair Cockburn
“A “Card” (or often a Post-It note), a physical token giving tangible and durable form to what would otherwise only be an abstraction. A “Conversation” taking place at different time and places during a project between the various people concerned by a given feature of a software product: customers, users, developers, testers; this conversation is largely verbal but most often supplemented by documentation. The “Confirmation”, finally, the more formal the better, that the objectives the conversation revolved around have been reached.”
~ Ron Jeffries’ 3C formula for User Stories
The code you might write may indeed literally throw up a dialog on the screen with a couple of buttons; but the overarching story is something much more important. It’s the way that I as a customer am asked to double-check my account numbers before transferring a large sum of money. It’s the machine readout that I, as a registered nurse, need in order to ensure a safe dosage of drugs for my patient. It’s the warning prompt that’s guiding me as a pilot to ensure that I don’t stall the aircraft.
Stories give us context, but they should also give us empathy, something critically lacking in a lot of software development. They should allow us to understand what our customer needs and why they need it - and that in turn should allow us to build a better product, and verify that it’s a better product while we’re at it. They should not just be an exercise in repetitive, “because-we’re-Agile” necessity:
“As a Blogger, I need to blog, In order to be a blogger”
~ User stories by every jaded software team ever
Stories also assist with something just as important - the transition of knowledge. Language is a incredibly useful technology, and with it we have built our civilisation from descendents of tree-dwelling primates to a freakin’ space-dwelling species! Our collective knowledge is written and recorded in scrolls and books, saved to electronic media, and now entirely distributed across the whole of humanity’s digital footprint. We also have a rich oral history - cultures like Australia’s first peoples have passed down laws and information from a time beyond our modern comprehension.
It is these acts of knowledge transfer that I find most interesting and engaging. Yes, I can look something up in an encyclopedia or reference manual and learn all about it - but you will be guaranteed my undivided attention if you can pass that same knowledge to me in a story; and I am far more likely to retain that information. I could read a thick tome of Ancient Greek history to learn about myths and legends - or I could read The Odyssey. I could read about exploration on the surface of Mars, or I could listen to first-hand stories from someone actually doing it. Or importantly, we could tell our junior engineering colleagues not to do something, or we could share with them our own experiences and what we’ve learned from going down that path before, and in turn ask them to share their own thoughts.
As engineers and developers, the temptation might always be to stick our heads down and RTFM if we’re in doubt. But we can do so much better than this - and we can produce better software if we go beyond these black and white interpretations of requirements. We don’t need the poetry or the three thousand word essays; but we can have simple conversations, capture some key notes, share knowledge with each other, and get some extra context that can make all the difference.
If that seems like a chore to you, then you you might be doing it wrong. Maybe you just need to read a good story?