LINEBURG


<< . .

 21
( 36)



. . >>

Formalize much of what is often informal
and
put more effort into creating informalisms.
In other words, effective distributed collaboration requires attention to both of these
actions simultaneously. Formalisms are the conventions, structures, and social agreements
that standardize communication.13 By formalizing, we mean that you inspect your
informal work behaviors, and formalize them. Formalisms reduce expensive trial-and-
error that is the basis of our natural coordination. The other side of the coin is to inten-
tionally create informalisms (a truly informal word!). Creating an informalism across
distance means deliberately creating social relationships between distant individuals.
After all, distant collaborators who have some kind of social relationship perform better
on a common project.
In this section, we present eight practical principles of formalisms and informalisms
which appear in Table 8.1 and are described below.

Table 8.1 Formalisms and Informalisms for more effective distributed coordination

Formalisms Create a rhythm of interaction, such as weekly meetings in real-time.
Iterate for synchronization, with frequent deliverables across distance.
Standardize communication protocols.
Build an awareness infrastructure.
Create protocols for acknowledgments and urgency.
Informalisms Create a cohesive team culture by fostering relationships across distance.
Foster interaction via real-time interaction.
Put warmth into cold e-mail by the taking the time to create e-touch.
155 Overcoming distance and time


Eight practical principles

Formalize! Create a rhythm of interaction
Rather than rely only on one-to-one interactions between distant collaborators, managers
need to create a rhythm of high interaction through meetings that synchronize, coordinate,
and create a regular rhythm to the project.14 This is an unusual recommendation since
most management books advise to minimize meetings. Meetings have become so vili¬ed
as to become a humorous clich©. However, in distributed collaboration, meetings between
individuals who are far away are a vital means for bridging the problems of distance.
These meetings force interaction among the distant participants.
These meetings need to be in real time: they should be via telephone, or video,
or web-conferencing. How frequent should these “dreaded” meetings be? The default,
as seasoned managers know, is weekly. But daily meetings may be possible: one
successful Russian“Swiss distributed software project conducted a strict, daily 15-
minute tele-meeting at the beginning of the work day to kick-off the day™s work. This
project stayed synchronized. (This was possible because the sites were two time zones
apart.)

Formalize! Iterate for synchronization
Distributed collaboration needs to formalize frequent synchronizations. By this we
mean setting up work so that there are many small iterations, also called deliverables,
that are sent off from one distant partner to another. Why is this important? Because
nearly all the informal means that we naturally rely on are no longer available over dis-
tance: face-to-face meetings, or spontaneous conversations, such as a quick dialogue in
the hall.
The answer is to iterate frequently. Frequent iteration (synchronization) addresses
fundamental coordination problems of work over distance, and is likely to discover a
problem before it is too late and delays the task at hand. Project managers need to
introduce many small deliverables into the project timeline. The Work Breakdown
Structure,15 used by most project managers, should formalize these frequent iterations.
The right number of iterations is dependent on the context (task, people, and size).
If iterations are too frequent (too granular), they overwhelm those who need to verify
or add to them. But, iterations of once a week should be a minimum frequency to allow
true synchronization between distant partners. In a similar spirit, these iterations are
called “sprints” within the Agile development methodologies, which are described at the
end of this section (and, according to the Agile methodologists, these “sprints” should
certainly be no longer than two weeks).
The deliverable itself may be any work object (complete or incomplete) including:
plans, outlines, prototypes, simulations, design reviews, test results, software code
reviews, module integration, and documents. And, each of these deliverables should have
a prede¬ned recipient and prede¬ned veri¬er.
156 Managerial competency


Formalize! Standardize communication protocols
Most individuals in distributed collaboration groups are inundated with e-mail messages.
Research has validated what we already know,16 that we are distracted and less effective
with the hundreds of telephone, e-mail, and Instant Messaging (IM) messages we receive
daily.17 Disorganized work groups tend to send each other too many messages with too
much super¬‚uous information. Now, more than a decade into the e-mail age, there are
some who ignore e-mail because they have become overwhelmed. Some managers have
gone so far as to ban e-mail.18 Furthermore, in the software development cycle, reliance
on e-mail loses critical design rationale that is buried in personal e-mail folders.
Since e-mail messages lead to information overload, they need to be reduced, stan-
dardized and replaced with work¬‚ow tools and project repositories. The overall goal
should be to migrate most project-related information into repositories and databases
so that the individual can pull them as needed.19 Some of the information ¬‚owing in
e-mail or IM also needs to be captured in these repositories, which is rarely the case
today, since these messages are either stored in personal folders or not stored at all.
Thus, persistent IM (in which all messages are stored) is a partial solution: one that is
beginning to appear in the marketplace.20
Terminology is also part of the communication protocol, and needs to be standardized
and formalized, since teams at different sites inevitably have their own interpretations for
what things mean. Therefore it is best to agree on a common terminology upfront, particu-
larly about methodological phases. Then, document these terms in the common repository.

