Storytelling is one of the most powerful tools SAP consultants have for reducing the number of iterations project teams must go through to give users what they want.
Agile developers have long recognized the importance of stories. The most obvious reason is time. If you’re going to develop a useful deliverable every three weeks for the customer to evaluate you simply don’t have time to write a functional design specification first and have the customer review it. That would take longer than the actual code itself.
But there is an even more important reason agile developers like stories. Stories do a more effective job of communicating user requirements than do functional design specs. Stories are about outcomes — the “happy endings” that the customer wants the software to achieve — not technical implementation details that need to be accomplished along the way.
Here is an example:
“As a regional manager, I want to see order numbers of any delayed merchandise so I can work with suppliers and shippers to expedite delivery.”
Knowing those outcomes should be enough. Consultants should then be able to figure out the technical implementation details on their own — either that or know enough to ask good questions so they can fill in the technical details. Without the story, the consultant would not know what questions to ask — since they’re not in the customer’s business. And customers would not know what technical details to suggest — since they’re probably not in the software business. In other words, neither side knows what they don’t know. So the story tells them.
Storytelling Whiteboard Sessions
With the story, the technical details — and by extension the functional design specification — is secondary. What matters is that the user in such-and-such role can do such-and-such an action with the system in order to achieve such-and-such a benefit. Are there technical considerations that could impact how that story could (or could not) happen? Great, then let’s bring those up to the customer as part of a storytelling whiteboard session. That way we can revise the story ahead of time, if need be, rather than wait until we show finished code to the customer and possibly have to rewrite it.
And it’s not just what information the story conveys that makes stories more effective than functional design specifications. It’s also how they convey that information. Stories are told in the customer’s own words — so customers are more likely too related to them emotionally. Seeing yourself as the hero of your own story has an impact that a list of design specifications cannot possibly compete with.
Stories are also more emotionally engaging simply by virtue of being stories. It is for emotional engagement that people are driven to want to consume stories. If they simply wanted the facts audiences would just read the synopsis or watch the trailer.
Storytelling Helps Agile Be Lean
Another way storytelling promotes agile development is by being lean — it helps consultants practice a lean production methodology. Consider three key lean principles — value streams, kaizen, and design by exception. Value streams describe a customer journey as in order-to-cash or demand-to-supply and are therefore much more story-oriented than they are about discrete functional silos (i.e., SAP modules) that the user may need to traverse to complete those journeys. So by telling stories consultants take a head start in mapping their customers’ requirements to value streams.
Kaizen is the principle of continually eliminating waste from production workflows so that over time the workflow becomes almost flawless. Design by exception means working on the code that truly makes a difference while reusing the 80-90% that doesn’t. Taken together, kaizen and design by exception focus developers’ attention on the key plot points of the story — the key issues they must resolve so the customer’s journey is successful — so the ending is indeed happy. Without the story there would be no value stream. And without kaizen and design by exception a lot of consultant activity would be squandered on activities that don’t advance the story — in other words, on the very back and forth that a lot of agile developers and their customers hate.
At the end of the day, of course, happy project endings are not about a particular methodology (agile, lean, or otherwise) just as they are not about a particular technical design. They are about exceeding the customer’s expectations for the software they are going to receive. But when you do commit to an agile process focused on implementing value streams instead of modules, you realize the best way to capture those expectations is by telling a story.
Want to know more about how storytelling empowers SAP projects? Download my white paper, “SAP Consultants Must Tell Stories Too.”