Like most writers of fiction, I spend most of my waking hours in a job where I’m doing something else. In my case, I write user assistance materials for software (yeah, that’s right; I write “Help.”) And since you ask, no; I don’t have a technology background. This is a career I wandered into, under the heading “Life is what happens to you while you’re busy making other plans.” (thank you, John Lennon) I’ve learned by doing; and by listening, watching, reading and asking questions.
There are always new challenges to keep me on my toes. But imagine my surprise when the latest challenge turned out to be an old friend.
The shop I work in is in the process of adopting the popular “Agile” approach to software development. Right now we have a kind of coach in house, to shepherd us through the transition to this new work culture. Since Agile is all about cross-functional collaboration, even I’m included in the training exercises. I’ve been training with the Product Managers, which is great for me because I rely on their documents to do my job.
Last week, our coach introduced us to the “User Story,” a method for looking at the various elements that might be needed in a new piece of software. The User Story is a simple statement of a task that a particular user might want to accomplish. In fact, we were told to make it so simple that we could write it, using a felt-tip marker, on one side of an index card. The other side of the card is for specific features that make it possible to perform the task. The Story stays simple, because it will ultimately be grouped with other Stories to become the “Theme”of the software product.
Experienced project managers and business analysts are more used to looking at either the very big picture or the very very small. Given the practice example of a piece of banking software, my coworkers came up with broad statements like “as a bank customer, I want an online portal so that I can do my banking any time, anywhere” and followed up with long lists (taped to the card) of all the specific buttons and tables that would have to be included for every possible banking experience.
What I wrote was: “I want to move a specific amount of money from savings to checking every month,” and the back of my card had only the details that supported that one activity. The coach was astounded. How had I, the one with no training in gathering software requirements, written such a good User Story the first time out?
Simple. What he calls a User Story, I call a scene. Think of a film. Each individual scene in a film has a specific goal for at least one of the characters. Actually, the same thing applies to narrative fiction as well. Some writers start at the beginning and work straight through to “The End”, but others (and I think we’re in the majority) set down our scenes. And if you’re powering through the idea for a new story, you may very well be jotting down notes for your individual scenes on index cards (or virtual cards).
It turns out software development is learning what artists already know. You work on the small pieces, and the big picture takes shape when you string them together. It’s an approach that works in a lot of areas of life. No one ever listens to artists, but now that technology has taken the idea and blogged it and certified it and meta-tagged it, maybe it’ll spread. So don’t be surprised in the next few years if you start to hear about Agile Government or the Agile Diet. When you do, remember: it’s just another common sense approach to breaking down a problem; and the writers were there first!