Formalize! Build an awareness infrastructure
We operate more effectively as a group when distant collaborators are aware of all the
dynamic factors that affect each other™s work.21 Recall that lack of awareness was intro-
duced in the previous section as a one of the reasons for the “coordination breakdown”
centrifugal force.
Research on awareness has its roots in the US military with the goal of giving a com-
manding of¬cer a feel for what is happening in the battle¬eld, all this with the aid of
technology. The US military researchers labeled this situation awareness. In subsequent
years, numerous researchers have parsed out situation awareness into a number of
important sub-types which are relevant to distributed collaboration (see Table 8.2).
More distributed software teams are creating “White Pages” that include: each person™s
name, contact information, and availability information (“I am available 09:00“18:00
GMT Monday“Friday”). It is useful to turn these “White Pages” into “Yellow Pages”
with full information about each person™s expertise, history, and tasks. This is a part of
an expertise search tool that large companies have been adopting.

Formalize! Create protocols for acknowledgments and urgency
A protocol is a code prescribing adherence to correct etiquette. Why bother with etiquette?
When collaboration crosses many time zones and relies on asynchronous e-mail,
we do not know if our partner received our questions or requests. Instead of an
157 Overcoming distance and time


Table 8.2 Awareness types22

Awareness Techniques to increase
types Answers the question Example this type of awareness

Activity Who™s working on Has Hans ¬nished the Repositories.

awareness which task? interface module, yet? Project/task systems.

Task Who has done something I need to start testing its Status meetings.

awareness and where is it? impact on my program. Pairing across sites.



Process What piece ¬ts where? I just learned something Organizational charts.

awareness How does Joe™s task ¬t important about the Expertise search tools.

into my task? What to memory module. Now, Work¬‚ow tools.

do next? who needs to know Integrated development

about this in the project? environments.

Availability Who™s there to answer June Hee is gone today, Instant Messaging.

awareness a question? who can tell me if the Team calendars.

Presence Who is around? cross-site meeting will Individual availability


awareness take place? schedules.

Environmental How does Natasha™s The weather this morning Team/site dashboards with

awareness work environment was awful disrupting the context, environmental
(weather, of¬ce, morning commute. data, news.
commute) affect her? There is a general Etiquette that includes some

Is it dark in London strike in the country, so exchange of environmental
now? daily life is disrupted. information.
Joe has to go to another Exchange photos of

room to access the workplace.
internet. Desktop video meetings.





acknowledgement, we often hear silence. The days tick by. Are they working on our
request? Silence across distance leads to all kinds of interpretations, most of which are
unhealthy and eventually lead to a spiral of mistrust.23 Instead of silence, distributed
collaborators need to establish a protocol of immediate acknowledgement. An acknowl-
edgement does not necessarily imply task completion, but rather a message in the fol-
lowing spirit: “I received your message inquiring about the procurement interface and
will reply with an explanation by Friday, July 12th.”
Urgency also needs a protocol since it is relative: different people assign different
priorities to messages and tasks. In some way, urgency (or lack of urgency) needs to be
expressed across distance. Urgency can be addressed via escalation protocols intertwined
in the managerial chain of command: e-mail to telephone, to cell phone, to home tele-
phone (for very urgent items).

Informalize! Create a cohesive team culture
Recall that one of the ¬ve centrifugal forces is that distributed groups are rarely cohesive.
However, effective managers can take some steps to create cohesion, to create a sense
158 Managerial competency


