Christian Koch
email: christian.koch@chalmers.se

Claus Jørgensen

Martin Olsen

Torben Tambo

We all know how, don't we? On the role of Scrum in IToffshoring

Keywords: Offshoring, Scrum, Agile, Routines 1

Offshoring in the IT-industry involves dual interactions between a mother company and an external supplier, often viewed with an implicit perspective from the mother company. This article review general off shoring and IT offshoring literature, focusing on the proliferation of a globally available set of routines; Scrum and Agile. Two cases are studied; a small company and short process and a large mother company with a long process. The interactions of the set ups shows that global concepts like Scrum and Agile are far from a common platform. The "well known" concepts are locally shaped and the enterprises have mixed experiences.

Introduction

The global IT industry has for quite some time used offshoring of activities as part of a costcutting strategy, however as transaction approaches dominates, the results remain ambiguous [START_REF] Lacity | Outsourcing business processes for innovation[END_REF][START_REF] Lampel | Living with offshoring: The impact of offshoring on the evolution of organizational configurations[END_REF]. It can hardly be claimed to be underilluminated what the challenges of offshoring are well illuminated, in the general literature on offshoring [START_REF] Bunyaratavej | Conceptual Issues in Services Offshoring Research: A Multidisciplinary Review[END_REF][START_REF]The Offshoring Challenge: Strategic Design and Innovation for Tomorrow's Organization[END_REF], as well as the IT literature is ripe with studies [START_REF] Jayatilaka | Changes in IT-sourcing arrangements -an interpretive field study of technical and institutional influences[END_REF][START_REF] Lacity | A review of the IT outsourcing literature: insights for practice[END_REF][START_REF] Lacity | A review of the IT outsourcing empirical literature and future research directions[END_REF][START_REF] Lacity | Business process outsourcing studies: a critical review and research directions[END_REF][START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF][START_REF] Willcocks | The practice of outsourcing: from information systems to BPO and offshoring[END_REF]. Across these there are common understandings pointing at the importance of transfer of routines and knowledge between the mother company and the supplier [START_REF] D'adderio | Crafting the virtual prototype: how firms integrate knowledge and capabilities across organisational boundaries[END_REF][START_REF] Jørgensen | Offshore supplier relations: knowledge integration among small businesses Strategic Outsourcing[END_REF].

The focus on routines and knowledge, "incidently" overlap with another approach to innovative organisational change, that of management innovation [START_REF] Birkinshaw | Management Innovation[END_REF][START_REF] Knights | Organization and innovation: guru schemes and American dreams[END_REF]. This stream of literature studies how concepts take the role of globally spreading fashions including their proposal for changed routines and their inbuilt knowledge. Such a globally spreading concept is "Scrum" [START_REF] Schwaber | Agile Software Development with Scrum[END_REF][START_REF] Sutherland | The Scrum Papers: Nuts, Bolts, and Origins of an Agile Method[END_REF], usually accompanied with "Agile" [START_REF] Conboy | Agility from first principles: Reconstructing the concept of agility in Information Systems Development[END_REF][START_REF] Misra | Identifying some important success factors in adopting agile software development practices[END_REF]. Scrum is argued to be producing high productivity software development through incremental delivery of working code and is adopted by a number of international players and researched in extenso [START_REF] Dingsøyr | A decade of agile methodologies: Towards explaining agile software development[END_REF]. Agile principles value collaboration and communication over processes, tools and contracts as well as working software (artefacts) over comprehensive documentation [START_REF] Conboy | Agility from first principles: Reconstructing the concept of agility in Information Systems Development[END_REF][START_REF] Hummel | The Role of Communication in Agile Systems Development[END_REF][START_REF] Sahar | Communication Tools in Offshore Development with Scrum[END_REF]. Together Scrum and Agile represents, a global available concept, a bundling of recommended routines and know how on carrying out the management of software development. The process of using a global concept in the offshoring interaction between mother company and supplier could be perceived as a provision of a common known approach [START_REF] Gupta | Leveraging temporal and spatial separations with the 24hour knowledge factory paradigm[END_REF].

As transfer of routines and knowledge are claimed to be crucial to offshoring, this article aims at an empirical analysis of two cases using the same routine and knowledge (Scrum and Agile). The two empirical cases enable a cross case comparison of offshoring types: the small enterprise with a short-medium term and complex project, versus the large enterprise with large volume, long term and simple cooperation.

The article contributes to the understanding of the use of Scrum and Agile in distributed software development as well as innovative models and approaches for managing complexity and multiplicity, by investigating the role of the standardized routine and knowledge in global concepts engaged in local contexts, and it underlines the difficulties of cultural exchange, mutual iterative learning, and issues tackling distance across boundaries.

The structure of the article is the following: An opening introduction and a subsequent theoretical review and frame, method discussion, two cases, discussion and analysis.

Theory Frame

The theoretical frame is developed in three steps. First a general discussion on offshoring studies. Second a review of IT-offshoring studies and third a presentation of Scrum and Agile as a global concept for managing standardized routines and knowledge.

