Global Software Teams: Colloborating Across Borders and Time Zones

Description

• Copyright 1999
• Dimensions: 6" x 9"
• Pages: 288
• Edition: 1st

• Book
• ISBN-10: 0-13-924218-X
• ISBN-13: 978-0-13-924218-2

92421-7

The first best-practices guide to organizing and managing global software teams. Examine what drives global teams apart and what keeps them together. Covers technical, procedural, managerial, and cultural issues Includes real-world global case studies.

Software development is tough enough when it's done locally - but it's even tougher when you're trying to manage cultural, language, and time-zone differences too. In Global Software Teams, expert consultant Erran Carmel brings together the latest best practices and real-world case studies in global software development-showing what works and what doesn't.

Discover five "centrifugal forces" that drive global teams apart and six equally powerful "centripetal forces" you can use to hold things together. Learn the best ways to apply:

• Telecommunications infrastructure.
• Collaborative technologies.
• Development methodologies.
• Software frameworks and architectures.
• Team building techniques, and more.

Learn how to build trust among key players regardless of location. Discover which projects best lend themselves to global teams. Understand the obstacles to "follow-the-sun" software development. Whether you're already involved in a global software project - or expect to be - this book provides the answers that can make the difference between success and failure.



Sample Content

Table of Contents

I. WHY GLOBAL SOFTWARE TEAMS?

1. Why We're Seeing More Global Software Teams.

Crossing Borders. History of Global Software Teams. The Future of Global Software Teams. Further Reading.

2. Three Tales of Global Software Teams.

PrestigeSoft's Version of Follow the Sun: Prototyping Around the Clock. Orchestral Technologies' Version of Follow the Sun: Sharing Code Between US and Russia. The Case of IBM's Version of Follow the Sun: The Global Software Factory.

3. The Bottom Line: Are Global Software Teams Successful?

II. THE FIVE CENTRIFUGAL FORCES OF GLOBAL SOFTWARE TEAMS.

4. Dispersion, Coordination Breakdown, Loss of “Communication Richness,” and Loss of “Teamness”.

Dispersion. Breakdown of Traditional Control & Coordination Mechanisms. The Loss of “Communication Richness”. Loss of “Teamness”. Diversity's Drawbacks. Loss of Cohesion. Building Trust Takes Time. Team Size Gets Out of Hand. Further Reading.

5. Cultural Differences.

Is Culture Significant? Different Types of Culture. The Fundamentals of Cultural Differences: Hofstede, Hall and Others. Do Cultural Differences Affect Software Professionals? No, There are Essentially No Cultural Differences Amongst Software Professionals. Yes, There Certainly are Cultural Differences Amongst Software Professionals. Culture, User Design, and Application Knowledge. Conclusions. Further Reading.

III. THE SIX CENTRIPETAL FORCES FOR SUCCESSFUL GLOBAL SOFTWARE TEAMS.

6. Telecommunications Infrastructure.

Best Practices Roundup. Further Reading.

7. Collaborative Technology: Generic Technology and Technology to Support Software Engineering.

Generic Collaborative Technology. Selected Collaborative Technologies and Their Use. The Cultural Overlay of Collaborative Technology. Collaborative Technology to Support Software Engineering (CT-SE). The Team and Collaborative Technology. Best Practices Roundup. Further Reading.

8. Development Methodology.

Best Practices Roundup. Further Reading.

9. Architecture & Task Allocation.

Task Allocation Strategies. Inter-site Task Allocation Criteria. Task Allocation of First- and Second-Tier Development Activities. Intra-site Task Allocation. Change in Allocation over Time; Stage Model of Global Software Teams. Best Practices Roundup. Further Reading.

10. Building the Dispersed Team through Trust, Communication, and Personal Bridges.

