bookexcerpt

An Excerpt from Journey of the Software Professional

The following is an excerpt from Chapter 10, Communication. It is addressed primarily to managers, and describes how they should strive to structure a communication topology based on the organization topology. In the book, personal anecdotes are offset from the text in an italicized font. Because italicized fonts can be difficult to read on-line, I have chosen to use normal font, but in a smaller point size. Finally, please note that this excerpt is from the draft of the book. Grammatical corrections have been made in the final copy, but this will provide you with enough detail to make it useful.

I intend to update this page every few weeks, so you will likely catch different excerpts from the book at different times.

Choose the communication topology based on the organization topology. Examining the flow of communication—who communicates with whom, and why—results in a communication topology. Effective organizational topologies support optimal communication topologies. In other words, a good organizational topology encourages communication among the right people in the project by providing natural structures for this communication.

Take advantage of this idea when designing organizational topologies. Beginning with a proposed organizational topology, draw a communication topology minimizing unnecessary communication. Then, work to create this communication topology by assigning tasks people communicate according to the communication topology. Try to assign tasks to the smallest coalition possible, as smaller coalitions communicate more effective. Expect to iterate through this process once or twice. The primary objective is to ensure the right people are communicating about the right problems.

I have used this technique often, and have found it especially helpful when the team is working under a tight deadline. Why? One of the biggest time-wasters on any project is unnecessary communication. By structurally minimizing unnecessary communication the team is more likely to meet the deadline. To illustrate, on one project I was asked to prepare the next version of a system on an extremely tight deadline given five people. As project lead, I was responsible for organizing the team.

At first, I considered a democratic team, with every developer as "equals", but rejected it because four out of five team members were unfamiliar with the implementation language. Their inexperience would create unnecessary and redundant communication. I decided a traditional hierarchy was best, because it offered the best chance to allocate independent tasks and minimize pairwise communication. However, two of the team members were best friends (indeed, one had convinced the other to join the project). These two friends were going to communicate intensely regardless of the project, so I leveraged their friendship and created a single larger task suitable for two people (see Figure 10-3).

Figure 10-3: Organizational and Communication Topology

To further structure communication I created a formal system of scheduled communication. Each subteam submitted weekly status reports into a shared a project repository (both of these are described in greater detail in subsequent sections). Two meetings were scheduled each week: one with each subteam and myself, and one with the entire group (thus, I had five meetings each week, but any one team member had at most two). By carefully structuring the communication of the team, everyone was able to focus on their assignment. The result? The project was completed on time, with 11 out of 12 major system enhancements.

Home lhohmann@acm.org Order Journey of the Software Professional