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.
Use Wireless Laptops
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.
Use Beamers Everywhere
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.
Use Instant Messengers
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.
Use Issue Trackers
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
- knowledge
- history
- specifications
- solution concepts
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.
Use Unambiguous Language
> 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.
Improve Presentation Practices
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.
- When you show a screen, give the audience the time to understand it - this may take longer than you believe!
- Don't scroll up and down all the time
- Avoid using acronyms and abbreviations
- Don't consider scanned hand sketches to be readable, always use computer graphics
- Constantly make sure the audience could follow you
- Talk to all, not just to the first row
- Let discussions happen, they prove that your presentation is useful
- Put your name and creation date into everything you publish
- Don't close the book and take it with you, leave some links where they could recall your presentation
- Make sure the one to teach operates mouse and keyboard, not the teacher
And last not least, as this list has become too long, I recommend to make short lists not longer than 7 items :-)
Keine Kommentare:
Kommentar veröffentlichen