Strategy Balancing


Many people think I want people to always sit closely together, just because communication is most effective when they are close. The idea I wish to develop here is

Just because a strategy is good much of the time doesn't mean it is good all of the time.

The point is encoded in the project leadership Declaration of Interdependence (see http://pmdoi.org): "We improve effectiveness and reliability through situationally specific strategies, processes and practices." The cooperative game model serves to remind us that different situations call for different strategies and that different strategies are called for at different moments in the same game (an analogy is chess, with its different opening, mid-game, and end-game strategies; the same applies to projects).

A good set of principles calls for a balancing of forces (this is, to my mind, a basic test of soundness). The principles should show when a method or strategy is too much or not enough for a given situation. It is the balancing of the forces that generates optimal strategies.

Let's look again at the matter of collocation and communication: Communication is most effective when people are face to face, but it is not always the case that "most effective communication" is the top priority.

  • Sometimes we want peace and quiet (see the discussion of drafts in "Convection Currents of Information" in Chapter 3). Sound barriers help create peace and quiet.

  • Sometimes we want time to think or to run a conversation when we are not all present at the same time. Asynchronous mechanisms such as voice-mail, email, and text messaging serve well here.

  • Sometimes we want to be able to study an idea at our leisure, and so we want a written form, perhaps on paper, so that we can study it, think about it overnight, reread it, and mark it up.

  • Sometimes we want to dilute a particular person's overly strong personality. In this situation we prefer a less-rich communication technology such as the telephone (I have been told stories of people who deliberately use the phone with their bosses for just this reason).

The principles plus your priorities help you to create an optimal balance for the situation. For example, when setting up your office, balance Osmotic Communication against "drafts" to get a space that works for you.

As a larger example, here are two opposing strategies created from the same principle. Watch how the strategies can be combined in interesting ways.

The strategy of Osmotic Communication (Chapter 3) suggests that people who need to communicate a lot should sit so they overhear each other in their background hearing. They learn who knows what and which issues are current. They can respond very quickly to the information flow around them. The Expert in Ear-shot strategy (Cockburn 2001a) applies Osmotic Communication to professional education.

The opposite strategy is the Cone of Silence[1] (Cockburn 2003b). In that strategy, one or more people are sequestered away from everyone else for the sole purpose of avoiding communication.

[1] The name of this serious strategy playfully parodies the gadget of the same name from the 1960s spy sitcom Get Smart. There is no connection between the two except a sense of humor.

How can the Cone of Silence possibly be useful? The situation that clarified the matter for me was a project in which the technical lead was supposed to do the most difficult programming, educate all the people around him, and sit in meetings to plan future extensions to the system. He never had quiet time to do his own work. The project was falling farther and farther behind schedule.

After trying several other strategies unsuccessfully (including asking his manager and colleagues to stop pestering him), we used the Bus-Length Communication Principle to try one last-ditch strategy.

Bus-Length Communication Principle: Communication between people drops off radically as soon as their (walking) distance from each other exceeds the length of a school bus.

(What is interesting as a side topic is that we were so attached to the strategy of Osmotic Communication that this was our last thought for fixing the problem!)

The Bus-Length Communication Principle is nothing more than a mnemonic restatement of what researchers have found and even graphed (Allen 1984, Olson 2001). However, until facing that particular situation, I had always interpreted the research and that principle to mean "Put people closer together." I had always wanted more communication. In the project at hand, however, we wanted the opposite effect; we wanted people to stop disturbing the technical lead. So we found him an office upstairs, at the far end of the rather large building, around many corners, certainly farther away than the length of a school bus.

The result was nothing short of remarkable. Exactly according to the principle, people stopped bothering him. He found the time and peace of mind to program at full speed, and within a couple months the project went from being impossibly behind schedule to ahead of schedule.

(An additional topic to consider is another strategy in play here: Give the best programmer time, peace, and quiet, and that person can sometimes get astonishing amounts programmed in a remarkably short time. But that is a different strategy with different boundary conditions.)

Having seen the Cone of Silence succeed, I suddenly started noticing its application in many places (Cockburn 2003b). One example was when IBM wanted to enter the PC businessthey located the PC development team away from any IBM development laboratory so that the team would not be disturbed. Another example is the fairly common strategy to send a group to an off-site location for a weekend (or week) to get a lot accomplished in a short time.

The Cone of Silence and Osmotic Communication are two diametrically opposed applications of the Bus-Length Communication Principle. They can be used together, in alternation, or one inside the other.

Putting a team off-site in a war room setting is applying the Cone of Silence to the team with respect to its external connections and Osmotic Communication within the team. In the project just described, we used Osmotic Communication within the project team, and only the technical lead occupied the Cone of Silence.

Strategy balancing should be used when arranging office furniture. As more people gather, their conversations become less relevant to each other. At some point, it becomes better to separate them than to cluster them. Many would-be agile developers forget this. They fill a space with more and more people, but then those people become depressed because the noise gives them headaches and because they get less work done.

Balance the strategies. Decide when the group size becomes too large, and then decide where Osmotic Communication is useful and where it is not.

Every strategy has built-in limitations. For Osmotic Communication, the first limitation is that optimal seating will change over time. At some point, you must decide whether to leave the now-suboptimal seating in place or to disturb people by rearranging the seating.

Its second limitation is that Osmotic Communication is difficult to arrange when people are working on several projects at one time. The immediate strategy to apply in this situation, of course, is to rearrange the project staffing and time allocations so that people aren't working on many projects at once (this strategy has been heavily studied; see Goldratt 1997 and Anderson 2003, for example). When you do this, you are likely to run into the next problem, which is that people have become too specialized.

The principles, problems, and strategies link one to another. Use of a strategy introduces a new problem, which requires a new strategy. Sooner or later, you choose one principle or strategy as dominating the situation and driving the rest.

As a starter suggestion, do whatever it takes to let people work on one or at most two projects, but no more. Serialize the projects and apply Osmotic Communication as practical. Balance the strategies and principles from that starting point. In all cases, balance your strategies according to their boundary conditions.



Agile Software Development. The Cooperative Game
Agile Software Development: The Cooperative Game (2nd Edition)
ISBN: 0321482751
EAN: 2147483647
Year: 2004
Pages: 126

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net