Open Collections

UBC Graduate Research

Matching expectations: When culture wreaks havoc with global software development Hsieh, Yvonne; Kruchten, Philippe; MacGregor, Eve 2008

You don't seem to have a PDF reader installed, try download the pdf

Item Metadata


Hsieh2008Culture.pdf [ 363.51kB ]
JSON: 1.0107464.json
JSON-LD: 1.0107464+ld.json
RDF/XML (Pretty): 1.0107464.xml
RDF/JSON: 1.0107464+rdf.json
Turtle: 1.0107464+rdf-turtle.txt
N-Triples: 1.0107464+rdf-ntriples.txt
Original Record: 1.0107464 +original-record.json
Full Text

Full Text

 UBC-ECE: Hsieh, Kruchten, McGregor i     Technical repot:  Matching expctaions: When cultre wraks hvoc with globalsoftware development   Yvonne Hsieh,  MaSc Philippe Kruchtn, Ph.D., P.Eng Ee MacGrgorcEIT  February 2008    Electrial and Computer Engineering University of British Columbia 2332 Mn Ml Vancouver, BC, V6T 1Z4    Canada  Contct:  UBC-ECE: Hsieh, Kruchten, McGregor ii  UBC-ECE: Hsieh, Kruchten, McGregor 1 Matching expctaions: When cultre wraks hvoc with globalsoftware development Abstrac In this reearch, we examine how intercultural factors afect—positvely or negatively—the outcomes of sofware deveopment practies. In the past decde, the North Arian and Wstrn Europen IT industries have observed a rapid incres in the number of companis er outsourcing software project for development abroad or starting their own delopmnt crs in remote locations. In spite of gre promse and anticpation, mny global sofwre developmnt projects fail. Aftr failures, one party is quick to bla the otr’s percived lak of diligenc, comitent, or ability; or te tchnology. But w observed that projcs oftn fa beus of subtl intercultural isue that impact the efivene coordination in the distributd team. To xplorehis mater, w examine the concept of culure and the potential it of intrculural dynacs on global software developm projcts. There has ben litle analytia resrch done in this arend he efct of intercultl facors has, thus fr, been ased baed on anedotal acounts by projt mgers. Our rearch combines t grounded theory and cse sudy research, strting with a collction ofcritil incidents in global projct. W present a descriptiveonceptual framework, for coordination bewn individualnd teams, that hasemrged from our daa and use it to analyz and explin som of our findings. 1. Introduction It is far esier to globalize, “virtualize,” outsource, or offshore activies that involve only bit (of information) as opposd to atom (of matril). Bit mov quickly and inexpensively, wherea atoms, in the forms of foods, manufured goods, or raw materils, need to be shipped slowy and at gret expense. The development of softare sys ha trefore emerged as a prime candida for becoming a globaly disributed ctiviy.  The growth of global software development is propeled by a number of enablrs and promised benefis (e.g., reduced lbour cost, large ski pools). Creating software in the ditributd environment is a chalnging endevor that is confronted by spail, emporal, organizational, tchnologica, and cultural nuance and complxites (Hrbsleb & Moitra, 2001). Resrchers and prationers have reognizd the ned to moresysaicly study te iuend ther impacts on software developmnt  (Damin & Moitra, 2006; Herbslb & Moitra, 2001). In our sudy, we focus on t isue of cultureand is role in globay distributed software developmnt work. Thi paper looks a the efct ofntrcultural facors, presnt findings from a study of large software projects,  UBC-ECE: Hsieh, Kruchten, McGregor 2 and proposes the AxE model, a conceptual framework for analyzing coordination problm in software deveopmnt. Sction 2 presnt the motvaton and context for our study, Sction 3 outlines exampls of culuraly-bad coordiion mishaps, and Secions 4 and 5 dicus in greater detail the central research problem and our resrch stragy. In Setion 6 we discus the specfs and applicbility of the AxE model, aion 7 uss the model to intrpret t mihaps w have obsrved. Sction 9 discuses potental rearch diretions, and gives our conclusion. 2. Motivation Software engineering (i.e., the engineering of software-intensive systems) i a highly knowledge-intnsive activiy. Unlike other engineering discplnes, thi “oft” nature mkes it hard to modularize a software systm into clr-ut components tha can be aigned to and deloped by difent individuals and then later asbled. Rather, tre s consstently a high lvel of intrdependenceong t mny activis and work produc involved in softare developmnt. Software enginering i alo a young disciplne with few esblished practies and in which methods, notations, proces and tool are rapidly evolving (Kruchtn, 2004). Ts “thnologicl churn” (Booch, 2002) further slows down the emergenc of a common, wl-understood wy to procd. Originaly, softare ws developed by colocated tams. Baed on thesecollocated projects, a body of knowedge on how to develop softare ha ben ambled nd is slowy being codified, as evidencd by the Softwre Enginering Body of Knowdge (Bourque & Dupui, 2001). Dspite t eergence of these developmnt methods and proces, failure rates of sofware projcts remain high. T Chaos reports (1995, 2001) sta that only a third oft  are succsful and half are sriously chalnged (e.g., there over budget, produceyst with poor functionality or mediocre quaity). Compad to other engineering disciplnes or eonomic avies, softwa development is highly risky and unpredictabl. The 1990’s saw the emergence of global sofwre development (Carmel, 1999; Herbslb & Moitra, 2001; Karolk, 1998; Kraut & Ster, 1995; Sahay et al., 2003;Sathynarayan, 2003; Yourdon, 2004). In this diributd environmnt, sofware organiztions initialy tried to use the same recipe and procse tt they had used internaly for coloctd developmnt. But as Borchers (2003) reports, in global projcts, “mthods that were thought to be ‘best prati’ turned out to be inefective or very dificulo implnt.” In the distributd environment, companies run into spatial and tmporal gaps: physial ditnce and time-zone difrenc make any form of direct comunication much moreficult. Anything that is not the routine execution of predefined tsks, such as geting quik information and reource, bransting new ias, or reahing consensus on a design, proves to be problmatic (Carmel & Agarwl, 2001). Collborative tool atemptd to fil thes gaps, but proved inadequate (Msey et al., 2003; Sarker & Sahay, 2004). Adding to t chalnges wre the wily held and underlying asumptions that “a world-wideomputer-litrae culture, the intrnet, a programer (hacker) culure lrgely domnat the dynamcs of tse global teams. A result of this ‘net ct’, programers behave sa in San Jos, Boston, Budapetor Bangalore” (Larry Constantine keynot, at t TOLS paif confrenc in Sydney, February 2002), or that “becus [the sofware personnel] require litle human interaction  UBC-ECE: Hsieh, Kruchten, McGregor 3 to be succesful, the individual does not need extnsive intercultural skils” (Beamn, 2004). To summarize, software enginering difrs from other globaly distributed economic ativis in the following respects: • It is entrely an intectual activiy: al bits, no atoms (Kruchten, 2002).  doe not lend itslf to simple work breakdown stures, or “nearly decomposabl subsysts” (Sion, 1996).  • It requires a lrge aount of intrpersonal cmunication.  doe not haveny widely aceptd proces. While the intelctual aspect makes software developmnt an idel candidate for distributd work, the otr charatriis mke it particularly vulnerabl to chalnges introducd by geographil, temporal, organizional, and ctural boundaris. In particular, what impact could culture have on globa softwre deveopment? Collboration in disributd and curaly dirse tams cates new dynamics: “In the new paradigm, there i no obviously dominant culture and there may be ltl or no incentive to cate a negotiated culture” (Hsh e al., 2005). Our reserch investigaes hat and how sofwre developmnt proce and practies arefctd in thi culuraly-dirsting, and aso what coordination problm likely to result. W start by looking a some example. 3. What happens in practice Evidence suggest that mshaps in global software development are sometims culturaly relatd (Olon & Olon, 2004), and most projec mnagers have one or two sorie theove to t. To iustrae our point, here a som incidents w collctd. 3.1 How much is enough? A manager at company C request that a developer at company D investigae a sries of options and make a recmendaion regarding a pending smal deign decion. Consdering the iportanc of this decison, the manager expects the iston to be completd by a morning’s work and reported in an informl meo. A wek laer the manager has stil not herd from the remot developer and inquirestr or not hisrequest i beng worked on. Honders if ther has forgottn his requet. Two weks afer the initial request he recives a 5-page report on the various optionshe anager does not have time to read such an indepth re and ultimately does not ratethe recommndations as usful. From that point on, the manager only channel hi request to a few delopers whom heruss to understnd his request. 3.3 What are plans for? Company E negotiates  subcontract for a multimlion dollar project wih Company F. As part of the contrac, Company F is required to produce a procs document that deails the software developmnt proce to be used in the projct. The is eiy aroad mp for t projet, defining key documntation and reviw proc a wl as project progres. Company F producs a procs document that saisfe the contractrequimnt and the projct begins. Two yers ltr, closo thecduld delivery dae, Company E realizes that the project has not progresd as std and snds engineers to investigae. During t cours of the invetigaon the engineers ask where t procs  UBC-ECE: Hsieh, Kruchten, McGregor 4 document is. The engineers at Company F look around and find the document on a shelf, covered with a layer of dus. When Comny E asks about this, t respons is “you didn’t acualy expect us to follow that plan, did you?” 4. Problem statement, hypothesi The problems decribed in the previous section, along with many others commonly found in global software projets, can be considered as miatches in expectations betwen reotis. Thes mimcreat breakdowns in projet coordinaon and may result from a variety of reons including comuniction delays and noise; difring lnguageskil;nd disconnetsn knowedge. While the mstches can be found in collocted projects, they are exacerbatd by the various boundarie inherent in the distributnvironmnt. Furthermore, developers from difrenc cultures collborae in the distributd seting, t mismatcs are often result of intrctura difrencs. Our reearch examnes te expeion mismache in the context of culture and hypothesiz that, in mny cse, mt result from intrcl diferes in factors such as values, behavioural norms, socil sysems, and communication approa.  4.1 Definiton Before we go further in explaining our hypothesi, we should take a closer look at what the trm cultur actualy mens. For the purpos of thistudy, it isppropriat to useSpencr-Oay’s definiton of culture as “a fuzzy st aiude, belifs, behavioural norms, and basi asumptions and value that are shared by a group of people, and thatinfluee ech member’s behaviour and his/her interpretaions of the ‘maning’ of other peopl’s behaviour” (Spencer-Oatey, 2000). One of the implcti of this defiton s to do with the function of culture. More specifaly, beside beng an influencng facor on pee’s beviours, c also afts how people ntrpret others’ behaviour. This intrpretive fti cult i eialy import in irculural situaions as thebehavioural norms of oneure my be misunderstood or regarded as incongruous by other cultura groups. In the global project, such misaches in interpretaion may result in misunderstanding, miscommuniation, conflct, mtrus, and even underutilztion oftalent, ulimely degrading t t performance.  4.2 Problem Our research is baed on the premise that there and wil continue to be intercultural factors that afct both collocatd and disributed software developmnt eforts. This ideais supportd by Gibbs (2002) who point out that the is a growing body of litraure that ndites tt ultural diferencs will reain a significnt fctor wthin, and may even bemagnifid in respons to, organizational culture. It should not be asumed that thes fctors arel negative. In fct, a les two projet managers have report a good ix of cultura approaches w beneficalo their projects (Borchers, 2003; Kruchten, 2004a).  Despit the fat that softare engineering is a highly analytical proces, culture and intrculuralcors are plying an oftn unrecognized rol in projt. Whil therewil be irct ft in tems tha are collocatd, the potential impac of ntercultl faors in disributd ta is much grer. “T lrgest ftor in global  UBC-ECE: Hsieh, Kruchten, McGregor 5 teams that we have sen is that they come from diferent cultures” (Olson & Olson, 2003). 4.21 Definig “team”  Our traditional notion of a “team” includes people who work together on a common task in a colocated environmnt. If thi i so, what does “team” mean in distributed context? In a distributd contxt tas are variously and intercngebly refrred to as being virtual and/or global. Gibbs (2002) defines global tas a “…crossing boundaries - cultural, geographical, tmporal, and organizational. They are both virtual and mtic. They also rey predominantly on the use of ltroni communiaon ratr than fae-tofe intracton, due to tir geographical dispersion. Team mebers aret last somewhat interdependent, to the extnt to whih they work collboratively to cpl cmon tasks. Finaly, ttam's straegy and work itsf i globa in scope.” Alhough w wil draw on exiing cultural theories and models to help explain data coletd in our study, we recognize tha fuidity of culture makes it nerly impossible for us to pinpoint any event to a particular cultural layer or group. Our focus is on xamining the diferencs in how softwre proces and pratices, are regarded by developers atnt site, and explining the difrencs in the context of cultural predisposions, be they tam, orgazatonal, or national.   5. Research ethod 1 Research question At a high level we are interestd in the question: How is cultur affcing particular sofware devlopment practices and rlatd arifacs?To answer this queton, we have taken a grounded approach and us a two-phase resarch stragy. In the first phase, w look for specif areas of interesthrough intrvis wih software profionalhile in the seond pha, w conduct more rigorous and deiled analyss to further refine our hypothesi.  5.2 Data collection and areas of interest In the first phase of this reearch we ierviw project managers and other personnel who have been, or are currently, involved global softare development projects. Our aim is to se wt emrges in trms of (potntiay) culurally-basdishaps and suce. Our current cas studie are with companies involved in project spread betwn Canada, USA, Rusi, Italy, India, Nel and China. Thus far w have conduced 21 si-structured intrviwsith a tota of 11 particpantsrom thes organiztions. One are of intreshat has emerged ha to do with t hard understanding of expectation beten remote developmnt sits (e.g., wha constiutes proper documentaon or procs? How are reviw carried out? How are prioritis rated?) We investiga how the expectaions stisfd or faild, and what influenc intrculturalfacors my have on tse intrat. Bad on the dat collecd, we have also  UBC-ECE: Hsieh, Kruchten, McGregor 6 developed a smal descriptive framework that wil be used to describe expectaions (both met and unmet) in coordinaton (s Sction 6). 6. The AxE coordination odel Collaboration implies (1) breaking down work into smaler “chunks;” (2) alocating the chunks to various groups or individuals, baed on skis, competenc, responsbily, vailbiity, and/or other crite; and (3) aligning al the c bewen the various partes to integrat and produc the fina softwre system. Dnding on t complexity of the work, work procs of varying granulrities may be involved in each of thre aspect. Coordination has been studied from various perspectis (Crowston, 1997; Mlone & Crowson, 1994) and ioftware development by Kraut and Sreetr(1995). ost of thee torie of coordination and the reatd tools and techniques (e.g., step-bysep manuals, procdures) sem rooted in t Input-Proc-Output (I-PO) model. “Idely, architcure, plans, and procs—coordination mhanism—would be sufficnt to esablish efctive coordination among teas” (Herbslb & Grinter, 1999). However, what i striking in the mishaps tt w have collctd is tt, in globaly distributd projecs, ofe input, proces, and outputs arepparently w-defined,  sil a kinds of failures occur. We have deloped a smal frawork, cald AxE, for Anticpation-eXcution-Expectaion, to anayze, explin, and reson about the failures tha w have encountered. The model difers from other model of coordination in tt iakes into a the transient and social micro-atributes aociated wh coordinaion input, outputs, and procs. The mode consis of 3 elmnts: 1. t concept of dicrepancis betwn expected and actual is and outs (“the delas”) 2.  fow over time, in three stps (“the waltz”) 3.the concept of a “trus capil” 6.1 Handing over inforation Asuming that during the executon of the software development proces, some artifact U (e.g., a docent, some code) has to be handed over from a party S to another pay D, there a 3 atributs of U that may afect t efectines of coordination in t proces: • C: a definiton ofhe contnt of U. Contnt refrs to not only t materil but alo its representaion. For exampl, the compones of a use-casy incude the nam, decripton, pre- and post-conditions, involved ators, min flow of events, and altrnat flows of events; t defnion woullso speify (or imply) how t components should be repreed. • Q: the level of quality of U at the time of the handover (e.g., is U a sketch or very plt? Has it been reviwd? How much detail isncluded?)  T: t tim a which the handover occurs. For theriplet oftributs U [C, Q, T], three instances are defined (Figure 1): • Anticpatd, by t source S, UA:  T aipated U is what initialy thinks he wil deliver to D: an anticpated ontentnd an anticpad lve of quality a an antcpated time of delvery. • Expectd, by the destnaion D, UE:  UBC-ECE: Hsieh, Kruchten, McGregor 7 The expected U is what D initialy asumes she wil receive from S: an expected content and an expeced lve of qualit an expetd tm of receipt. • Exutd, what is atualy handed over by S to D, UX:  The execed U i thetl artifact that S hands over to D: a crtain content of a certain lvel of qualty deivered a a certain te. 6.2 Discrepancies (deltas) Often the cause of breakdowns in coordination is the diferencs betwen the 3 instances of U: •ΔEx is the diferenc betwen what D expectd and what she recived (i.e.,  UE -UX). Tscpay may be on any of the 3 aributes: diferent contents, diferent lvel of quality (e.g., completnes, auracy), and/or difre time (e.g., lat, mosten). • ΔAx is the difrenc betwen what S anticpated he would deliver and what he actualy delived (i.e., UA - UX). This dirency is le obvious: why would someone der somthing other tn what he anticpat? But this i often the  in software projecs a time presure or work overload compromi quality and/or timelines. • ΔAE is the difrenc in percption betwen S and D regarding the 3 atributes (i.e., U – UE). O would think tha, in a wl-oiled and disciplned organization tha rigorously follows a defined procs, such discrepancy would be mimd. In software project, nevertheles, ΔAE i common, due to the nature of softwre developmnt. Many software engiring artifats are intangible—informaion, intes, plns, partil definions, risks, este, aong otrslaving a gret al to interpreton (and therefore dicrepancis in perception). S and D my very wl adhere to the same proces but intrpret the detals of the proces diferenty.  It should be notd that ΔAE is not necsarily the sum of ΔEx and ΔAx. In som cas ΔEx and ΔAx are greater than : the expected and anticpated values arelose, but theexecution fals fr from both. Also, A wide ΔEx may not nesariy be the fult of sourc S; the cus my be unreaonable etions from the detinaon D.  Figure 1: Overview of the AxE discrepancies (the 3 deltas)  UBC-ECE: Hsieh, Kruchten, McGregor 8  6.3 Stages for coordination (the waltz) The handover of U from S to D proceds in 3 sages: • Planning, where anticpatd UA and expected UE are formed; Execution tualrtifact UX is handed over;  Fdback, wre ΔEx and Δx are aualy percived, evaluatd, and (maybe) ommuniated. 6.3.1 Communication channels These 3-tage handover impli some form of communication betwen S and D. This communicion can tke mult fs (a shown in Fgure 2): • Direct: S and D speak to each other face-tofae. Mediated use s medium (e.g., eail, instant mesaging).  Indirct: S a acsom cmon repostory, docum(s) (e.g., plans), and/or procs(e). • By proxy: S and D cmunicate vi third parties (e.g., management); S and D my not beware of their mutual existenc.  Implict: S a use contxt to implictly deduc the anticpatd and/or expeed values.   Figure 2: Modes of comunicatio during coordination  6.3.2 Plannig How do S and D form UA and UE, respectively? The time component is usualy the simplest: S are both aware of some sdule or plan. The conte and t quality are more subjective to interpretion. There may be guidelines, but t specifs of t contnt and qualy are afcd by fctors including (1) previous intratons betwen Snd D; (2) the extnt of common undersnding betwen S and D (regarding the artifact, overal goal, proces, and environment); and (3) the lvel of trust bewn tm.   UBC-ECE: Hsieh, Kruchten, McGregor 9  6.3.3 Execution Exeution is the least problematic part of coordination. S creates or refines U, and makes it avalablo D using the mos appropriate (and avalabl) communicaton mechanim(shown in Figure 2). In doing so, S uss wha he considers the “right” procs but is stil subject to external conditions that my afct his abilty to actualy produc wt he antipas.  6.3.4 Fedback Onc UX is delivered, the discrepancies ΔEx and ΔAx are perceived by D and S, respectively. The question of fedback concerns whetr D makes S aware of ΔEx, when, and how. Fedback mehanism vary aross projcs, aivit, and individuals. Fedbak can be imdiat (e.g., “you are lat,”) or communiction cn proced indirectly (e.g., through mnageent meings). In the global proje, fdback may be msntrpreted, ignored, or exaggeratd, oftn for cultural reasons: saving fa or ctering to an aymrical retionship. Ofn in the distributed sting, theource is never mde awre of ΔEx, or only indirectly and much laer, through a growing lvel of mitrus. To del with this, some softwa organizations have instiutd systematc fdback mechani (e.g., posmorte mengs, retrospecs).  Figure 3: The 3 stages of coordination (the waltz)  6.4 Trust and mistrust When coordination betwen S and D occurs for the first time, they start with some lvel of trus in each other.  This trust capitlθ plays an important role in t forming of both UA and E in the plnning sge. And the trust cpitl is revisd aftr executon. A large discrepancy bewen what is expected and wha i deivered (ΔEx) wil derese the trust capitl, specialy if there i no efint fedback mehanism. On the contrary, a sml ΔEx wil incre trust capitl that D holds for S, θ(D,S). Repeatedly large ΔEx wi deveop the distruso such an intolerabl lvelor D tt D wil no longer collborate with S (i.e., “I’d raher do it myself”).  UBC-ECE: Hsieh, Kruchten, McGregor 10 6.5 Scaling AxE up We have described the AxE coordination model from the perspective of one individual handing an artifat to anotr. But the m can be generalized to interaction betwen large groups of individuals and teams. And it generalizes to more complx or composit rtifcts. Though not explicty std, todel applo coordination in both diributed and collocated ts. In the distributed tam, ti diferencs, physical stancs, and other culural and organizaional fctors afect the forming of UA and UE, he communication modes, and t avalbity and idiay ofdback. Close tention needs to be paid to these fctors when using the AxE model.   7. Data analysi Using the AxE model, we wil revisit the examples preentd in Section 3. 7.1 “How much is enough” revisited In this cae, the coordination centrs on an investigaon conducted by developer D that is to be reportd to mager C. The request to conduc an invesigaon and to submit a writn re (C) is mde explictly by C to D. The quality (Q) and deliry tme (T) asocied with the invetigaon, however, is not explcy sated. Manager C asums tha developer D would be able to deduc t Q and T nesry, basd on pat experinc, currentorkload, and the priority of the requet, among other facors. The coordination endsith a UA[Q,T] that is much greater than UE[Q,T], leding to a largeΔAE and reduced θ(D,S). Manager C considers t ti and efort spent on t investigaon and the report wsted and should have ben spent on more worthwhile work. Manager C starts delgaing this type of work to others (or whom he has a higher θ(D,S) i.e., a higher trust capitl). 7.2 “What are plans for” revisited The mismatch in this cae has to do wh the question of whetr or not plans are to be followed. The ide that the plan wil not be followed i foreign to Company E, while theidea that Company E acualy expects Company F to follow t plan comes a surpris to D.   Examining the isue from a cultural perspective, we find difrencs betwen the two compaes on many levels. The organizational culure of cpany E i one that ishighly proc orintd. In otr words, plns are of great importaen Company E and everyone in the organiztion is expected to be comied to following plans. Comny F, howr, places litle value on the procs documnt and just consders it a hoop to jump through 9. Conclusion No, programers do not behave the same in San Jose, Boston, Budapest or Bangalore. Beyond the isue of language, ti zones and collboraive tools, there i a range of incdent, mihaps, and filures tt are mostly atributablo difencsn culture, in the fundaental va systemha part of the society’s education, politc, organization, and even religion.  UBC-ECE: Hsieh, Kruchten, McGregor 11 Bibliography Beamn, K. V. (2004). Myths, mystiques, and mistake in overseas aignments: The role of global mindset in internaonal work. IHRIM Journal, 40-53. Borchers, G. (2003). The softwar engineering impacts of cultural factors on multi-cultural softwar devlopmnt tams. Paper preentd a the 25th Internaonal Conferenc on Stware Ering (ICSE'03), Portland, OR. Bourque, P., & Dupuis, R. (Eds.). (2001). Guide to the software enginering body of knowldge. Los Almitos, CA: IEE CS Pres. Carmel, E. (1999). Global sofware tams: Collaborating across borders and time zones. Upper Saddle River, NJ: Prentic-Hall. l, E., & Agarwl, R. (2001). Tatl approaches for aleviating distanc in global softwre deopment. IEE Sofware, 18(2), 22-29. Crowton, K. (1997). A coordination theory ah to organiztional proces deign. Organization Scinc, 8(2), 157-175. Damin, D. E., & Moitra, D. (2006). Global software development: How far have we come? IEE Sofware, 23, 17-19. Gibbs, J. L. (2002). Loos coupling in global teams: Tracing the contours of cultural plxity. Unpublished Dsertation, Universty of Soutrn California, LosAngeles Herbslb, J. D., & Grinter, R. E. (1999). Architecures, coordination and distnce: Conway's lw and beyond. IEE Sofwar, 16(5), 63-70. rbslb, J. D., & Moitra, D. (2001). Global software development. IEE Softwar, 18(2), 16-20. Hsieh, Y., MacGregor, E. L., & Kruchten, P. (2005, My 1-4). Intrcultural factors in global software devlopmnt. Paper presentd at the 18th Annual CanadiaConferenc on Elctria and Computr Engineering (CCECE'05), Sskatoon, SK. Karolk, D. (1998). obal sofware devlopmnt: Managing virtual team and nvironmnts. Los Almitos, CA: IEE Computr Socey Pres. raut, R. E., & Streer, L. A. (1995). Coordination in software developmnt. Communications of theCM, 38(3), 69-81. Kruchten, P. (2002, March 15-16). The nature of software--what's so special about software engineering? Paper presntd at the Intrnational Confernc on theScincs of Dsgn -- T Sciefic Chalnge for the 21st Century -- In honour  Hrbert Simon, Lyon, Franc. Kruchten, P. (2004, April 14-16). Putting the "engineering" into "software engineering". Paper presentd at the Ausralan Software Ering Confrenc (ASWEC 2004), Mlbourne, Ati. Malone, T. W., & Crowston, K. (1994). The interdisciplnary study of coordination. ACM Computing Survey, 26(1), 87-119. sey, A. P., Montoya-Wis, M. M., & Hung, Y. T. (2003). Because tim maters: Tmporal coordinaton in global virtual project tams. Journal of ManagentInforation Sysem, 19(4), 129-155. Olson, J. S., & Olon, G. M. (2004). Culture surpris in reote software development teas. ACM Que, 1(9), 52-59.  UBC-ECE: Hsieh, Kruchten, McGregor 12 Sahay, S., Nicholson, B., & Krishna, S. (2003). Global it outsourcing: Software developmnt acros border. Cambridge, UK; New York: Cambridge University Pres. Sarker, S., & Sahay, S. (2004). Implicatons of spac and ti for distributed work: An interpretive study of us-norwegin systes development ta. European Journal of Informaton System, 13(1), 3-20. Sathyanarayan, M. M. (2003). Ofshor devlopmnt--provn stratgies and tactics for succes (1 ed.). Cupertino, CA: GobaDev Publ. imon, H. (1996). The sciencs of the artifcal (3 ed.). Cambridge, Mas.: The MIT Pres. Spencer-Oatey, H. (2000). Culturally speaking: Managing rapport through talk across culurs. Nw York: Case. tandish Group. (1995). The chaos rport. West Yarmouth, MA: The Standish Group. Sndiroup. (2001). ExtrmYourdon, E. (2004). Outsource: Competing in the global productivy race. Upper Saddle River, N.J.: Prenti-Hall.  


Citation Scheme:


Usage Statistics

Country Views Downloads
China 16 0
Germany 12 1
United States 9 0
Canada 8 0
Russia 5 0
India 2 0
France 1 0
Malaysia 1 0
City Views Downloads
Unknown 21 1
Beijing 10 0
Shenzhen 6 0
Vancouver 6 0
Sunnyvale 5 0
Ashburn 3 0
Kuala Lumpur 1 0
Redmond 1 0
Richmond 1 0

{[{ mDataHeader[type] }]} {[{ month[type] }]} {[{ tData[type] }]}
Download Stats



Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            async >
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:


Related Items