General studies of offshoring is dominated by various types of business economics such as transaction cost theory [START_REF] Bunyaratavej | Conceptual Issues in Services Offshoring Research: A Multidisciplinary Review[END_REF], agency theory [START_REF] Aubert | A Framework for Information Technology Outsourcing Risk Management[END_REF], the knowledge based theory of the firm [START_REF] Grant | Prospering in dynamically-competitive environments: organizational capability as knowledge integration[END_REF] and the resource based view [START_REF] Hätönen | 30+ years of research and practice of outsourcing -Exploring the past and anticipating the future[END_REF]. Further studies introduce sociological and psychological explanations [START_REF] Abbott | From boundary spanning to creolization: A study of Chinese software and services outsourcing vendors[END_REF][START_REF] D'adderio | The performativity of routines: Theorising the influence of artefacts and distributed agencies on routines dynamics[END_REF][START_REF] Heiskanen | Control, trust, power, and the dynamics of information system outsourcing relationships: a process study of contractual software development[END_REF][START_REF] Ågerfalk | Flexible and Distributed Information Systems Development: State of the Art and Research Challenges[END_REF]. In early empirical studies of Danish companies [START_REF] Maskell | Learning paths to offshore outsourcing: from cost reduction to knowledge seeking[END_REF][START_REF] Praest Knudsen | Outsourcing i mindre danske virksomheder[END_REF] it appears to show that cost reduction was a key motive in those year whereas [START_REF] Jensen | A learning perspective on the offshoring of advanced services[END_REF][START_REF] Jensen | A passage to India: A dual case study of activities, processes and resources in offshore outsourcing of advanced services[END_REF][START_REF] Koch | Strategic Sourcing Development-Emerging Resource Combination and Knowledge Interaction[END_REF] provide examples of more profound long term business transformation of Danish service and manufacturing companies. Internationally studies of offshoring are split in a similar manner [START_REF] Lacity | Outsourcing business processes for innovation[END_REF][START_REF] Lampel | Living with offshoring: The impact of offshoring on the evolution of organizational configurations[END_REF][START_REF] Bunyaratavej | Conceptual Issues in Services Offshoring Research: A Multidisciplinary Review[END_REF]. A German study by Westner and Strahringer [36] thus exhibit focus on cost reduction. Whereas [START_REF] Mcivor | How the transaction cost and resource-based theories of the firm inform outsourcing evaluation[END_REF][START_REF] Bengtsson | The integrator's new advantage -the reassessment of outsourcing and production competences in a global telecom firm[END_REF][START_REF] Lewin | Why are companies offshoring innovation? The emerging global race for talent[END_REF] indicate resource-based dimensions also occur as motives for sourcing decisions, partly including knowledge integration.

In this article our focus is in line with Nelson & Winter's [START_REF] Nelson | An Evolutionary Theory of Economic Change[END_REF] notion of the importance of routines and knowledge in the development of firms. Accordingly the knowledge-based theory of the firm maintains that "the primary role of the firm, and the essence of organizational capability, is the integration of knowledge" [START_REF] Grant | Prospering in dynamically-competitive environments: organizational capability as knowledge integration[END_REF]. Knowledge integration occurs through two primary mechanisms, identified by [START_REF] Grant | A knowledge assessing theory of strategic alliances[END_REF]: direction of Demsetz [START_REF] Demsetz | The theory of the firm revised[END_REF] and organizational routines of Nelson and Winter [START_REF] Nelson | An Evolutionary Theory of Economic Change[END_REF]. Direction occurs, through management, when "firms convert sophisticated knowledge into directives, rules and operating procedures that can be imposed by authority based relationships" while organizational routines "are complex patterns of co-ordination that permit different specialists to integrate their knowledge into the production of goods and services while preserving the efficiencies of knowledge specialization" [START_REF] Pollock | Post local forms of repair: The (extended) situation of virtualised technical support[END_REF][START_REF] Roberts | Offshoring: individual short-term gain versus collective long-term loss?[END_REF]. Both mechanisms become more complex when IT-firms offshore their product development operations since specialists may be separated by time, space and sociocultural settings outside the usual organisational routines. Authority-based relationships tend to rupture when product development is not only offshored, but also outsourced. New directions and new organisational routines have to be established to manage the new relations created through the offshoring. In the focal firm, heavier demands on coordination capabilities regarding knowledge integration intra-and interorganisationally arise due to increased complexity when handling the sociocultural, physical and time distances. In a global offshore context "performativity struggles between competing agencements lead to their mutual adjustment involving (temporary) predominance of a strong programme, or the emergence of a new programme from the coexistence/assemblage of different ones" [START_REF] D'adderio | The performativity of routines: Theorising the influence of artefacts and distributed agencies on routines dynamics[END_REF]. In the cases to follow such a development and adjustment of a strong programme (the agile and scrum methods) will be identified in both cases due to the challenges regarding mainly geographical and sociocultural differences between the actors, and being mainly initiated by the focal company and at least in one of the cases finishing as indicated by D'Adderio (resulting stability) [START_REF] D'adderio | The performativity of routines: Theorising the influence of artefacts and distributed agencies on routines dynamics[END_REF] and Nelson and Winter (truce) [START_REF] Nelson | An Evolutionary Theory of Economic Change[END_REF].

According to Carlile [START_REF] Carlile | Transferring, translating, and transforming: an integrative framework for managing knowledge across boundaries[END_REF], knowledge integration can be divided into three increasingly complex processes: transfer, translation and transformation. As part of the initial transfer of technologies, codified or codifiable knowledge is transferred. In the second phase, the goal is to make the tacit knowledge of the sender explicit through translation and integration of the knowledge at the receiving end. This process builds capabilities at the receiving end for exploiting knowledge originally generated by the sender. The last step augments knowledge, where the sender's original knowledge is transformed into new products and processes at the receiving end. The demands on the organizational routines and direction of the organizations in the process of integrating knowledge increase when companies begin the translation and transformation processes. In the cases to follow, we find at least a move to local translation of the global concepts of Agile and Scrum during the offshoring process.

