Storytelling is the conveying of events in words, images, and sounds, often by improvisation or embellishment. Stories or narratives have been shared in every culture as a means of entertainment, education, cultural preservation, and to instill moral values. Crucial elements of stories and storytelling include plot, characters, and narrative point of view. (http://en.wikipedia.org/wiki/Storytelling)
To reach valuable solutions in software development you shouldn’t be the best requirement writer. Instead you should be a good storyteller. Why? Follow me…
One of the good point in storytelling is that it puts everything in context. I was listening Coplien in Tampere Talo during 2012 spring. His point was that user stories are not good enough as stand alone “requirements”. User stories are missing context.
Storytelling goes from beginning to end. From describing the initial “system” through changes to the happy end (or sometimes not happy end). All of this will set context for user stories. It will tell how small requirements will change the whole system.
Context sets the final value which system will got from the change. Beginning end in mind makes sure that every steps takes the team toward the right goal.
So we understand that context is important. But for who it’s important?
Poppendieck wrote about decision making. I specially remember a Marine team. In the team decision making is given to the front people. Why? Because complex problems can be dealt only on the front line. Poppendieck wrote about a study which result was that when front people are solving complex problems they will do less mistakes than distant officers.
Poppendieck continued that in the Marines planning process focuses on understanding. This way the team can understand boundaries, simplifying assumptions, alternate approaches and strengths and weaknesses. They can do fast decisions when a mission is going on and act based on that.
Same way as you dig in to the source code and find out what really is going on in the function level. You find out what are real reasonable ways to solve customer problems. You can do best decisions if you have understood the problem and the context.
If you don’t understand the problem and find that some of the manager assumptions were wrong then you have two options: Call in manager for new decision making or do some guessing. Call in will take time and stops whatever you are doing and puts the task on hold. You need to get back to it later instead solving it right away. About guessing… well it’s guessing.
But how to emphasize understanding? As when setting context for requirements you can continue storytelling to help people to understand.
Tell about the users and the customer. Tell what kind of problem customer has and why it happens. Tell about the environment. Tell also about how customer now survives and which kind of consequences she is having. Tell about boundaries. Then move to the time after problem is solved.
Again highlight the value which customer or user gets after problems is solved. Also go through possible solutions which are discussed with the customer. List down pros and cons from different alternatives. That’s way to emphasize understanding.
Isn’t that just creating a good vision for a project?
With good storytelling you can visualize the context, the problem and the solution to other people’s minds. You can make them feel sad and happy.
The storytelling is what you need to do if you want people to stand in customer shoes. To feel the problems. Somebody once said that if you can’t visualize it, you can’t understand it.
So if you already write the vision for your project or product development, check that it’s not boring. Make it interesting.
The storytelling has many advantages. With the storytelling you can
- Add context to the requirements
- Create a clear vision about what happens when the problem is solved
- Help front people to make better decisions
- Have possibility to feel and stand in the customer shoes
How to find time for the storytelling? In previous post we had unhappy developer Cole. His project started with punch of the detailed requirements. At the beginning of the project Consultant should have been considered to replace most of the requirement details with storytelling. That would have helped Cole to do better decision.
My conclusion is that the requirement writers needs to learn to be good storytellers. The storytellers will put some drama, make people sad and happy. More better story you tell more better it’s remembered.