Building Trust. The Kick-off and Other Milestone Meetings. Communication. Lateral Communication. Everyone Gets a 360<198> View. Team Communication Protocols. Communication: The Many Forms of English. The Principle of Building Personal Bridges Between Sites. Building Personal Bridges Between Sites: The Cultural Liaison. Building Personal Bridges Between Sites: The Need for Constant Travel. Building Personal Bridges Between Sites: Expatriates. Creating the Common Team Culture. Become Aware of Culture's Effect on the Style and Speed of Decision Making. Bridging and Managing Time Zone Differences. Training. Cultural Training and Preparation. Team Governance: Contract? Maturity Models for Teams. Best Practices Roundup. Further Reading.

11. Specialized Management Techniques.

Designing the Team Structure. Managing Conflict. Project Management Techniques. Measure! Recognition, Rewards, and Compensation. Selecting the Global Software Development Manager. Best Practices Roundup. Further Reading.

IV. GLOBAL INFORMATION SYSTEMS TEAMS.

12. Globalization and Information Systems.

Implications of Globalization for the IS Function: The Integrated Network IS organization. IS Global Outsourcing. Best Practices Roundup. Further Reading.

13. A Methodology for Defining Global Information Systems & Designing Global IS Teams.

PSR—Process/System/Responsibility. Types of Global IS Application Teams. Other Specialized Global IS Teams. Best Practices Roundup.

14. Holiday Inn's 'A Passage To India'.

Acquisition and the Move to Atlanta. From Insourcing to Offshore Outsourcing: Passage to India.

Appendix A: A Research & Data Collection Methodology.

Composition. Identification of Teams. Data Collection.

Appendix B: Differences Between IS & Packaged Software Development Teams.

Glossary of Key Terms. Endnotes. References.

Index.

Preface

Preface

This book is intended for the software professional or software manager who either is about to embark on globalization or has already taken the plunge and is discovering some unforeseen problems. It is designed to help the software professional think about and find solutions for the range of issues specific to global software teams — managerial, behavioral, cultural, and technological.

The book is about global software teams of all kinds, but primarily about those organizations that make packaged software, also known as software products. These are software organizations like IBM, Microsoft, SAP, Baan and their thousands of smaller competitors. Parts 1, 2, 3 are written predominately with those organizations in mind. These are the organizations that have been going through a major globalization surge. These are the development organizations that I have been studying over several years. The specific issues of global Information Systems (IS) teams are covered in Part 4. Packaged and IS organizations both develop software, but differ in many key organizational respects. For example, a basic difference is that packaged software organizations develop a product for many customers, while IS units develop a system (not a product) for one customer (albeit very large on occasion). More on these differences appear in Appendix B.

Many of the observations and recommendations in this book are derived from the Globally Dispersed Software Development study ("GDSD study" from hereon) of software companies, which I conducted in recent years. The study's research methodology is covered in Appendix A.

It is also important for the reader to know what this book is not. There are hundreds of books about teams, from medical teams to government teams. Many of them take an advocacy approach of "teams are wonderful." This book is not about team hyperbole or global hyperbole. It takes a sober-minded look at what is known about teams, culture, and managing software development. Managing global software teams is difficult. The pioneers described in this book are mostly a self-selected group who have a strong interest in making these new ventures succeed. Once the novelty wears thin, many of the difficulties will remain.

This book is also not a primer on technical issues. It assumes some experience with software development, with various collaborative technologies, and with development methodologies. It takes more of a beginner's approach to cultural issues because my assumption is that this will be a first exposure for many readers to this subject.

How to Read this Book

The book is structured in such a way that it can be read in the old-fashioned linear fashion, or it can be used more like a reference book. The reader interested solely in the reference book components ("How to") should skip to Part 3 and Part 4.

Part 1 provides background to the global software team phenomena. Why are so many organizations creating these globally dispersed organizational units? More than a dozen reasons are presented with data in Chapter 1. The reader new to the topic may want to plunge quickly into Chapter 2, which describes three cases of global software teams. Chapter 3 takes the reader to the really difficult managerial question — are these new organizational units successful using measures such as cost and time-to-market?