Finally it should be noted, that a majority of the studies of offshoring assume a mother company perspective [START_REF] Pagano | The role of relational capabilities in the organization of international sourcing activities: A literature review[END_REF] [START_REF] Kedia | Understanding offshoring: A research framework based on disintegration, location and externalization advantages[END_REF][START_REF] Tambo | Offshoring -the new dilemma of IS research[END_REF][START_REF] Khan | Barriers in the selection of offshore software development outsourcing vendors: an exploratory study using a systematic literature review[END_REF]. It is thus the offshoring company which possesses the knowledge and routines needed for the establishment of the offshoring activity.

IT-Offshoring

When IT companies offshore their product development, their challenges follows broadly the same patterns as discussed above. Also IT-offshoring studies are spread over a number of positions [START_REF] Cummings | Crossing Spatial and Temporal Barriers in Globally Distributed Projects: A Relation Model of Coordination Delay[END_REF][START_REF] Contractor | Reconceptualizing the Firm in a World of Outsourcing and Offshoring: The Organizational and Geographical Relocation of High-Value Company Functions[END_REF]. Here we choose to organise the literature into two streams according to their view on transfer of knowledge and routines. One position, the rational technical approach represented by Lacity et al. [START_REF] Lacity | A review of the IT outsourcing literature: insights for practice[END_REF], claims that routines and knowledge should be transferable, as they are well described and formalised [START_REF] Lacity | A review of the IT outsourcing literature: insights for practice[END_REF].

Another position argue that the development of routines in setting which is not colocated anymore should be seen through the community of practice lenses and therefore in a situated manner [START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF][START_REF] D'adderio | The performativity of routines: Theorising the influence of artefacts and distributed agencies on routines dynamics[END_REF]. Lacity et al [START_REF] Lacity | A review of the IT outsourcing literature: insights for practice[END_REF] adopt a realist position equalising a number of features including routines and practices acrosss settings. This review counts 191 articles on IToffshoring from 1991 to 2009. The factorial splitting, enable them to count and measure experiences of offshoring in terms of for example firm size, degree of outsourcing, the role of IS technical/methodological capability as well as business process outsourcing. These aspects are however not transcended much further. Similar results occur in contributions like [START_REF] Straub | Strategic dependence on the IT resource and outsourcing: a test of the strategic control model[END_REF]. In a parallel publication Willcocks & Lacity [START_REF] Willcocks | The practice of outsourcing: from information systems to BPO and offshoring[END_REF] argue for two significantly different periods of outsourcing in the IT sector, one from the 1990s and another from 2000 and on. In the last period offshoring has become prevalent. In this volume (and elsewhere) the authors advocate the notion of "configuration" to help describe and manage offshoring [START_REF] Willcocks | The practice of outsourcing: from information systems to BPO and offshoring[END_REF]. Offshoring components in the configuration include the scope of IT, supplier grouping, financial aspects, duration and commercial relationships.

Vaast and Walsham [START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF] take a different position adopting an interpretive casebased position. They argue that distributed interactions should be viewed through practice-based learning theory [START_REF] Brown | Organizational Learning and Communities-of-Practice: Toward a Unified View of Working, Learning, and Innovation[END_REF]. As point of departure they acknowledge that situated learning is impaired by the lack of collocation. However Vaast & Walsham [START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF] propose a concept of transsituated learning, and thereby arrive relatively close to Carlile's understanding [START_REF] Carlile | Transferring, translating, and transforming: an integrative framework for managing knowledge across boundaries[END_REF] discussed above. Vaast and Walsham [START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF] emphasise that the translation and transformation of knowledge does not "just occur", but has to emerge. In prolongation of this D'Adderio [START_REF] D'adderio | The performativity of routines: Theorising the influence of artefacts and distributed agencies on routines dynamics[END_REF] in her discussion of transfer of routines, point at the performativity of (standard) routines, as the mutual adaption between the routines and actual performing of processes and practices both converge and diverge in interactive processes. A discussion of the standard routine is as we shall see prevalent in studies of Scrum and Agile in distributed environments [START_REF] Lee | Distributed agile: project management in a global environment[END_REF].

Scrum and Agile

