Video of my talk at NDC Oslo 2015 on "Don't demo facts. Demo stories!"
The talk I gave at NDC Oslo 2015 on Don’t demo facts. Demo stories! is now available online.
The talk I gave at NDC Oslo 2015 on Don’t demo facts. Demo stories! is now available online.
This year, I will again have the pleasure of going at NDC Oslo 2015. This time I will talk about the demo-driven approach and the importance of storytelling in software engineering.
Here is the abstract of the talk:
Feedback is the central source of agile value. The most effective way to obtain feedback from stakeholders is a demo. That is what reviews are about. If a demo is the means to value, shouldn’t preparing the demo be a significant concern? Shouldn’t the preparation of demos not be left for the last minute? Should it not be part of the definition of done?Good demos engage. But, there is more to a good demo. A good demo tells a story about the system. This means that you can tell the story. And it also means that the system is made to tell that story, too. Not a user story full of facts. A story that makes users want to use the system.
Many things go well when demos come out right. Your system looks different. Stakeholders are in sync. Marketing does not have to lie. And even sales can sell better.
This talk tells stories of successful demos and distills demo-driven lessons from both working in research and in industry. These lessons are meant to be used in every day projects.
A couple of weeks ago, I had the pleasure of giving a one-day course to PhD students on the topic of Demo-driven innovation. The course was organized as a CUSO (Conférence universitaire de Suisse occidentale).
I got to work with highly motivated students and argue my way through the demo-driven philosophy.
We started from debating what innovation is and what role it plays in both research and engineering. We agreed that innovation is less about discovering the fantastic, as it is about revealing the obvious.
Then we tackled the problem of the process of research. Finding a complete process to such a complex problem is difficult, but focusing on the most basic problem is a doable first step. We concluded that the most important research challenge is not the fight against nature, but against our own entrenched assumptions.
The argumentation went on: To fight our own assumptions we have to expose them and get feedback. But, feedback comes only from interested people. And it is hard to get people interested in a subject that is not their own. The most effective way to capture the attention and later on the imagination is through stories.
Not fairy tales. Stories. Stories make facts valuable. They capture attention and spark imagination. And the more palpable they are, the better their impact is. In other words, we should strive to demo our story. Especially in a field such as computer science, making stories palpable is both accessible and beneficial.
When demos tell stories, magic things happen. On the one hand, the audience gets more involved. On the other hand, the very implementation of the demo provides a tremendous feedback. We are syntactic creatures, and the look of ideas matters a great deal to us.
And no, there is no such thing as an un-demoable topic.
The review session in a Scrum project is a place where both the team and the stakeholders come together to assess the current state of the project and to figure out what is left to do. On the one hand, this is important for stakeholders to get in touch with their investment. On the other hand, it is equally important for identifying possible problems or opportunities.
Most sessions I saw tend to go like this. The Scrum Master starts the session by enumerating the stories in the backlog. He takes the first story, and the concerned developers start to demonstrate the progress. They explain the story, and this explanation typically boils down to saying that the story requested that if "you click here, you should get that." Then they start the program, get to the point relevant for the story, and say "you click here, you get that." Everyone is happy, and the next developers take the stage to demonstrate the next story. And so it repeats until all stories are done.
This approach limits the review to facts stating. "You click here, you get that" is just a fact, and facts are never exciting. Facts get exciting when they are surrounded by a story that is relevant for the current context.
It is for this reason that many review sessions fail to incite the audience, and as a consequence, they generate little feedback. Often stakeholders have to switch from their typical activities to participate in this meeting. They might remember little from the last review they visited, and as a consequence they feel rather remote when someone is showing some details inside the product. They need context to get involved. It’s in everyone’s interest for stakeholders to bring their energy and generate feedback.
To turn the problem around, go beyond the click. Tell them a story for why the story is important. Build a little tension. Make them want it. Then give it to them. Something as simple as "In our context, it would be beneficial to get that. Would it not be great if we could just click here, and we would get that?" can do miracles with the energy in the room.
This exercise goes hand in hand with the ideas behind impact mapping. The more you emphasize the big picture and how it reflects in the actual software solution, the more everyone’s understanding is aligned, and the more chances you get to uncover traps or opportunities.
Storytelling is a skill that can be built over time. You just have to want it.
Moose is an extensive platform for software and data analysis. To make it easier to digest, I will start complementing the book I am writing at themoosebook.org with a series of online demos.
Today we start with a short demo of how to play with the basic interface of Moose to find out which interfaces has only one implementor.
The scenario is quite simple. We first select all the types. From these we select the interfaces using each isInterface. Afterwards we select those interfaces that have only one subclass by using each subclassHiearchy size = 1.