I can hardly express how important I consider communication to be for software development. In every bug you fix you will find some failed communication if you dig for reasons.
This Blog proposes improvements for the heart of Scrum's Common Sense and the foundation of Domain-Driven Design's Ubiquitous Language: communication.
Equip your developers with laptops. It is hard to believe how this raises quality of communication. Just because a developer can take the laptop from the docking station, go 5 meters to the table of a colleague and help to find out something. Internet connection comes through WIFI. Both can look at the screen of each other while investigating. Remember that a developer is not complete without his/her computer, so mobility is an asset.
Other scenarios are meetings like planning and review. At any point in time, any attendee can connect his/her laptop to the beamer and explain his/her different point of view by showing some documentations or diagrams, and this will be understood much better than just spoken language.
How many meetings with too many people in front of a too small monitor with a too small font did we cancel because our heads were crashing? Magnifying the screen to a wall where everybody can see it is a great idea.
You can reach many people when you use one of these short-distance LED beamers, they are not bigger than a book any more. Even when people can not follow your talk they could read the page you are showing meanwhile. Using a magnified computer screen makes communication unbelievably easy and efficient.
Put some beamers into the rooms where developers reside (and make the beamer manuals available). Topics that normally are hard to talk about will become accessible.
There is another question, but - you're already gone. So I want to send you a message about it, instantly, because I could forget this later. Answer it whenever you like.
Mails mostly are read just once a day. From my experience, instant messaging doesn't make our lives much more complicated. It pays off even when just a few people use it. It's a nice-to-have opportunity. Don't make a duty out of it.
Everything that is done on the software product should have its reflection in an issue tracker. That way nothing remains undocumented, features have a specification, bugs have an explanation, improvements have a cause. Issue trackers hold
of the software product. References to issues should be written into the source code, especially when fixing bugs. Issue tracker contents should be saved together with the source.
Introducing an issue tracker to a team is not an easy task. You need written conventions and rules how to do titles and descriptions, and especially when and why to write comments, e.g. for collaborative investigations.
> Was this about login, logging, or locking?
Spoken words are hard to assign sometimes. Their written representation may look quite clear, but just the one that speaks sees it written before the inner eye.
Words are the atoms of communication. There must be common sense about every business-term in the team. Maintaining a project glossary really pays off, although nobody may explicitly notice it.
Presentations are the most important part of team communication. Developers should be used to do presentations regularly. Here are some mistakes that I observe over and over again, and they don't die out.
And last not least, as this list has become too long, I recommend to make short lists not longer than 7 items :-)
ɔ⃝ Fritz Ritzberger, 2019-03-23