What’s wrong with technical tutorials

I’ve been diving into a few new technologies recently, and I’ve been heading to Google to find tutorials and documentation to help me out.
I was describing my frustration with the way these tend to be written to my colleagues. A typical example is the “Do something with x in 20 minutes” tutorial. For Ruby on Rails, it’s writing a blog engine, and for Angular, it’s a to-do list.
These are great for showcasing techniques that overcome the itches that they were written to scratch, but they don’t explain what those original itches were.
It’s a bit like being taught to parallel park, and your instructor saying “This car has power steering. Power steering makes everything easier. See how quickly and easily I can turn the steering wheel, even though I’m not moving. Power steering is the best technology ever”. For people who know how to park, and know how hard it is to turn a non-powered steering wheel while stopped, this kind of information is great; but for people who are there to learn how to park, it doesn’t give them any of the information they need to know about how to park, why they’d want to parallel park or that there might be other parking alternatives.
These newbies might stumble across a method for parallel parking, but they attribute it to the power steering because that’s what their tutor was raving on about during their lessons. When faced with a new problem, they might then say “What we need now is power-gearing, or power-acceleration” and end up using the wrong tool for the wrong job because they never understood the motivation behind the right tool.

Soap Opera Personas

Teams often use personas to help them identify their users and the types of actions they’ll perform. This is usually a workshop exercise that will last many hours and identify 5-10 key characters with a few paragraphs of history and motivation.
I find that these personas tend to get forgotten and that user stories are still written “As a Customer” or “As a Customer Service Agent”.
I’ve been recommending that my teams use a method I call “Soap Opera Personas”. In TV soap operas, we don’t get a big introduction to the characters at the beginning of the episode; we get thrown in at the deep end and we learn about the characters as they go about their daily lives. For persona writing, this means that we can avoid the workshop exercise and start with very basic characters.
Take “Carl, the Customer Service Agent”. As we start to define stories, we write them “As Carl” and bit by bit, we get to learn a little bit about him. For the first few stories, we might not need any other characters. As the project progresses, we might find a few behaviours that seem outside of Carl’s usual routine. If someone suggests a feature that requires setting accelerator keys so that keyboard users are more effective, we can introduce “Kevin, the keyboarding CSA”. When we need to have reporting and administration functions, we can introduce “Sharon the Supervisor”.

This might seem a little cute, but it has immense power. Security features can now be tested by having Carl try to do something that only Sharon is permitted to do. The team can push back on features that seem at odds with the stories they’ve built so far; “This feature is labelled as a Sharon feature, but it seems more like something that Kevin and Carl would be doing day-to-day. Is there a reason for that?”
It gives the team something to identify with. Just as somebody can jump into a soap opera at any point, and infer the backstory; new team members absorb the characters as they listen to discussions during planning or story writing. It enriches the experience and gives another dimension for people to ask questions.
In soap operas, characters sometimes suddenly reveal a secret history; Phil is in witness protection from the Mafia. As long as the revelation doesn’t completely invalidate the character we’ve come to know, we’re happy to accept it. Our personas can also cope with significant changes when key aspects of the project change, allowing stories and automated acceptance criteria written in this style to adapt as the project progresses.

Like with all good characters, once you get to know them well, the stories write themselves.