Stone Fish - About the Importance of Storytelling

My son, Tim, is four years old. The daycare center where he spends his days are only a couple of minutes walk from where we live. (Tim, he wrote his own name here, says Hello! He is sitting beside me as I write this.)

Walking home is different, it often takes more than an hour. We go for walks, stop to play, investigate things... One day a couple of weeks ago we went past the sculptures you can see here, and Tim wanted to take a closer look:

As we got closer, I began asking Tim questions about the sculptures: "What does this one look like?"
"It's a bear holding a fish," Tim said. We often play little games together, rhyming games, we weave stories, play scenes from favorite movies, sing songs. Since Tim was interested in the sculptures I decided to take the opportunity:

"OK, what is this then?"
"Fish."
"And where are they?"
"The sea."
"OK, the sea, or maybe a river." I think I made a misstep there. Shouldn't have corrected him.

I then asked him about the other bears that you can see in the first picture. Tim said they were a mummy bear and two baby bears. I asked him what they were doing. Waiting for Daddy bear to catch fish for them, he said.

I then asked him what the bears had been doing before they came to the river to catch fish. Together we wove a story about a bear family that woke up from their long winter sleep. They were hungry and went to catch some fish.

We continued on our way, still talking about the bears. Right outside our home there is a small rocky hill with some trees. We went up to see if we could find anything interesting. If nothing else, we can get a good view of where we live from up there.


It didn't take Tim long to find something interesting. "Look, a fish," he said and pointed to this:


Yep, unmistakably fish shaped.

The point of the story is that the story Tim and I created together had primed us both to think about bears and fish. When Tim saw something even vaguely fish shaped, he recognized it.

Stories do the same thing for us in all walks of life: when we work, when we are with our families and friends, when we pursue our interests.

Stories create patterns in our minds. We then use pattern recognition to identify other things that fit the same pattern. We can use this to identify problems, and to figure out solutions. Patterns are also an excellent way of communicating with other people. If we can recognize and use the same patterns, we have a basis for understanding each other.

As a management consultant I am obviously interested in the power of patterns, for example: Systems Archetypes from Systems Thinking, or strategy patterns like the Chinese 36 Stratagems. Lean and TOC do of course also have patterns for identifying and solving problems.

One of the book ideas I have is a pattern book. It might not be the next one I write, but I will write it. Until then, I'll write about some useful patterns in this blog, and maybe in the Tempo! newsletter.

Comments

Post a Comment

Popular posts from this blog

Waterfall vs. Agile: Battle of the Dunces or A Race to the Bottom?

Image
The major software methodology wars since the mid 1950’s. Someone was wrong on the Internet, so here we go… In a recent HBR article, It’s Time to End the Battle Between Waterfall and Agile , the author sets up a false premise: There is a war between Waterfall methodology and Agile. The war must end. And finally, you can combine the approaches to get the best of both worlds. This sounds good, but the article is based on a misunderstanding of both Waterfall and Agile. Also, there is no war between Waterfall methodology and Agile. There can’t be, because Waterfall methodology does not exist! Waterfall is a name for large projects that failed in the 1960’s. Waterfall was never a methodology, but a failure to apply the methodologies that existed back then. As I will show towards the end of this article, at least one of the “successful” Waterfall projects mentioned in the HBR article was neither successful, nor a Waterfall project. I got invaluable help from Alistair Cockburn. He fact che...
Read more

Performance Evaluations, Business Strategy, and Agile Methodologies

Image
It is performance evaluation time in many companies. This can be stressful, both to the people being evaluated, and the people doing the evaluation. In companies adopting agile software development methods, the tension can be extraordinary. Individual performance evaluations run counter to agile philosophy, which emphasizes team performance over individual performance. However, managers and corporate leaders need to take a few steps back, and consider the impact performance evaluations have on the organization as a whole. Especially now, in the midst of a recession, it is important to look at a companies current policies to see if they can be improved, or if they are actually holding the company back. So, how can a manager evaluate policy? Performance evaluation policies can serve as an excellent example. I'll confine myself to discussing the so-called ‘rank and yank’ methods. These are performance reviews were employees are ranked using a forced ranking system. It usually looks so...
Read more

Agile Requirements Structures, Part 1

Image
If you have worked in large Agile projects or programs, you may have noticed that there is often quite a bit of confusion about requirements, what the requirement types are, their purpose, how to write them, how to use them, and above all, what not to do with them. There are many causes for this confusion. Here are some of the more common I have seen: Nobody in the organization has read up on the requirements model it is using, so everyone makes their own interpretation. The organization deviates from a standard requirements model, but nobody knows which standard model the organization is deviating from, and/or there is no agreement about how they deviate from it. The organization has not documented its own requirements model very well. The organization mixes two or more different requirements models, often without realizing it. The organization has documented its requirements model, but finding the documentation is an epic project in itself, on par with when Henry Sta...
Read more