I am just about to read the book “7 habits of highly effective people” by Stephen Covey. In the first two chapters I stumbled across an example of how we perceive the world and our paradigms. It is basically about the models in our head and how we see the world compared to how others see it. A good example was the illusion of a young lady and an old woman within the same picture.
Some of you might only see the young lady where others will only see the old woman. This can lead to big arguments and misunderstandings although everyone is looking at the same picture.
While I was reading and identifying the young lady and the old woman I remembered a completely different picture. It was the picture of a polar bear sitting on a floe. I guess everyone knows the picture.
The picture wants to tell us about the melting ice in the arctic and a possible climate change. Almost everyone has got strong feelings for the poor bear.
On the other side not that many people know that polar bears are good swimmers.
In our model of the world or of this story we just see that the poor bear is caught on the floe and can not escape anymore. However he is a good swimmer and possibly could swim to land.
Further learning will tell us that the floes are drifting away from land and the distances are getting too big. Even too big for a polar bear to swim.
Learning and shaping
I can see different steps of learning and changing of our models in this story.
- The poor polar bear is sitting on a floe and can not escape.
- We learn that an ice bear can swim and therefore he is not as poor as he looks like.
- We learn that an ice bear can swim about 100 kilometres.
- We learn that the floes are drifting away from land significantly.
- A polar bear can swim about 100 kilometres but the floes are drifting away more than that.
What I have learned from this story and model-building is that we need more information before we are going to judge a situation or person etc.
Similar situations can be applied to software development teams or teams in general.
People often perceive information in different ways. It depends on their models and views of the world and also their experiences in previous projects. If you ask for instance the status of a project or if there are any problems you will definitely get a lot of different answers. So why not getting information to proof the assumptions and thereby learn to shape the model.
The same can be applied to requirements engineering. Both the customer and the development team look at the same picture (young lady and old woman) but each of them sees it completely different. I have been in planning meetings where everyone agreed on what was talked about but everyone understood it differently.
There are a lot of things to address these issues. One method is Kanban and the visualization of work (How conversations and Kanban visualisations enable process improvement). Another apporach, especially for requirements engineering, for instance is Specification By Example (http://gojko.net/).