In software projects, it’s hard to coordinate and communicate effectively. This should come as no surprise to anyone developing software for a living, yet it bears repeating because it’s one of the main motivations for adopting the Shared Understanding paradigm that I discussed in my previous post of this series.
The fact that coordination and communication are hard is well established. There seem to be at least three factors that make it difficult:
- An abundance of information (and a scarcity of attention)
- Lots of tacit knowledge that is very hard to externalize, but that still needs to be communicated somehow
- An exploratory or creative aspect to the project (so that there are no clear answers, and probably no clear goals either)
So, too much information to parse, knowledge too complex to make explicit, and questions for which we don’t yet know the answers, or which we don’t yet know exist. Whenever these factors hold (and I argue they hold for a very significant chunk of software projects; certainly for every project I studied), we won’t be able to coordinate and communicate effectively with a simple transfer of information—we’ll need a deeper understanding of the project’s situations, and that understanding needs to be shared by everyone involved in them. In my next post I’ll discuss how (I think) we can reach that state of shared understanding more easily.