In this section we describe the global variant of Scrum and Agile. The primary objective for agile methods is to be able to cope with uncertainty as an alternative to traditional plan-driven methods [START_REF] Dingsøyr | A decade of agile methodologies: Towards explaining agile software development[END_REF]. Agile software development methods [START_REF] Misra | Identifying some important success factors in adopting agile software development practices[END_REF] share the principles in the agile manifesto written by 17 experienced practitioners in 2001 (http://agilemanifesto.org). The principles emphasize collaboration and communication between individuals more than processes, tools and contracts, and they focus on working software over comprehensive documentation [START_REF] Sahar | Communication Tools in Offshore Development with Scrum[END_REF][20][22] [START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF]. One of the most popular agile methods is Scrum [START_REF] Schwaber | Agile Software Development with Scrum[END_REF] where a key element is incremental delivery of working code. A prioritized product backlog with high-level descriptions of potential features of the system to be developed is maintained throughout the Scrum process. The process is iterative and organized in so called sprints (typically a few weeks) where the objective of a sprint is to develop the feature currently at the top of the product backlog. The outcome of a sprint is an increment of the system to be developed -this increment is evaluated with the stakeholders and the product backlog might be changed at this phase. A so called product owner represents the customer throughout the process and a Scrum master facilitates the process in order to keep it on the right track. As for all agile methods the system to be developed becomes the key object for the communication among the parties involved [START_REF] Hummel | The Role of Communication in Agile Systems Development[END_REF][START_REF] Sahar | Communication Tools in Offshore Development with Scrum[END_REF]. The Scrum method also sets up a framework for how meetings are organized and it may be combined with ingredients and practices from other agile methods such as XP [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF].

Scrum and Agile in distributed settings

We now turn to related work on the use of agile methods in a distributed setting with respect to geography and culture [START_REF] Lee | Distributed agile: project management in a global environment[END_REF]. Iivari & Iivari [START_REF] Iivari | The relationship between organizational culture and the deployment of agile methods[END_REF] have proposed suggestions for deployment of agile methods in cross cultural environments. Duan et al. [START_REF] Duan | Identifying key factors affecting transnational knowledge transfer[END_REF] looks into the required trans-national knowledge transfer. Uy and Ioannou [START_REF] Uy | Growing and Sustaining an Offshore Scrum Engagement[END_REF] describe how their company Kelley Blue Book uses "The Five Dysfunctions of a Team"model by Patrick Lencioni to help set up offshore Scrum development teams in India and China. Sutherland et al. [START_REF] Sutherland | Fully Distributed Scrum: Replicating Local Productivity and Quality with Offshore Teams[END_REF] show that distributed Scrum teams can obtain "… the same velocity and quality as a colocated team …" and Kussmaul et al. [START_REF] Kussmaul | Outsourcing and Offshoring with Agility: A Case Study[END_REF] report "lessons learned" on a case of a development project with a distributed Scrum team. The findings in these papers [START_REF] Lee | Distributed agile: project management in a global environment[END_REF][START_REF] Uy | Growing and Sustaining an Offshore Scrum Engagement[END_REF][START_REF] Sutherland | Fully Distributed Scrum: Replicating Local Productivity and Quality with Offshore Teams[END_REF][START_REF] Kussmaul | Outsourcing and Offshoring with Agility: A Case Study[END_REF] indicate that it is possible and beneficial to use agile methods in an onshore/offshore distributed setting, although [START_REF] Ionel | Critical Analysis of the Scrum Project Management Methodology[END_REF] summarizes various concerns. Discussing global software development (GSD) [START_REF] Holmström | Agile Practices Reduce Distance In Global Software Development[END_REF][START_REF] Ågerfalk | Outsourcing to an Unknown Workforce: Exploring Opensourcing as a Global Sourcing Strategy[END_REF] claim that "… the more common view is that agile methods are not applicable " in a context of global development (GSD), but nevertheless arrive at a more positive conclusion suggesting among other things that "… agile methods may be more amenable to GSD than has been previously reported".

Offshoring of services particularly digital, professional services in the IT sector has become increasingly popular. Virtual development teams are largely regarded to increase organizational development capability [START_REF] Vaccaro | The impact of virtual technologies on knowledgebased processes: An empirical study[END_REF][START_REF] Sakthivel | Virtual Workgroups in Offshore Systems Development[END_REF]. Lampel and Bhalla [START_REF] Lampel | Living with offshoring: The impact of offshoring on the evolution of organizational configurations[END_REF][START_REF] Lampel | Embracing realism and recognizing choice in IT offshoring initiatives[END_REF][START_REF] Bhalla | Is more IT offshoring better? An exploratory study of western companies offshoring to South East Asia[END_REF] discuss various pitfalls and models for IT offshoring, and [START_REF] Lampel | Living with offshoring: The impact of offshoring on the evolution of organizational configurations[END_REF] provide a longitudinal study of IT project offshoring with a continual low cost focus; [START_REF] Chatfield | IT Offshoring Risks and Governance Capabilities[END_REF] contribute with the aspect of risk management in IT offshoring. Culture and geography is widely recognized as an influencing factor on software engineering [START_REF] Jaakkola | Knowledge-oriented software engineering process in a multi-cultural context[END_REF][START_REF] Niederman | IT Software Development Offshoring: A Multi-Level Theoretical Framework and Research Agenda[END_REF][START_REF] Gregory | Review of the IS Offshoring Literature: The Role of Cross-Cultural Differences and Management Practices[END_REF]. Deng & Zhao [START_REF] Deng | Control, Affect and Cognition Trust in Determining IT Offshoring Outsourcing Service Quality[END_REF] describe a shift from informal to formal control to improve delivery quality.

It derives from the above presentation that studies of Scrum and Agile in offshoring and similar constellation are rich with discussions on the use of the globally presented concept. However the understanding of the concepts varies significantly, probably because specific contextual interpretations of Agile principles, Scrum methods and even XP programming occur. Moreover the challenges regarding the concepts of Scrum and Agile as being mainly promoted by consultants, professional press and education institutions, and thereby often more loosely coupled to the enterprises are not discussed.

Method

The article places itself within the multidisciplinary IS-research with an overarching interpretive approach [START_REF] Walsham | Doing interpretive research[END_REF]. The review and theoretical frame encompasses contributions from IS-research focusing on offshoring [START_REF] Lacity | A review of the IT outsourcing literature: insights for practice[END_REF] as well as on Agile and Scrum [START_REF] Schwaber | Agile Software Development with Scrum[END_REF], business economics [START_REF] Mcivor | How the transaction cost and resource-based theories of the firm inform outsourcing evaluation[END_REF], and sociological approaches such as [START_REF] Carlile | Transferring, translating, and transforming: an integrative framework for managing knowledge across boundaries[END_REF][27] [START_REF] Vaast | Trans-situated learning: supporting a network of practice with an information infrastructure[END_REF]. These approaches are used in mutually complementary manner, using a soft multidisciplinary synthesis [START_REF] Gioa | Multiparadigm Perspectives on Theory Building[END_REF].

The cases were selected due to the author group's insight in the two companies based on two authors being employed in each of the companies respectively. The experiences from the two companies as presented by two of the authors seemed at the outset to provide an interesting tension of difference. The clear limitation of selecting and developing the cases in this manner leads to a need to lend support from the method literature on autoethnography [START_REF] Cunningham | Autoethnography: a tool for practice and education[END_REF][START_REF] Lapadat | Writing our way into shared understanding: Collaborative Autobiographical Writing in the Qualitative Methods Class[END_REF]. It should moreover be noted that both cases build on ex post reflections on the offshoring processes, and not on ex ante decisions to research on offshoring. In the development of the case analysis, given the two authors close ties to the cases with regular participation in the companies, two approaches were used; a strong element of, first securing a distinction between the 'information insider' and the 'analyst outsider' [START_REF] Cunningham | Autoethnography: a tool for practice and education[END_REF], and second an intercollegial challenging of the work experiences in the broader author group was carried out [START_REF] Lapadat | Writing our way into shared understanding: Collaborative Autobiographical Writing in the Qualitative Methods Class[END_REF]. It has been chosen in the description and analysis not to enter more detailed references to the sources used by the authors directly involved in the cases. Their memory and point of view is therefore thoroughgoing and counterbalanced by the author teams external perspective. As a final limitation, the ideal research approach given our emphasis on the emergent character of implementing routines and knowledge, spanning the mother company and the supplier, would probably be "global ethnography" as suggested by [START_REF] Burawoy | Global Ethnography: Forces, Connections, and Imaginations in a Postmodern World[END_REF], lending equal voice to the two settings investigated, rather as it is done here, with point of departure in the (Western) mother company. It can be noted however, that in one case the author employed has visited the receiving organisation, and in the other the author employed has been closely following the offshoring process.

Cases

Case A. HouseCo offshoring to Ukraine

HouseCo is a Danish company running a web site offering users the possibility to book a holiday home in Europe. The company employs 11 people and the web site contains roughly 100.000 European holiday homes. In Q2 2009 HouseCo decided to upgrade the search infrastructure of their web site in order to meet future demands for search efficiency and flexibility. The project is a relatively complex development task and the initial estimate on manpower needed for the project was 2 man-years assuming the project was to be handled in-house, but due to other projects HouseCo could not allocate the man power in-house so extra man power was needed. In 2009 the demand of local and qualified IT developers was high so HouseCo decided to contact a Danish company SourceCo. Through the company SourceCo, a Ukrainian development team dedicated to the project, was set up in Kiev. Following one of the agile principles, it was decided not to base the work on a contract specifying the software to be developed, and the Ukrainian team -consisting of approximately 6 people on average -was paid by the hour instead.

According to HouseCo the Ukrainian educational system does not seem to have "matured" with respect to teaching system development. Almost all of the members of the Ukrainian development team have university degrees at the master level but not necessarily IT related degrees -and if the degree is in IT the degrees have a narrow technical perspective. Two HouseCo employees, including the scrum-master, made regular visits to Kiev and two visits to Denmark for members of the Ukrainian team were organized as well. Scrum has been used to manage the development process.

HouseCo neither consider the project as a "success" nor a "failure" with the HouseCo Scrum master leaning more towards "failure" and the CEO estimating the outcome somewhere in between. The cost of Ukrainian man power is roughly 60 % in average (including the share of the broker company SourceCo) compared to the cost of manpower in HouseCo. The development time exceeds the initial estimate. The initial estimate is also characterized as "very optimistic". The agile approach with extensive involvement and regular visits by the HouseCo employees is characterized as "absolutely crucial" by HouseCo. According to the Scrum master HouseCo was not mature using agile methods internally when diving into the onshore/offshore variant. As an example the very important processes of specifying the features to implement in the sprints and evaluating the resulting increments were improved a lot as the development process went along. In the beginning the communication was oriented towards the technical architecture and written code. A more user-oriented perspective replaced the technical perspective later where the feature(s) to be implemented in a sprint were specified by scenarios telling exactly how the system should react on specific inputs. In other words, the brokering of the information should be done upfront, as needed information had to be conveyed in the beginning of the development process. The Scrum frame was too unclear and thin at the beginning of the process but all in all the development process resembled the Scrum model. The distributed setting made it necessary to focus more on written as opposed to verbal communication compared to the non-distributed setting.

The HouseCo people sometimes had the impression that the members of the offshore development team had a fine understanding of what was to be developed for the next sprint but later it turned out not to be the case. Besides the initial unclear Scrum frame, communication difficulties also have triggered the problems. As an example video-conferences did not work nearly as well as the face-to-face meetings. According to HouseCo there appears to be a "yes-sir"-culture offshore where the members of the development team are not persistent enough in trying to reach an understanding of the goals of a sprint so the sociocultural distance also constituted a problem. The offshore team tried to "impress" the HouseCo people in some of the sprints leading to increments failing the tests -the HouseCo people were disappointed and the communication suffered.

HouseCo succeeded to hire local man power and decided to finish the project inhouse finishing the offshore activities primo 2010. There have been many obstacles along the way but by using an agile approach a reasonable result has been obtained that forms the basis of the ongoing work in-house. The flexibility of the man power allocation is seen as the major advantage of the approach used and HouseCo questions that the project could have been solved fully in-house since the demand of qualified and local IT personnel was very high at the time the project was launched. HouseCo will be very careful, if the company should offshore software development in the future, but if the company decides to do so, HouseCo is convinced an agile approach will be chosen again. The lessons learned from the project presented above have led to an increased maturity inhouse regarding conducting the Scrum process that would help to avoid at least some of the problems discussed above. On the other hand, the lessons learned have improved the agile skills of the HouseCo developers so they now produce high quality code efficiently according to their Scrum master.

Case B: TexCo outsourcing to India

TexCo is a Danish trading company within the consumer goods sector with a turnover of 2 billion EUR, and 14,000 customers in 45 countries. The IT Department at the local TexCo headquarter consisted of 150 employees in 2005, but was facing an increased requirement for further IT resources within development, maintenance and operations activities. An increase in internal staffing was considered, as well as various options for relying upon existing relationships to local consultancies to fulfill the need for further resources. Based on traditions for buying physical products in India, the CEO asked the IT management to start using Indian offshoring to access further IT-resources. Captive offshoring (a fully owned subsidiary) was considered, but disregarded in favor of an independent company. As a result of a former relationship, SoftCo in Maharashtra, India was chosen. SoftCo had at this time approximately 2000 employees, representation offices in several European and US cities, and had experienced 25% annual growth rates.

The relationship was initiated with a startup meeting at TexCo's premises in Denmark, where SoftCo presented the expected trading/legal documents, and suggested a competitive pricing scheme. SoftCo explicitly defined themselves as a service company delivering resources to the customers opposed to a traditional software development company. An agreement to establish a team of Full Time Equivalent (FTE) resources was reached. FTE means that the employees from SoftCo were allocated to TexCo for all working hours reasonably billable; SoftCo contributed with internal time registration systems and a detailed planning system, whereas TexCo was expected to formally allocate resources and track project progress using regular project management tools.

Mid-2005 two employees from SoftCo started at TexCo's headquarter to gather information for tasks to come: Development of reports (database queries, graphical formatting) was chosen as the first initiative. From two employees the relationship grew to 80 employees over the next 24 months. The dominant background of the SoftCo employees was 3 to 18 months of working experience as B.Sc.´s in Computer Science. Managers were promoted from this group further including 3 -4 more experienced project managers for the overall engagement. Activities were during the growth aligned with the organization of employee activities within TexCo's IT Department, and mutual teams were grouped within the areas of Java development, Reports development, Integration Services development and operation, Standard ERP maintenance and operations, and IT Operations -mainly database server monitoring and problem resolution. The development activities are further discussed below.

The development oriented assignment accounted for around 60 of the team members. After 30 months of growth TexCo's functional and technical project managers were questioning the outcome and cost of the cooperation. Deadlines from SoftCo were repeatedly delayed. There were severe quality issues with delivered software. Training given by TexCo staff at SoftCo's premises did not seem to help. Guidelines and requirement specifications were not followed in detail. A number of "proof of concept" projects yielded no results only further cost. Relationships decayed with the supplier of standard ERP, development tools, and server technologies, and SoftCo failed to maintain relationships with their suppliers during this conflict as well as failing to include experiences from other clients. A review on staff experience showed that SoftCo largely exaggerated working experience of the associates. Something needed to be done within Texco's IT department, otherwise the situation would become a subject for the top level management requiring their intervention.

The project management team of TexCo had over time followed professional discussions on governance and management of IT development projects. The team decided to receive training in and implement Scrum on internal and external delivery processes. Five project managers obtained Scrum Master Certification. For some months Scrum was tested only on internal project deliverables with whiteboards and physical meetings in TexCo's offices. It was very well received by developers and project managers. Emphasis was given on micro-planning (day-to-day and sprint), issue resolution -with users or other technical staff, and self estimation.

TexCo made a plan for SoftCo that required most development activities to switch to Scrum. It was initially assumed, that a number of the learnings from the internal use of Scrum could not be transferred identically due to the time difference of 4.5 hours between Denmark and India. It was ideally expected, that Scrum would speed up the delivery pace from SoftCo and satisfy TexCo's project managers on cost and delivery issues. TexCo's Scrum Masters undertook the training of SoftCo's staff in SoftCo's offices.

In moving from and internal use of Scrum to Scrum in offshoring, a number of issues were created. The micro-planning aspect shifted face-to-face contact among developers, projects managers and product owners, to daily Scrum meetings at the offices of the offshoring company, where product owner and teams with in-depth knowledge could not play the same role. In issue resolution, internal Scrum projects had immediate access to product owners, and deep insight in technology and business, and therefore excellent opportunities for making high precision sprint estimation. In the offshoring case, interaction inevitably became secondary causing lost transparency, again creating confusion and tensions. Furthermore mis-estimations were mostly the case. The Scrum routines developed by the internal Scrum activities resembled strongly the culture and behaviour normally utilized at Texco, and the offshoring teams abroad had difficulties in mimicking this. The loyalty of internal teams to "play the game" was based on the project managers and immediate users; loyalty and readiness. In the offshored scrum activities on the other hand this turned more towards satisfying local managers and customer managers compared to accomplishing the requirements of the customer.

TexCo's project managers started to use sprint time estimation between internal and Indian developers in allocation of assignments, and proforma business cost quotations. Changes in development policy at the same time meant less development assignments. The FTE agreement was loosened, so TexCo no longer had to pay for under-utilized resources at SoftCo. The business between the two parties continued at a lower, but more transparent level.

TexCo saw Scrum as one of several methods for creating agile development projects as it was also supported by formalised training. TexCo sought to use an agile approach to improve the business' acceptance of proposed software, and to 1) improve the overall project management's insight into business requirements and other constraints -and 2) improve adaption to the former by having shorter and more standardised cycles introduced in the development process. Furthermore, the offshore team's progressive understanding was expected to improve concerning the basic technology, the business requirements, and the solution design. Scrum should thus balance between (1) necessary breaks to adjust to the understanding of the required outcome, (2) the control of resources spend by the self-estimation and the explanations given in case of wrong self-estimation.

