Humans are born with the ability and need to communicate. Their vocabulary initially consists of various types of crying: an empty belly, a wet bottom, cold feet, being tired etc. This vocabulary grows with age to include words, expressions and even writing.
By the time our baby is a productive member of a software development team, they probably have a couple of decades of experience in communicating under their belt. Unfortunately, this experience does not always translate to effective communication, especially for software development work.
What works well at the bar and other social situations does not work our as well in the development process.
In this entry, we will be looking at some of the steps you can take to make communication within your teams more effective.
In government or at least as it is portrayed by Hollywood, they have a term “Need to know”. It describes data that is deemed to be very sensitive. Access to this information is restricted even for those with all necessary security clearance.
Somehow this mentality has seeped into how we do normal business. With the business people sharing only information that they think the developers need to build the product and developers only sharing what they think the client can understand and appreciate.
This insidious practice slowly erodes the trust that the team needs to communicate effectively. After all, how do you know if what you are hearing is all that there is or the other person is withholding something?
It is not enough to ensure that all information is shared, it’s equally important to give everyone a chance to participate in decision-making and the creation of new information. As humans, we naturally own decisions that we feel we had a part in making. This ownership leads to greater contributions of energy to the work being done.
This does not mean that everyone wholly agrees, it is enough that they can live with the decisions made by the group.
Keep the information credible
In the entry Is your backlog still relevant? we mentioned that if you don’t maintain your backlog it will atrophy and eventually be abandoned. This applies to all your other communication tools including documents, spreadsheets and other project management material.
Words are powerful, they give meaning and perspective, yet they only make sense in a context. The words used in your communication materials should be meaningful to all participants. In practice, that means avoid jargon as much as possible.
Eric Evans in his book Domain Driven Design describes ubiquitous language as:
A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.
This simply means that the language that you use should be meaningful within the context of the team.
It may be useful to have a project index describing what the words means especially for highly technical projects.
Keep it fun
By now I have started to gain a reputation as the “processes guy”. I don’t believe this rep adequately represents who I am. Rather, I believe that all we do should have some element of fun in it. If you don’t enjoy the process, no outcome is ever worth it.
This means that while you should respect the formal practices of scrum or whichever project management paradigm that you use, there should also be some room for informal collaboration.
This is what Alistair Cockburn refers to as osmotic communication, the variety of sensory modalities (visual, audio, touch, sense, etc.) that provide a rich set of collaboration clues
Even the ideas that come to the team members when they are not in an official setting should be captured in your project management system. As David Allen usually says:
The Mind Is For Having Ideas, Not Holding Them
So then let your process allow for anyone who has an idea to express it as quickly as possible without having to wait for the next brainstorming session.
How do you communicate with your own team? Talk to me on the comment section below or on my twitter @jchex