The bulk of the book is structured using the model of Exhibit P-1. Software globalization is like a centrifugal force that propels things outwards from the center as it disperses developers to the far corners of the world. A centrifugal force must be balanced by centripetal force, a counter force, that is directed into the center. Centrifugal is derived from the Latin "to flee the center," and centripetal, from the Latin "to seek the center." If you take a stone, tie it to a string, and whirl it with your arm, the centrifugal force exerts force outward. The centripetal force, analogous to the string, keeps the team from being launched into a state of disorder and exerts force inward. The centrifugal forces are the five problem areas presented in Part 2. The centripetal forces, the countervailing forces, are presented in Part 3.

Part 2 covers each of the five centrifugal forces — the problems — that pull the global software team apart and inhibit its performance. Chapter 4 includes the first four forces. The first of these is geographic dispersion. It highlights something we know intuitively, that it is harder to manage from a distance. This discussion is followed by two forces that build on the problem of distance. Teamwork depends on a process of coordination, much of it informal, a process that falls apart when teams are dispersed. Communication technology is but an alternative to the richness and satisfaction that comes from communicating face-to-face. With the loss of personal contact, team unity, in a team composed of multiple sites, is hard to achieve. Chapter 5 presents a lengthy treatment of cultural differences and cultural breakdowns. It includes ten important dimensions of national cultural differences as well as a specific focus on cultural differences of software developers in various nations.

Each of the six chapters of Part 3 covers one of the six centripetal forces — the solutions — that pull the global software team together and make it more effective. Chapter 6 discusses the telecommunications infrastructure — the foundation for all the other strategies, techniques, and solutions that come later. Chapter 7 introduces the cement that holds it all together, the collaborative technologies — from groupware, through e-mail, to the family of specialized collaborative technology tools for software engineering. Dispersion means that informal coordination cannot be done the way it used to be done. Coordination must be channeled through all forms of collaborative technologies. Some of the communication can remain informal, but much has to be formalized. Chapter 8 addresses another topic that requires some formalization: the systems development process itself. Ad hoc processes will not work in global teams. The organization needs to select and tailor a development framework and then have all sites subscribe to it. In Chapter 9, we come to the critical issue of product architecture and task allocation. The product architecture needs to be conceived carefully because it must correspond to the architecture of dispersed team sites. The team chapter, Chapter 10, brings human resources into the equation. After all, the software itself can be duplicated quickly. The company's primary competitive edge is its human capital. How do you glue together remote sites to bring them to their highest performance level? This is done by a combination of building trust, conducting kick-off meetings, fostering lateral communication among team members, traveling, and other means. Chapter 11 focuses on global managers and on a potpourri of managerial issues — from team structures, to special metrics measuring the unique characteristics of a global team.

Part 4 shifts to the particular issues of global Information systems (IS) teams. Global corporations are dealing with higher levels of IS cross-border, collaborative development because of increased cooperation between central and subsidiary IS units and the emergence of off-shore outsourcing. Chapter 12 addresses the question and implications of why companies globalize their IS functions. Chapter 13 presents a setp-by-step guide to the Process/System/Responsibility (PSR) methodology for global applications. This methodology helps corporate IS to design the global IS team, but only after comprehensively identifying the corporation's global processes and worldwide systems. Chapter 14, written by Professors Kumar and Willcocks, presents a colorful case study of IS global outsourcing at the US-headquartered hotel chain Holiday Inn. Holiday Inn began its outsourcing by insourcing — using contract software programmers that worked inhouse. At a later phase the contracting staff were moved to India. The different management issues of insourcing versus global outsourcing provide valuable lessons. A note on convention used throughout the book: a (global software) team consists of two or more (geographically dispersed) sites.

What Is Unique About Global Software Teams?

Any software professional knows that even "normal" — much less "global" — software development is fraught with difficulties. Depending on whose estimates one subscribes to, perhaps half of all systems projects are failures. The entire field of software development, or software engineering, is still going through a maturation process. This book does not attempt to cover all the problems of software development, but rather to highlight the differences between "normal" software development projects (and those people who build them) and global software teams. The list of features that distinguish global software teams from normal (nonglobal) software teams is short and precise: distance (the distance of developers from each other and from their customers or end-users); time-zone differences; and national culture (including language, national traditions, customs, and norms of behavior).