It never became clear to Texco actors if SoftCo had actual past experience with Scrum. Despite TexCo's open-mindedness regarding purchasing in Asia, the quality lens for software was far different from garment, the core business of TexCo. The business relationship both during the ramp-up and the stable phases had an element of crisis management to it. Constantly new "incidents" were brought up. Scrum was a mediation toole in the mutual conflicts over blame/success. TexCo's main successes with software consultancies were mainly achieved with smaller teams of highly dedicated and skilled people, i.e. directly resembling and reflecting TexCo's own organization and culture, and making tools like Scrum superficial. This constitutes a pattern of routines within TexCo hard to transfer to offshore collaboration partner. SoftCo had much less issues with other customers, and has sustained its growth with by end of 2013 more than 8.800 employees.

Discussion

The cases are addressing the issue of agile and scrum as a target of distributed organizational learning [START_REF] Brown | Organizational Learning and Communities-of-Practice: Toward a Unified View of Working, Learning, and Innovation[END_REF][9] as both hosting organization were unexperienced in agile and scrum prior to the described development process cases. The cases suggest a general issue of agile and scrum as colloquialisms rather than institutionalized routines [START_REF] Jayatilaka | Changes in IT-sourcing arrangements -an interpretive field study of technical and institutional influences[END_REF].