of a common team culture. This will help ease communication and foster trust across
distance. We describe several techniques to do this here.
Developers tasked to work together over distance do not have the luxury of taking
time to slowly build trust but must forge swift trust at the onset of their working rela-
tionship. Swift trust can be achieved by highlighting the reputation and professional
quali¬cations of team members. Technical people tend to respect (meaning trust) other
individuals who they view as technically quali¬ed. Therefore, take the time to explain
the pedigree of the distant partner: he was educated at the selective Indian Institute of
Technology; she worked for the ground-breaking Irish ¬rm, Iona.
A preferred, though expensive, means of building trust early in a project is to bring
everyone together for a face-to-face kick-off meeting. We human beings form into
cohesive groups when we develop common (informal) experiences together. The com-
mon experiences can be eating together, drinking together, playing together, or just
chatting with one another face-to-face. Jim Herbsleb24 speculates that one of the missing
ingredients to effective distributed teamwork is the informalism of “goo¬ng around.”
Of course, collective kick-off events are more common during times of company pros-
perity and for high visibility projects. Lower-cost options include well-orchestrated,
virtual kick-off events enabled with high-resolution video-conferencing.
Other common experiences require creativity and enthusiasm. Some distributed soft-
ware teams have created online team discussions, and given them a fancy label, such
as “virtual caf©,” or “virtual retreat.” These common activities can be asynchronous or,
perhaps, once a month in real-time. Activities can vary from solving a public policy
problem, to discussing the football World Cup, or even watching a football game at the
same time. Researchers have validated these recipes: virtual teams that have more social
communication achieve higher levels of trust.25

Informalize! Encourage interaction via real-time communication
I make sure to do a synchronous conversation (IM, phone, video, and face-to-face)
with each person on my team at least once a week. I even have a list of all team
members and check it off. “
A European Project Manager

These days, instead of Management By Walking Around (MBWA), we do MBFA
(Management By Flying Around).
An American Project Manager
Since human beings are more effective with real-time interaction, then any type of
real-time communication is preferred to relying strictly on e-mail. Like the European
Project Manager quoted just above, consciously shift to more real-time channels.
Even paired-programming (advocated by “Extreme Programmers”) can be conducted
with a headset telephone so one programmer can be keyboarding while speaking, as
the programmers share their computer screen using a collaboration tool, such as
159 Overcoming distance and time


Netmeeting (we come back to some lessons from Extreme Programming at the end of
this section).
Off course, the most effective real-time communication is face-to-face and therefore
there should be regular travel between the project sites. The liaison is the label we use for
the individuals interacting frequently with distant sites. They are the channels through
which synchronization is conducted and through which messages are transmitted.26 These
liaisons use not only face-to-face communication, but augment this with other real-time
channels, such as telephone, or video. The most effective liaison is often the expatriate
linking the organization to his birthplace. In that role he is not only a liaison, but a true
ambassador. Liaisons are nurtured via rotations (of weeks or months), or so-called
“onshore presence” (rotating lower-wage professionals to be near their clients or partners).
In spite of the bene¬ts of face-to-face interaction across distance, the travel budget is one
of the ¬rst items to be cut from distributed projects when budgets become tight. Sometimes
this cost-cutting ends up costing more. One study found that cross-site trust is low unless
at least one person made at least one trip between the software development sites.27

Informalize! Put warmth into cold e-mail
“I greet you and I invite all of you to my home for the dinner this evening.
It™s just after the corner of one of the main street of Rotterdam. ;)))”
A student e-mail from a global virtual team exercise28
Note some interesting attributes of this message. This message puts the writer™s col-
leagues in context by giving them a sense of where he lives. The message has at least
three grammatical mistakes, but the reader probably does not care because the message
is warm, welcoming, and its fantasy of a cozy dinner in his home adds to the warmth.
We already noted how easily messages can be misconstrued and lead to bitterness.
A bit of warmth can do wonders to alleviate distance. In general, this is about building
e-touch over the net. Some early research shows that those that are good at building
social capital in the face-to-face world are also good at doing so over the net. Here are
some useful e-mail clauses to incorporate into your next messages:29
— “¦ thank you for your ¬‚exibility in working with us on these points ¦”

— “¦ we have been making great progress on this ¦”




Lessons from “unconventional” distributed approaches
Two of the most radical and successful software movements have also fused the infor-
mal with the formal to overcome problems of distributed collaboration. The two are the
open source software (OSS) community, best known for Linux, and, separately, the
Agile Software Development movement, best known for Extreme Programming.
How has the OSS community managed to develop robust software in completely
distributed collaboration? After all, OSS projects are born distributed and rarely per-
form any co-located or synchronous activities.
160 Managerial competency


