The Storytelling People

Photo by Tim Parkinson (cc license)

I’ve always had an aversion to what I will call, for lack of a better term, “the storytelling people.”

Now don’t get me wrong, these are almost always nice people. Hearty people. Full-of-life people.

But they are also the people who insist on regaling us with renditions of Robert Service ballads around the campfire.

They like to hold festivals.

They wear bow-ties, and cuddle bodhráns at their side. There are beards and pipes. Or tie-died skirts and rhetoric about tapping into the spirtual truth-telling DNA of our wise ancestors. Etc.

This doesn’t mean that I don’t like a good story.

Get Perry Williams in a room and you’ll be lambasted with well-told storylets that can keep you going for weeks. And I’ve always been a fan of the two Alans and the Erskine, and their brother David. Indeed almost any gathering, social or formal, that happens on Prince Edward Island becomes a de facto storytelling session, and we are all the better for it.

It’s not stories themselves, nor storytellers, that I’m averse to, it’s those that seek to institutionalize (and thus suck the life out of) the practice. Going to a “storytelling festival,” to me, seems about as much fun as going to a “sex festival.”

But all of the above aside, the Storytelling People are beginning to make inroads with me, and this week they’ve been working on two remarkably similar fronts at polar ends of my everyday life.

It all began last week, when I sat in on the weekly Product Forum over at Plazes in Berlin. One of the items on the agenda was a discussion of “using stories to describe features.” Immediately my defenses went up. But once I’d heard the story story (so to speak), I was intrigued. The process, well described here, is technically called “behaviour-driven development.”

And it is perplexing mostly for its simplicity.

“Each feature is captured as a ‘story’, which defines the scope of the feature along with its acceptance criteria” is how they introduce the notion, and then continue:

Software delivery is about writing software to achieve business outcomes. It sounds obvious, but often political or environmental factors distract us from remembering this. Sometimes software delivery can appear to be about producing optimistic reports to keep senior management happy, or just creating “busy work” to keep people in paid employment…

And later:

Behaviour-driven development (BDD) takes the position that you can turn an idea for a requirement into implemented, tested, production-ready code simply and effectively, as long as the requirement is specific enough that everyone knows what’s going on. To do this, we need a way to describe the requirement such that everyone – the business folks, the analyst, the developer and the tester – have a common understanding of the scope of the work. From this they can agree a common definiton of “done,” and we escape the dual gumption traps of “that’s not what I asked for” or “I forgot to tell you about this other thing.” This, then, is the role of a Story.

In other words, the role of the story is to focus development on things related to the real world, as opposed to on abstract concepts that can distract and obfuscate.

So a story can be as simple as:

As a Plazes User that has created an activity
I want to spread the activity to others
So that they know about it and can react to it.

Seems simple, no. Perhaps “too obvious.” But imagine some other, more common ways of expressing the same concept (I’m just making this up, but I’ve written like this before, so I know the territory):

We need to develop a system that allows data from one user’s activities record to be messaged to other users so that, if they choose to, these other users can opt to add the same data to their own activity record and apply the usual activity controls to the newly-added data points.

By comparison, the benefits of the “storytelling” approach seem obvious.

The cavalcade of storytelling continued today, a week later, when we attended the parent-teacher interviews at Prince Street School and were shown this:

This is a sample of what, in edu-speak, is called a “social story” and the idea is much the same as “behaviour-driven” software development — indeed you could call it “behaviour-driven personal development.” And if you change around some of the concepts in this sentence I quoted earlier:

Software delivery Growing up is about writing software learning things to achieve business behavioural outcomes. It sounds obvious, but often political or environmental factors distract us from remembering this. Sometimes software delivery schools can appear to be about producing optimistic reports to keep senior management happy, or just creating “busy work” to keep people in paid employment…

…it’s easy to see that many of the pitfalls of traditional software development practice befall educational practice as well. Who can forget the seemingly arbitrary exercise of discipline from school days? So often school rules and discipline procedures lose sight of the “business outcomes” and become a self-contained world unto themselves.

By encasing these “business outcomes” inside a story, everything becomes commonly understandable (it’s easier to develop a shared understanding of what we’re trying to do, and why), more manageable (we can change the way things happen by updating the story appropriately) and far less susceptible to the inclusion of arbitrary “busy work” (rules for the sake of rules).

Again, one of the challenges to accepting this approach is that it seems too simple. But contrast the story above to something like:

Students are expected to return from the washroom to their desks and complete their lunchtime routine in a self-directed manner.

Try explaining that to a 7 year-old.

I’m not ready to drink the storytelling Kool-Aid yet, but these two examples of how storytelling can be used for Good, completely devoid of both bow-ties and bodhráns, are starting to win me over. Talk to me in six months and I’ll likely be invoking Rhymes of a Rolling Stone at the drop of a hat.