The process of the cases assumed a fast track to routinisation of agile and scrum mechanisms that proved more problematic than expected by the involved parties.

Furthermore both cases seem to focus on, but generally fail to reach, a dualism of organizational learning involving both the onshore and the offshoring organization [START_REF] Jørgensen | Improving offshoring of lowbudget agile software development using the dual-shore approach: an autoethnographic study[END_REF][69] [START_REF] Jaakkola | Knowledge-oriented software engineering process in a multi-cultural context[END_REF]. In Texco previous methods were rather haphazard and Agile and scrum offers itself in by articulating the existence of a development method [START_REF] Deng | Control, Affect and Cognition Trust in Determining IT Offshoring Outsourcing Service Quality[END_REF] and transferring sporadic and unstructured communication and collaboration [START_REF] Sahar | Communication Tools in Offshore Development with Scrum[END_REF][20] into routines although aspects of learning and "mental" embedding of routines seem overlooked in the cases. Scrum and Agile have been around as a global standardised routine "offer" for around ten years. Nevertheless our cases show that the assumption that this might act as a common denominator, a common know how, in an offshoring process seems to be overestimated. Scrum and Agile unfolds in the case in ways, where these principles fail to perform as common understanding [START_REF] D'adderio | The performativity of routines: Theorising the influence of artefacts and distributed agencies on routines dynamics[END_REF], neither as brokerage nor as boundary objects [START_REF] Carlile | Transferring, translating, and transforming: an integrative framework for managing knowledge across boundaries[END_REF]. Failure of both the sending and receiving organization to comply with the demands within the standardized routine are mainly due to barriers at both ends to translate tacit knowledge during the development process [START_REF] Jørgensen | Offshore supplier relations: knowledge integration among small businesses Strategic Outsourcing[END_REF] directed by the chosen standardized routine as well as managing the identified roles (i.e. the scrum master and more) supporting the interorganisational coordination part supplementing the standardized routine. The concepts turn out to be too general and unprecise. In the HouseCo case this occurred as difficulties when specifying the early sprints, and in the TexCo Scrum routines became dependent of intraorganisational tacit knowledge, developed as TexCo felt they need more routines than the described. This is a result paralleled by [START_REF] Holmström | Agile Practices Reduce Distance In Global Software Development[END_REF], which witness a "filling out" by XP methods [START_REF] Beck | Extreme Programming Explained: Embrace Change[END_REF][START_REF] Holmström | Agile Practices Reduce Distance In Global Software Development[END_REF]. Moreover it remains unclear in the processes of Houseco and Texco to what extent the suppliers actually master Scrum and Agile and what type or variant they embraced. Scrum and agile methods act as primarily a intraorganisational coordination tool, through micro planning, delivery of sprints and the like, and missing an interorganisational coordination part. In the internal processes Scrum perform the distribution of roles and development of the actors' capability to fulfil the identified roles. In the interorganisational coordination we witness a mutual adaption/adjustment towards the other party in the Houseco, where expectation to sprints (the short term artefacts) has to be mutually bended [START_REF] Kornstädt | Mastering dual-shore Development-The tools and materials approach adapted to agile offshoring[END_REF]. In the Texco case however it appears that, scrum masters from Texco are willing to establish authoritative relations and subjugate actors from the supplier to insist in exercising the scrum estimations, which illustrate the role of direction [START_REF] Demsetz | The theory of the firm revised[END_REF]. Furthermore the role played by the mother company's knowledge base is a finding parallel to [START_REF] Sutherland | Fully Distributed Scrum: Replicating Local Productivity and Quality with Offshore Teams[END_REF], which maintains that it is the mother organisations understanding of Scrum that makes the difference.

