How to understand what others (really) understand?

The process of transferring an idea into working software in collaboration with others is full of pitfalls. One of them is the possibility of communication falling short which leads to confusion, risk of doing The Wrong Thing and heaps of frustration.

“The greatest obstacle to discovery is not ignorance — it is the illusion of knowledge.”
– Daniel J. Boorstin

One way to increase the chances of getting all team members to become aligned around The Right Thing is to create graphic models together. In this blog post, I will describe two different ways of doing this by giving examples of situations where I have seen it been done successfully.

How to test an idea?

Here is a game I think many played in kindergarten

The same phenomena can be observed every day among fully functional and well-educated adults that are trying to co-create something of value. Misunderstandings and hidden assumptions are the cause of much woe and sorrow in the world of software development.

Dan Ashby wrote a wonderful blog post about testing in a devops context, check it out

Please observe the expanding animated cloud of testable things. How do you go about testing all those things? How do you test an idea for example?

Let me give you one example:

Two developers and a tester has gotten a request for change specification to read and ponder. Now they are seated in a room with a project manager and are about to discuss different ways to implement a solution and how to test it. After 20 minutes of discussion the developers feel that they have a plan and are ready to finish the meeting. The tester who is new at the job on the other hand feels that he hasn’t fully understood how the system that will be affected by this change works so he asks if they together could draw a model of it. He gets up and starts drawing a map of the system on a white-board. Then he asks the developers to fill in the blanks where he might have missed or misunderstood something. One of the developers starts detailing the finer aspects of the system and how they will be affected by the change. As he is drawing, the other developer remembers another change that was done recently and that they hadn’t thought of during their planning. So she gets up and begins adding new details to the system map. And in the process of co-creating this visual representation of the system the following happens:

  • The tester gets a better understanding about the context and are able to create more relevant test ideas.
  • The project manager realizes the complexity of the upcoming work and can therefore make a more realistic plan for the project.
  • The developers share knowledge and get a common view of the system and how it needs to be changed which reduces the risk of time-consuming re-work.
  • There is a good chance they even might have fun together in the process!

A picture says more than a thousand words!

Another example but now about sharing ideas and new information:

A tester in an agile team has plotted down some test ideas, risks and quality criterias in a mind-map but feels that there might be room for some improvement. So he nudges the developers that sits next to him and ask if she can spare some minutes and take look at the mind-map. Together they spend 10 minutes on going through all the nodes in the mind-map and some of the questions that the tester had gets answered, a few new test ideas are added and other test ideas gets edited.

As the tester starts to explore the new feature, trying out his test ideas and collecting information on how the product behaves he quickly realizes that there are areas that seem more interesting to test than he thought at first. He would like to show his new findings at once but the developer is neck-deep in the code and a gigantic wooden hour-glass on her table signals that she does not want to be disturbed for the next 40 minutes.

So the tester projects his mind map on a wide-screen TV that he has next to his test lab so that anybody that passes him can see in real-time how the mind-map gets altered and what findings he collects. It is like a live monitoring of the on-going testing process.

The UX-designer walks by and spots a screen-shot attached to a node in the mind-map and quickly realizes something looks off. The designer and the tester start discussing and begin some impromptu pair-testing. After a while the developer looks up and joins them. The mind-map is revised and information is shared. It is twelve o’clock and all is good in the micro cosmos of this agile team!

A picture says more than a thousand words. Co-creating that picture is like having a clarifying conversation that at the same time gets documented in such a way that it can easily be shared with others. Perhaps one might call it mob drawing or mob modeling?

“All the brilliant people, modeling the same thing, at the same time, in the same space, and on the same white-board.”

Sorry Woody Zuill, I hope you don’t mind me borrowing and tweaking your elegant phrase!

How do you go about understanding what others understand? I’m qurious to know so don’t be a stranger, connect with me 🙂

About the author


David Högberg is a physiotherapist who turned software tester. He likes to think of himself as a guardian of end user satisfaction. But he also believe that the quality of the experience of producing the product is as important as the product itself. He wants to beckon the lovely wherever he works which all begins with forming personal relationships with one another.