Walt Scacchi found several types of informalisms that make this type of distributed
collaboration succeed.30 Like other informal processes, requirements are co-mingled
with later phases, with design, coding, testing, and documentation. The requirements are
organized around persistent, globally accessible tools and repositories: websites, site
content directories, source code directories, threaded e-mail, bulletin board forums, bug
and enhancement descriptions, and version descriptions. All this allows those in the
distributed community to trace the development and evolution of the project and its
design. These are examples of the formalism principles that we noted earlier: stan-
dardizing communication protocols and building an awareness infrastructure.
The OSS community also standardizes around a rich set of Internet-based tools:
SourceForge, Bugzilla, forums, listservs, newsgroups, and IM. In lieu of formal require-
ments or any face-to-face interaction, the community develops shared understanding
using screen-shots, guided tools, “how to” guides, and execution scripts.
Extreme Programming (abbreviated as XP) is the best known of the Agile methodolo-
gies. Agile methodologies emerged as a reaction to the “heavy” methodologies that are
typi¬ed by CMM. XP believers (and they are believers!) advocate working in small co-
located teams. Programmers are paired with each other, working side by side, helping,
guiding, and mentoring each other. This is a “high contact” approach with much face-
to-face interaction. Therefore, XP is the antithesis of software collaboration over distance.
Nevertheless, XP™s advocates have learned to adapt it to the reality of work over dis-
tance: there is even a Dispersed XP (DXP). They learned a number of lessons,31 many
of which were discussed in this chapter: start the team in a single location (to get to
know one another); designate travelers that physically move around sites (this is simi-
lar to our label of “liaisons”); agree to a block of common time (this is similar to the
¬rst formalism principle of a rhythm of real-time interaction); agree on common com-
munication tools; and agree to a common set of coding guidelines, coding styles, and
modeling guidelines (we called these: standardizing communication protocols).


Managing time differences

“I can have a high priority, but at the time when [the US colleagues] are
sleeping they won™t answer me. [¦] Same thing with me: When I™m not working,
I™m not reading my mail.”
Singaporean computer engineer working on a distributed team with
American partners32
One of the biggest factors in the amount of time it took us to ¬x bugs was the
time zone difference. When we diagnosed a bug, we tried to determine who in
India, Europe, or the US needed to look at it. We™d reassign it, but if it had to go
to someone in Europe, or India, there would be a delay of several hours before
the assigned person would be in on their regular work shift to look at it. If it
got assigned to the wrong person, they might reassign it in turn with another
161 Overcoming distance and time


potential time zone delay. With problems that were dif¬cult to diagnose, the
ownership of the bug could pass back and forth, with time zone delays adding
up to several days of little or no work getting done.
Software engineer, Siemens, USA
Time differences are a constant nuisance when offshoring. Time differences are more
than merely time zones, they also include different starting and ending times at work,
different religious and national holidays, different weekends, and different lunch and
other break hours. Here we present these time differences and some of their related
best practices, based on research Carmel conducted with Alberto Espinosa.33


Managing time-zone differences
Experienced global managers have a bag of tricks that they use implicitly, almost intu-
itively, in managing and coordinating across time differences. It is quite clear that dis-
tributed teams do not treat time differences as static, but rather adjust and adapt to
them. The 10.5-hour difference between New York and Chennai (India) is not “¬xed”
in that sense. These tactics are summarized into three categories in Table 8.3 and we
explain each of them below.

Asynchronous tactics
Effective distributed teams learn to conduct as much work as possible in non-overlapping
time. This translates into a number of tactics. First, effective teams formalize and structure
activities and messages so that they convey information in a more effective manner, thus


Table 8.3 Tactics to overcome time differences34

Category Tactic

Asynchronous Structure and formalize into work¬‚ow tools.


(non-overlap) Plan the work day: bunch-and-batch; plan dialogue for overlap window.



Synchronous Enlarge overlap window by working longer.


(overlap) Enlarge overlap window by shifting work hours.


Enlarge overlap window by always being available.


Enlarge overlap window by creating a 2nd shift in the low-cost offshore


destination.
Create individual liaison roles who adjust/enlarge their own hours


rather than the entire team™s.
Create ¬xed daily, or once-a-week, overlap periods between sites.


Synchronize individuals who are working closely together (in paired tasks).


Break the e-mail chain.



Awareness Reminders and coaching.


Easy access to current time, calendar, and holiday schedule of distant


individuals.
162 Managerial competency


reducing the interaction required by a need for clari¬cation. Distributed teams become
“bureaucratic” in other ways: they carefully de¬ne the collaboration work¬‚ow, tasks,
owners, and deliverables in order to reduce the need to coordinate via real-time interaction.
Time-separated collaborators learn through experience to plan and organize their

<< . .

 21
( 36)



. . >>

Copyright Design by: Sunlight webdesign