The routine perspective adds an issue of control and expectancy of work. The routine is whether tacit or explicit supporting the inter-relational communication in interand intra-organisational contexts alike [START_REF] Hummel | The Role of Communication in Agile Systems Development[END_REF]. Using Carlile's [START_REF] Carlile | Transferring, translating, and transforming: an integrative framework for managing knowledge across boundaries[END_REF] context of knowledge integration in the state of transformation, the cases suggest is takes more than some months of transition to actually move to a state of internalisation. Finally, considering [START_REF] Deng | Control, Affect and Cognition Trust in Determining IT Offshoring Outsourcing Service Quality[END_REF][71][45] [START_REF] Heiskanen | Control, trust, power, and the dynamics of information system outsourcing relationships: a process study of contractual software development[END_REF] agile and scrum contain attractive aspects of control of performance, developers perception, ability to deliver, and cost. Routines provide a certain degree of control as performativity is relatively direct recognisable; this proves more complex in offshoring although scrum is providing parts of this given necessary learning and internationalisation.

At the outset the two cases are rather different. One HouseCo is a small to small and a single project, whereas the other Texco is a large to large longitudinal collaboration. They can be characterised as Win-Loose (HouseCo) versus Loose-Loose (Texco). As a result both case companies return to a captive set up, which along with the general offshoring literature [START_REF] Lacity | A review of the IT outsourcing literature: insights for practice[END_REF][START_REF] Lacity | A review of the IT outsourcing empirical literature and future research directions[END_REF][START_REF] Lacity | Business process outsourcing studies: a critical review and research directions[END_REF], is probably merely a temporal choice until another occasion will stimulate the companies to use offshoring again. At least in the HouseCo case management is prepared for this future turn.

