Thoughts On Our Natural Inability to Communicate Well
Many believe the best way to communicate is face to face. Being able to see the other person allows both communication partners to read each other’s body language and facial expressions. It feels most natural and doesn’t require additional effort, as that’s the form of communication we humans have been used to ever since.
In fact for almost all beings on planet Earth being within close range to each other when communicating is the only form possible. All those beings need to either see, hear or smell their communication partners. All, but humans. Humans have evolved into a species that can leverage two new forms of communication: one is sophisticated verbal communication and the other is communication through symbols.
Throughout our existence, we humans have developed thousands of different languages and usually also a corresponding form of scripture that allows us to record information, share and transmit it or get back to it at a later time. Being able to perform these activities has allowed us to evolve even further mentally and create complex societies and tools.
But why is it so difficult for us to communicate well with only the written word? Isn’t it that the same written word has allowed us to get to where we are now?
Maybe it is because not all of us possess the same skill to read and process the written word?
There is an activity that teaches us the skill to read and process the written word. It is called interpreting literature. The mechanics of this activity can be visualized as in the following diagram.
As the reader I will understand any text from within my own context. Context is the combination of my work/life situation, my education, my acquired believes, my skill of reading in a given language (the language of the text) and whatever else has influence on my understanding of what I read. For the writer there is also his own context and when he writes a text there is the context of the moment when the text is written.
The simpler and the shorter a text is, the less information about its context can be revealed to the reader. Think about Twitter messages. They are limited to 140 characters. People send them out of a situation at work, when they had a thought while walking or talking to a friend or something else. My, limited, observation is that people do take into account that limited context and don’t get into arguments because they understand that they can’t understand well what the person says. So they, when in doubt, assume the best.
In the case of email we don’t have that limitation. We can write very long texts and it may take an hour to write a meaningful email that not only transports what we want to say but also enough context so that the recipient understands why we write and what our situation was.
The challenge now becomes one of reading. Given the writer is good at expressing complex thoughts in a concise manner, if the reader just skims over the text due to time constraints or isn’t really willing to read thoroughly, we have a communication breakdown despite all good intentions and effort. It’s the context of the reader that becomes an impediment to working communication.
I feel that written communication only works when the communication partners are willing to invest and keep an open mind. In the case of literature the writer just puts the text out for anyone interested to read. It’s more a broadcast model. Writer and reader don’t have a tight relationship so there is not much harm being done, if the reader doesn’t understand the text as indented. However, in a work context, a lot of harm is being done when writer and reader don’t understand each other.
We can mitigate the negative effects of our natural inability to communicate well or we can invest into an improvement of our communication skills.
The prevalent recommendation to work within co-located teams to enable face to face communication is such a mitigation strategy. It creates a multi-channel situation for all communication partners but as soon as some leave the room and start relying on less channels the problems show up again.
Agile software development practitioners have shown us many good techniques to create high quality software. Once we start to use the agile mindset outside of software development teams we will need to solve the communication problem.
Software teams can share working software with the rest of the organization. For example, one team can share a library with other teams and the library is their product. They can send an ambassador with the code to the other team for a while to carry the context of the text to their colleagues.
What about when the product is something else than software?
I was just saying ambassador. I’ve seen some thoughts about a lattice organization where each group within the lattice shares a member with neighboring groups.
Difference Between a Mindset and a Process
When coaching, I frequently make this observation. People want to receive instructions about how to do something and then move on. “Tell me what to do” is the question in their mind. When I respond to their request by explaining why they should do something, I start to loose their interest. There is really no difference between a regular team member and their manager. But it seems to correlate with the culture of their organizations.
These people are interested in being shown and taught a process. First you do this, then you continue with that and finally you check that and if it’s right, then you continue here. They like a linear and predictable way of doing things. Show up for work, do the things you have to do and leave.
A while ago I read somewhere that our human brain likes linear processes. First you get hungry, then you find food by doing all these steps and then you will feel happy. If that’s the case, then these people act perfectly normal.
But then creating things – and that includes software – is so much more than finding food or shuffling information from desk to desk. It is an entirely creative activity in which there is no clear separation between right or wrong. There are many wrong ways of doing it but also many right ways of doing it. So knowing and understanding why someone is doing it in a specific way seems to be important. Important because that knowledge may guide you to further learn in the direction of that person or someone else.
What I just called ‘learn in the direction’ is a complicated and probably entirely wrong way of calling this a ‘mindset’.
A mindset is not a belief. It has to do with assumptions and with a point of view. In German there is the term “Weltanschauung”. It means how someone views the world, which is a general philosophy of understanding the world based on assumptions and cultural background.
Something like “Agile” as expressed in the Agile Manifesto is clearly a mindset. It also is a preference. By saying “Individuals and interactions over processes and tools” the speaker makes it clear that he prefers one thing over the other and on request will explain why he does. He will likely not accept the opposite until you convince him that the other provides more benefit.
A mindset is based on experience and teaching. A process is purely based on teaching. You cannot successfully follow a mindset because someone taught you the rules but you can successfully follow a process after being taught the rules.
Acquiring a mindset requires to understand the Why of all the things the other carriers of said mindset do. In the case of a process understanding why you do something is not really important. You can still use it and be successful.
A mindset will grow stronger and become more and you will defend it more and more once you make enough positive experiences of applying it. That is when a mindset starts to morph into a belief. A process is easily abandoned. After all it is just a bunch of rules to follow and after changing employers you can quickly learn to deal with a new set of rules.
“Agile” – with uppercase A – can be a process. It can be working in iterations with all the ceremony before and after. It can be the XP flavor with things like TDD. Or something else that people have come up with. “agile” with lowercase A – is – just by looking at the word itself – an attribute.
“Being agile” is different from “doing Agile”.
By being agile I am able to react to change easily without loosing my balance. I can do this because I have solid grounding due to my experience in my profession. I have my preferences for how I do things and what I use to perform my work based on experience. I want to know for whom I do something because I want to tailor what I do towards that person. My agile mindset defines who I am, what I do and how I do it.
Why Developers Don’t Want to Write Tests First
This is an experimental attempt to finding an explanation of why programmers don’t want to write tests first using Activity Theory.
The programmer is the subject and writing tests is the object. The outcome of this activity is well tested software.
According to Activity Theory there are rules, community, the division of labor, as well as the mediating artifacts that influence an activity. They themselves, are also influenced by the activity.
Let’s go through rules, community and division of labor first.
If there are no rules in place that demand writing tests, then nobody is being forced to do it. In the case of an organization with a traditional test approach (QA after the fact) there might be a rule that requires the team to deliver something that works or else the team will get back a report with a huge number of defects from the QA people. The rule may come in the form of bad performance reports or similar. If that’s the case, then there would be an incentive to writing tests to prevent defects.
In the case of the organization with the traditional test approach the community within the organization does not promote writing tests first. There may be a few people here and there but the community at large does not do it. So there is no good example for doing it. “Others don’t, why should I?” may be the question some programmers ask themselves in silence.
A huge influencer is the existing way of how labor is divided within the organization. If there are strongly separated groups and membership in these groups is static – based on job description -, then a programmer will not want to do the job of testers. He may be actively prevented from doing someone else’s job. In an extreme case he may do work outside of his job description and, who knows, could be accused of violating his work contract. How far this goes is also dependent on the rules and the community factors within the organization.
The fourth element that influences subject and object and is influenced by them is the mediating artifact. For a programmer this refers to the tools he uses to perform his work but also to things like the runtime environment or where software gets deployed too. Things like the version control system, how a build runs, etc. – all that is a mediating artefact. It’s basically everything that he uses to make software. Those artifacts are also influenced by the community within the organization and what is being used to make software does shape the community.
If at some point important decisions about tools were made and those tools don’t make testing easy, then a community will have evolved where testing first is seen as too difficult and not worth to pursue. A change of those tools might be very difficult, because the community is heavily invested into those tools, as the tools have influence onto rules and the division of labor within the organization.
I will stop here exploring this any further, as this is meant only as a little experiment. However, I hope that it shows how Activity Theory can be used to explain observed behavior. I believe that it can further be used to identify those factors that stand most in the way of making changes that allow the desired activity to happen.
As Activity Theory also takes into account for which reason, the motive, people perform an activity and helps to identify goal-based actions that contribute to the activity, there seems to be another handle for change.