Distance.

Geographic distance (dispersion) between development sites has a direct impact on all forms of communication. Communication is less frequent and more constrained. Distance impacts the communication between designer and customer, the communication between two developers, and the communication between development teams and their remote managers. Communication constraints become increasingly significant for software development teams, whether the team's sites are in the same metropolitan area (e.g., Boston-Brookline), within the same country (e.g., Boston-Berkeley), or cross-ocean (e.g., Boston-Bangalore). (The problems of distance are expanded upon in Chapter 4).

Distance affects all manner of coordination and control. In general, managing a team of programmers and designers is dependent on rather minimal controls and commands, relying instead on informal coordination (such as socialization). This kind of coordination is very communication intensive. Of course, once the team is dispersed, this management style fails. Problem solving becomes more difficult. The socialization of teams becomes agonizing — teams do not develop cohesiveness when their members are many kilometers apart. Teams can only slowly come to share a common vision of their work and their products. Project managers become confused with distance: The instinctive mode of supervision by walking around and talking to team members is no longer available. Managers are reduced to managing through milestone charts and once-a-week conference calls and can slowly lose control over the development process. (Loss of "teamness" is explained in Chapter 4).

Distance forces most communication into electronic pipelines of various widths and colors. These pipelines (channels) are not as rich as face-to-face communication. In fact, not only are they not as rich in conveying the message that we wish to convey, but many are asynchronous (such as e-mail, or structured conversations in groupware). While some Western cultures may be somewhat comfortable forming relationships over electronic means such as e-mail, telephone, or video-conferencing, other cultures find these channels extremely uncomfortable unless solid personal relationships have already been formed. (Our desire for more "rich" media when we communicate is covered in Chapter 4).

Time zone differences exacerbate the communication problem. When developers in California and India have no natural overlap of working hours for voice or video conversations, then one side always has to compromise. More practically, almost all communication is channeled through various asynchronous technologies, such as e-mail, or formalized work flow arrangements. (Specific handling of time-zone differences appears in Chapter 10; collaborative technologies are presented in Chapter 7).

National Culture.

Perhaps the most confusing intra-team feature is national culture. We use a broad definition of national culture in this book to encompass national and ethnic traditions, customs, norms of behavior, as well as language. Cross-cultural teams have more potential — more potential for productivity as well as more potential for problems — relative to that of more homogeneous cultural groups. Problems may stem from mistrust, miscommunications, and lack of cohesion. Global managers are faced with a balancing act: Foster a healthy conflict of ideas and opinions while controlling cultural differences among team members.

Software developers from different cultures exhibit different behaviors, norms, and assumptions even though the lingua franca of the computing world is unequivocally English. Most people are surprised when they learn that spoken words account for little of our total communication. The major part of communication, perhaps as high as 80%, consists of contextual information as well as nonverbal cues, such as greeting styles, gestures, and posture. Both verbal and nonverbal communication is awash with ambiguity. The nonverbal part is especially difficult because it relies much more on culture. Worse, the nonverbal cues are difficult to convey across ("nonrich") electronic communication channels.

One of managers' most important roles is to understand the sources of conflict within their team. National cultural differences make this task more complex. For example, an American software company acquired a British software company. The respective sites began collaborating and encountered a critical disagreement. Was this disagreement rooted in national culture differences, organizational cultural clashes, or professional differences? Unless one understands the root, the solution will be only superficial. (The problems of cultural differences are explored further in Chapter 5. Solutions appear in Chapters 10 and 11).

Cultural diversity also represents the tremendous potential of bringing in fresh ideas and perspectives. The cultural differences can be fused to create a cultural synergy: new ways to solve a problem, design a product, or think about the software production process itself. This is the primary energy that the global software team needs to harness.



Updates

Submit Errata