On this background it appear that other differences between the cases, such as informal versus formal contractual relations have mattered less as both dyads, mother companies and suppliers struggle with making acceptable results out of the scrum processes. Issues of quality and time are occurring. They both experience that direct collocated interaction are superior to IT-mediated communication [START_REF] Hummel | The Role of Communication in Agile Systems Development[END_REF]. Texco and Softco invest heavily for some time in the collaboration (up to 80 employees involved, with 60 involved in software development) and it continue to be a likely future alliance.

Finally it could be interesting to consider alternatives to agile and scrum. In the HouseCo case it could have been a classical waterfall requirement specification that would have proven difficult given the small size of both organisations and the complexity of the project [START_REF] D'adderio | Inside the Virtual Product: How Organisations Create Knowledge Through Software[END_REF] [START_REF] Uy | Growing and Sustaining an Offshore Scrum Engagement[END_REF]. In TexCo agile and scrum was sought for as a replacement for a highly ad-hoc based development methodology characterized by a very low degree of experience from all sides [START_REF] Misra | Identifying some important success factors in adopting agile software development practices[END_REF] [START_REF] Westner | Determinants of success in IS offshoring projects: Results from an empirical study of German companies[END_REF]. Requirement specifications were rarely more than 15 pages and did more set the framework of the project, and TexCo's prior methodology could thus be seen as "haphazard prototyping" [START_REF] D'adderio | Crafting the virtual prototype: how firms integrate knowledge and capabilities across organisational boundaries[END_REF]. Therefore TexCo can be viewed as potential terrain for getting into trouble using almost any method.

Conclusion

In establishing offshoring relations we have discussed the role of globally accessible standardised routines and methods, Scrum and Agile. It was chosen by the case companies as a direction to enable the integration of knowledge and to establish routines between a mother company and a supplier. We saw how this partly failed as it appears that the involved companies have not succeeded in practicing Scrum and Agile in a collaborative manner even if managerial direction were in place. However our results underline that Scrum and Agile also act as an independent reference point for the receiving organization, even if it turns out to be an imprecise reference. Failure of both the mother and supplier organization to comply with the demands within the standardized routine was interpreted as due to barriers at both ends to translate and/or externalize tacit knowledge during the development process. Both failures relate to the chosen standardized routine as well as managing the identified roles as the interorganisational part supplementing the standardized routine. Scrum and Agile functions primarily as an intra-organisational coordination tool whereas the interor-ganisational coordination part fails, leading to a captive backshoring of the activities in both cases. Routines are not like tin cans. The trajectories of the two cases reveals the performativity of routines especially within the interorganizational area and partly also within the organizations.