Coordination Challenges in Large-ScaleSoftware Development: A Case Study ofPlanning Misalignment in Hybrid SettingsSaskia Bick , Kai Spohrer , Rashina Hoda , Alexander Scheerer , and Armin Heinzl

Abstract—Achieving effective inter-team coordination is one of the most pressing challenges in large-scale software development.

Hybrid approaches of traditional and agile development promise combining the overview and predictability of long-term planning on an

inter-team level with the flexibility and adaptability of agile development on a team level. It is currently unclear, however, why such

hybrids often fail. Our case study within a large software development unit of 13 teams at a global enterprise software company

explores how and why a combination of traditional planning on an inter-team level and agile development on a team level can result in

ineffective coordination. Based on a variety of data, including interviews with scrum masters, product owners, architects and senior

management, and using Grounded Theory data analysis procedures, we identify a lack of dependency awareness across development

teams as a key explanation of ineffective coordination. Our findings show how a lack of dependency awareness emerges from

misaligned planning activities of specification, prioritization, estimation and allocation between agile team and traditional inter-team

levels and ultimately prevents effective coordination. Knowing about these issues, large-scale hybrid projects in similar contexts can try

to better align their planning activities across levels to improve dependency awareness and in turn achieve more effective coordination.

Index Terms—Large-scale software development, agile, hybrid, inter-team coordination, dependency awareness, planning alignment,

information systems development

Ç

1 INTRODUCTION

RESEARCH andpractice have gainedmany insights into theinherent mechanisms of agile software development, its

beneficial effects on how teams adapt to change [1] and itsability to help teammembers collaborate more effectively [2],[3]. The rapid rise of agile software development beyond thecomforts of small, co-located teams [4] into the setting oflarge-scale software development projects, however, hasopened up a Pandora’s box of uncharted challenges for thesoftware industry. Undoubtedly, the fundamental structuresand methods of small-scale agile software developmentrequire adaptation in order to suit the nature of complex andlarge endeavors with numerous active development teamsat the same time [4], [5]. It has been suggested that hybridapproaches, combining traditional plan-driven and contem-porary agile development, are actually often an adequatechoice given the history and requirements of large, long-running and highly integrated development projects [6], [7],[8], [9], [10]. Some reasons cited in favor of continued

traditional planning in such hybrid approaches includepredictability, dependability, stability and effective use ofresources [11]. Although these hybrid approaches have beenpromoted in both academic literature [6], [9] and industrialframeworks (e.g., Disciplined Agile Delivery [12]), little isknown as towhy they succeed in some cases and fail in others.

Despite its promising potential, the introduction of anyagile elements into traditional structured methodologiesincurs major costs for reconciliation and may in fact demandfor entirely new forms of development project control [13],[14]. Particularly interdependencies between many, possiblyeven geographically distributed, teams of software develop-ers require carefully coordinated action across teams [15],[16]. In fact, inter-team coordination has recently been rankedthe most pertinent large-scale agile challenge demandingimmediate research attention [17].

Whereas traditional plan-driven approaches aim at the res-olution of dependencies by comprehensive planning, detailedroles and pre-specification of software requirements andimplementation activities [18], [19], agile approaches build onthe idea that developers can most effectively resolve depen-dencies collaboratively and iteratively through self-organiza-tion when dependencies become visible on a detailed tasklevel [20], [21], [22], [23]. Prior research suggests that largeand complex development projects may actually benefit fromcombining the flexible, organic coordination inherent to agileteamwork and the structured, plan-driven coordination oftraditional project management into hybrid forms [6], [9],[14]. The questions whether such a synthesis is indeed possi-ble and how hybrid approaches affect coordination are of

� S. Bick and A. Scheerer are with SAP SE, Walldorf 69190, Germany.E-mail: {saskia.bick, alexander.scheerer}@sap.com.

� K. Spohrer and A. Heinzl are with the University of Mannheim,Mannheim 68131, Germany. E-mail: {spohrer, heinzl}@uni-mannheim.de.

� R. Hoda is with the University of Auckland, Auckland 1010, New Zealand.E-mail: r.hoda@auckland.ac.nz.

Manuscript received 28 Apr. 2016; revised 16 June 2017; accepted 4 July 2017.Date of publication 23 July 2017; date of current version 23 Oct. 2018.(Corresponding author: Saskia Bick.)Recommended for acceptance by B. Fitzgerald.For information on obtaining reprints of this article, please send e-mail to:reprints@ieee.org, and reference the Digital Object Identifier below.Digital Object Identifier no. 10.1109/TSE.2017.2730870

932 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

0098-5589� 2017 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.See http://www.ieee.org/publications_standards/publications/rights/index.html for more information.

utmost importance as inadequate responses to interdepen-dencies and ineffective coordination constitute major sourcesof project failures [24], [25].

For this reason, we aim to better understand the criticalaspects of inter-team coordination in such hybrid forms ofagile development and traditional planning and coordina-tion. Despite few studies of successful hybrid projects [13],[26], prior work in the area of coordination in hybrids isscarce and there is only limited extant research to buildupon [14], [27], [28]. As one consequence, the frequentlyreported coordination failures and issues in hybrid settings[11], [29] have largely remained unexplained. We thereforeapproach our research from a problem-oriented perspectiveand empirically investigate a case study where a hybridform struggled to achieve effective coordination in a largesoftware project. In particular, we address the question:

“How and why does a combination of traditional plan-ning on an inter-team level and agile development on ateam level lead to ineffective coordination in large-scalesoftware development?”

We leverage diverse qualitative data from a revelatorycase study of a long-running hybrid software developmentproject observed at a large global software company whereinter-team coordination was known to be an ongoing chal-lenge. In this context, 13 teams consisting of more than140 developers worked on a single, highly integrated sys-tem of standardized enterprise software, combining agiledevelopment on a team level with traditional planning andcoordination on an inter-team level. This setting provided avaluable context to study the causes of inter-team coordina-tion challenges not discernible in well coordinated units.

Following a Grounded Theory approach to qualitativedata analysis of interviews with scrum masters, productowners, architects and senior management, as well as proj-ect documentation, product backlogs and wikis, the keycontributions of this study are twofold: 1) we identify a lackof dependency awareness as a key explanation of ineffectivecoordination in hybrid development settings, 2) we showhow this lack of dependency awareness emerges from mis-aligned planning activities between team and inter-teamlevels, particularly during specification, prioritization, esti-mation and allocation.

In addition to implications for research, we highlightpractical recommendations arising from our study with theaim to help software practitioners identify and avoid criticalpitfalls in order to achieve better inter-team coordinationvia alignment of planning activities and higher dependencyawareness.

2 CONCEPTUAL FOUNDATIONS AND

RELATED WORK

In this section, we present the relevant foundations onagile, as well as on large-scale agile software development,including the key terminology. Further, we recapitulate thecurrent state of research on the coordination of tasks incomparable systems of multiple teams, particularly focus-ing on the associated challenges. For the purpose of discus-sing this research, we use the term team level to refer toactors, actions and interactions within a single development

team of a larger software development unit. The inter-teamlevel, by contrast, comprises all institutions and activitiesbetween development teams of a larger unit, including cen-tral teams (CT) that act as coordinating entities betweendevelopment teams.

2.1 Agile Software Development

Traditionally, approaches to software development reliedon top-down planning and heavyweight process manage-ment with a focus on detailed specifications and thoroughupfront design. The most prominent is the waterfallapproach [18], [19], which aims at process oversight andpredictability based on intense upfront planning, documen-tation and sequential implementation and deployment.Attempting to better meet the dynamic nature of today’ssoftware development business, agile software development, amore flexible, lightweight approach, gradually replaced themore rigid traditional software development approach [30].

In 2001, the Agile Manifesto [20] postulated, amongstothers, values such as interaction, collaboration, workingsoftware and flexibility in response to change. In this paper,we focus on the most prominent agile methodology, namelyScrum [31]. This project management framework aims atsmall software development projects and established a setof new roles such as scrum master (SM), product owner (PO)and the self-organizing team [32]. A product owner isresponsible for a product’s business value and the scrumteam’s remaining product backlog – an ordered list of prod-uct requirements. The cross-functional, self-organizingscrum team consists of seven (þ/- 2) developers and is sup-ported by a scrum master who is the process facilitator andcoach of the team. At the heart of Scrum lies the sprint, atime-boxed iteration of usually two or four weeks, duringwhich the development team implements a shippable soft-ware product increment. During several institutionalizedScrum meetings, the team collaboratively and iterativelydiscusses requirements, identifies dependencies, estimatesefforts and reflects upon recent experiences to fine-tune itsown processes.

2.2 Large-Scale Agile Software Development

Originally, agile methodologies aimed at small projects [4],[8]. Increasingly, however, large organizations seek to bene-fit from the advantages promised by agile development ona small scale. Especially the flexibility and adaptability ofthe workforce constitute major improvements compared tothe heavyweight traditional approaches to software devel-opment [33]. Several practices and approaches to scalingagile methods have been proposed over time.

One of the earliest described practices to address the scal-ing issue is the Scrum-of-Scrums (SoS) – a scaled form of thedaily stand-up meeting practice where smaller teams arerepresented by their “ambassadors” [34]. The format of anSoS is the same as that for a single team’s daily meeting inthat three areas are discussed by each team representative:work completed, next steps and impediments. Resolution ofimpediments often involves resolving coordination chal-lenges via team interfacing, negotiating responsibilities, etc.[35]. The use of the SoS practice has been documented in apractitioner-based experience report [36] where individual

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 933

teams met daily and team leaders were reported to meetonce a week in an SoS meeting. However, there is no inde-pendent empirical evidence of the use of this individualpractice as a comprehensive scaling approach and the prac-tice has also been noted to be ineffective [37]. In some cases,the SoS was replaced by other approaches such as commu-nities of practice.

A community of practice (CoP), which is a group of expertswanting to deepen their knowledge of a common sharedinterest or topic, has been shown to be a key success factor insupporting knowledge management and coordination inlarge-scale agile software development [37], [38], [39]. TheseCoPs were formed around common topics of interest, pas-sionate leaders, concrete agendas and supporting tools tocreate transparency. They were introduced as a large-scaleagile practice to achieve knowledge sharing and learning,coordination, common design principles and organizationdevelopment. Wider adoption of the CoP approach remainsto be seen in other organizations practicing large-scale devel-opment [37].

In response to the rapid adoption of agile software devel-opment, a number of industrial frameworks have been pro-posed by practitioners and agile evangelists in more recenttimes to adapt agile development to a larger scale. Examplesinclude Large Scale Scrum (LeSS) [40], the Scaled Agile Frame-work (SAFe) [41], the Nexus framework [42] and DisciplinedAgile Delivery (DAD) [12]. All such commercialized frame-works seek to provide guidance for large organizations,which want to scale agile from the team to the inter-teamlevel, by offering specific principles, roles and practices.While Nexus, LeSS and SAFe take the approach of scalingagile bottom-up from the team to the inter-team level, DADmeanwhile promotes a mixed approach that combinesScrum with best practices from multiple methodologiessuch as Extreme Programming, Rational Unified Process,Kanban and others.

All of the described scaling frameworks, however, have acommon tendency to assume a greenfield setting to build on.Yet, especially large, established software vendors often donot face such legacy-free development targets and structures.In our study, we therefore want to focus particularly onhybrid structures of agile team level and plan-driven inter-team level approaches. Despite the plethora of approachesand frameworks, there is a dearth of research evaluating theireffects in the software industry. Research has shown thatcompanies rarely adopt software development frameworksin their entirety but usually pick and combine single elementsof different ones to suit their needs [43], [44]. Critical views onthis common practice label the commingling of traditionalapproaches and agile approaches Water-Scrum-Fall [45]or ScrumBut [46], criticizing the lack of procedural disciplinewhile at the same time acknowledging the difficulties orga-nizations are facing during an agile transformation. How-ever, apart from this, almost no research has addressedcustomized or otherwise combined approaches to large-scaleagile development.

2.3 Challenges to Scaling Agile

Applying agilemethods and practices on a larger scale bringsalong challenges and difficulties [7] such as a higher numberof stakeholders, additional complexity in coordination efforts

and increasingly difficult architectural integration [11], [37].A better understanding of these challenges is key to harness-ing the benefits of agility in large scale settings [47]. Yet,research on agile on a large scale still remains scarce [17],[27]. Some empirical studies illustrate individual effects oflarge-scale agile development [9], [48], [49], [50], [51], [52]and report that agile on a large scale contributes to knowl-edge sharing through an emphasis on collaboration and atthe same time increases coordination effectiveness. Thesevaluable studies, however, do not provide more in-depthexplanations of how to understand and overcome the chal-lenges of large-scale agile development.

In general, team level agile methodologies, includingScrum, do not easily transfer to larger projects because pref-erences and priorities between multiple teams tend to differstrongly [53]. Moreover, the organic coordination of largenumbers of tasks and individuals logistically and cogni-tively overburdens project members [11], while numerousstakeholders pose distinct process requirements on largerand thereby more costly and critical projects [14]. Conse-quently, also business-relevant decisions can rarely beachieved on the team level through timely and direct cus-tomer interaction [29], [47]. Based on the heterogeneousnature of existing software development organizations,scholars have therefore suggested adapting and customiz-ing agile development to its environment, particularly tothe size of the development endeavor [43], [52], [54].

2.4 Hybrid Approaches to Scaling Agile

In response to the described challenges to scaling agileapproaches to large settings, so called hybrid approaches com-bining agile and traditional plan-driven methodologieshave increasingly gained attention in research and practice[6], [10], [11], [55]. By definition, the term hybrid character-izes something “of mixed character” or “a thing made bycombining two different elements” [56]. Hence, the defini-tion of a hybrid traditional-agile approach includes a widespectrum of the combination of traditional structured andagile approaches. Existing conceptualizations accept thatfor many different areas, organizations can opt for eitheragile or structured and plan-driven practices thereby creat-ing a huge variety of hybrid approaches [14]. Similarly, Bar-low et al. [6] conceptualize a hybrid methodology for large,mature organizations that combines aspects of agile andplan-driven methods. For this study, we build on Barlowet al.’s [6] research and conceptualize a hybrid approach asa combination of traditional, plan-driven methods withagile methods. Key characteristics of a hybrid approachinclude the display of:

1. characteristics of two or more different approaches,e.g., hierarchical, top-down communication from atraditional approach and bottom-up adjustment [23]seen in an agile approach.

2. practices of two or more different approaches, e.g.,extensive upfront planning in a traditional approachand regular inspections and adaptations from anagile approach.

3. roles from two or more different approaches, e.g.,traditional project managers and scrum masters andproduct owners from an agile approach.

934 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

Hybrids are therefore not a single, discrete type ofmethod. Much rather, they represent a huge variety ofmixes within a spectrum between the extremes of purelytraditional and purely agile development (see Fig. 1).

Depending on the project size, volatility and interdepen-dencies, a hybrid approach focuses both on agile aspectssuch as mutual adjustment through strong social networks,as well as on traditional project planning with formalizedinformation and knowledge transfer [6]. Hybrid approachesmay therefore be particularly reasonable in large and dis-tributed project settings with high impact that nonethelessneed to cope with changes in requirements, organizationsand technologies [14], [55]. For example, Scrum has beensuccessfully embedded in structured approaches based onthe PMBOK (Project Management Body of Knowledge)framework or CMMI (Capability Maturity Model Integra-tion) [14], [55]. Batra et al. [55] conclude that elements ofstructured project management (such as formal manage-ment of skills and architecture together with traceablerequirements and documentation) can serve as architecturalfoundations to maintain order and predictability through-out a project. Contrastingly, agile elements (such as time-boxed development sprints and actively prioritized back-logs) can add to a project by providing the means for sens-ing and responding to dynamism and uncertainty [55].

Several studies focus on the introduction of agile practi-ces in traditional, large development projects [13], [26].As such, Mahadevan et al. [13] find that hybrid approachesmore likely show a mix of outcome control and emergencecontrol compared to the traditional waterfall approach.Interestingly, the introduction of agile elements to tradi-tional plan-driven approaches has been found to resultin more decision power for the business side rather than thedevelopment side of large projects [13]. Moreover, studiesemphasize that project uncertainty and completion urgencyrequire a neat fit of project teams’ information technologycapabilities and implemented organizational controls [26].

In particular, agile teams are found to stand out in suchcontexts by developing either sensing capabilities for rela-tively foreseeable needs for change, or responding andlearning capabilities for situations of unforeseeable change[26]. This resonates with findings by Ramasubbu et al. [14]who observe that project contingencies such as require-ments volatility, novelty and the need for process compli-ance foster a mix of different frameworks within singleprojects. They find that combinations of multiple frame-works are only beneficial for project success if project man-agement actively enforces compliance to the defined mix offrameworks and processes, whatever that may look like inparticular [14].

Lastly, studies have noted the adverse effects of hybridcontexts where teams were practicing agile methods in non-agile or more traditional environments [11], [29], such aschallenges to project productivity and delayed releases.Reported challenges range from the creation of require-ments, and the alignment of methods to differing opinionsabout processes and standards. In particular, the adaptationand alignment of software developmentmethods and practi-ces between the two opposing development approaches inan environment of team-of-teams structures seems to causeorganizations severe difficulties [29]. However, the rootcauses of such issues remain largely unclear in the literature.

In sum, prior work has proposed different hybridapproaches and emphasized their numerous potential bene-fits. As hybrid approaches are reported to impose variouschallenges, scholars underline the important need for coor-dination across all teams involved in a developmentendeavor. Extant work has associated this coordinationwith both activities and capabilities of project managementteams [13], [14], as well as of single development teams [26].Lamentably, however, these valuable contributions to ourknowledge have not yet ascertained where the frequentlymentioned coordination challenges in hybrid settings stemfrom, why they arise and how the different actors withinand across development teams are involved in not onlyresolving but also in causing these challenges. In fact,research attempts to unravel the detailed interactions withinand between teams in large-scale agile development set-tings have only just begun [16]. For this reason, we engagein theory building to lay an explanatory foundation for fur-ther investigations.

2.5 Inter-Team Coordination

Applying agile methodologies in large-scale settings bringsalong the challenge of added complexity and a much highernumber of involved stakeholders, naturally arising from alarger organizational context. As such, multiple, interdepen-dent teams that work together on a common goal representa so-called team-of-teams structure. In the organizational lit-erature, this structure of “two or more teams that interfacedirectly and interdependently in response to environmentalcontingencies toward the accomplishment of collectivegoals” [57] is called a multiteam system (MTS). In such anMTS, the single teams have individual proximal goals andshare a common distal goal with all other teams while theyhave input, process and outcome dependencies with at leastone other team [57].

The traditional view of dependencies [58] implies theneed for activity alignment in order to resolve dependen-cies. Crowston [59] and Strode et al. [60] provide categoriza-tions, which focus on the types of entities between whichthe dependencies exist, e.g., task, resource, knowledge andtechnical dependencies. In this paper, we refer to task depen-dencies, i.e., producer-consumer dependencies. These occurwhen one task has to be finished before another task can bestarted [60], [61]. If the first task remains unfinished, the sec-ond task is blocked.

In order to manage existing dependencies within andbetween teams, inter-team coordination is of major impor-tance. While literature holds an abundance of definitions forcoordination, we make use of the definition of coordination

Fig. 1. Spectrum of hybrid approaches between plan-driven and agilesoftware development.

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 935

as the management of dependencies [59], [62]. When speak-ing of inter-team coordination, we explicitly refer to the coor-dination of activities between two or more teams within anMTS. Extant literature presents several types, directions andmechanisms to categorize coordination. Espinosa et al. [63]distinguish between two coordination types: explicit coordi-nation, which consists of mechanistic (e.g., plans, rules androutines) and organic elements (e.g., mutual adjustmentand feedback), as opposed to implicit coordination, whichconsists of cognitive elements (e.g., shared mental models,team expertise and transactive memory systems). Based onthis, Scheerer et al. [16] conceptualize top-down planning asa mechanistic, centralized approach with vertical coordina-tion, e.g., between a team and a hierarchically superior per-son or a central team. The archetype on the other end of thespectrum is called bottom-up adjustment and represents alargely organic and decentralized strategy with horizontalcoordination between teams of anMTS [16], [63], [64].

The performance of inter-team coordination has beenmeasured in terms of coordination success and effectiveness[65], [66]. Both concepts are similar in their foundations andfor this study, we chose coordination effectiveness as anoutcome variable for our research. Coordination effectivenessis defined as a state of coordination, where all members of asoftware development MTS have a comprehensive under-standing of the common goals and priorities, what is goingon and when, what they as a team need to do and when,which team is doing what and how each team’s work fitsin with another team’s work [65]. The few studies thatinvestigated antecedents of coordination effectivenesslooked at the influence of coordination strategy [67], knowl-edge sharing [68] and team environment complexity [69],amongst other factors. Particularly in software developmentorganizations, however, ineffective coordinating reactionsto dependencies are known to be a major cause of projectfailure [24], [25]. A comprehensive understanding of thenecessary conditions for coordination effectiveness is stilllacking, though.

3 RESEARCH DESIGN

In our research, we aimed to understand the emergence androot causes of ineffective coordination in hybrids of tradi-tional and agile approaches. While research and practiceagree that reconciling agile and plan-driven approaches intohybrid forms appears necessary [26], [55], the frequentlyreported coordination failures and issues in doing so [11],[29] have largely remained unexplained. Due to this lack ofexisting explanations, we engaged in theory building basedon empirical data [70], [71]. To do so, we focused on under-standing the central mechanisms that prevent effective coor-dination in hybrid settings by studying a case with knowncoordination challenges. By understanding these detrimen-tal mechanisms, we aimed to conceptualize a process modelof effective coordination in hybrid settings. Based on theidentified negative mechanisms, we describe the type andsequence of necessary but non-sufficient conditions that musthappen as antecedents of effective coordination.

Process theorizing is well established in the literatureand complements variance theories by providing a qualita-tive and temporal causal argument [72], [73], [74], [75].

Importantly, a process model describing the relation X ! Ydoes not read “more X therefore more Y” but rather “theoccurrence of X is necessary but not sufficient for Y tooccur” [74]. Our process model of effective coordination inhybrid traditional-agile development settings thereforedescribes necessary events that occur as prerequisites ofeffective coordination. By definition, this is not a compre-hensive explanation of effective coordination, but a modelproposing that coordination can only become effectivewhen the antecedents exist. While such a model may notprovide a silver bullet for successful coordination, it empha-sizes and explains the roots of important challenges.

In order to build our explanatory model, we conducted asingle, revelatory case study [70], [76], [77] in an ongoing,large-scale software development project at a large enter-prise software company. We had the unique chance toconduct a case study that promised to be particularly infor-mative for our research because it clearly exhibited a hybridform of traditional and agile approaches to large-scaledevelopment that reportedly suffered from ineffective coor-dination. In fact, we were approached by several of thecompany’s agile development experts in early 2013 whoregarded this project as particularly interesting because itmixed agile and traditional approaches, and the expertswanted to know how this would turn out.

During a first informal talk, it became clear that heavycoordination issues existed in the project and we wereinvited to study those issues and their possible relation tothe hybrid setting. While individual development teams ofthe project applied agile practices following the latest stand-ards, there was a clearly articulated desire by managementto retain traditional elements of product and project man-agement in order to coordinate activities across the manyteams involved. Despite the fact that the developed producthad been successful and development could somehow keepthe pace of the market, there were reportedly frequentfrustrations because of ineffective coordination between thedifferent development teams. As a consequence, this projectprovided a very rich and insightful case for exploringwhether and how events of ineffective coordination relatedto the combined application of traditional and agile devel-opment approaches. Given the dearth of theory explainingcoordination failures in hybrid settings and the uniquepromise of very rich data access to such a reportedly nega-tive hybrid case, we deemed it appropriate to conduct a sin-gle case study for the purpose of building a theoretical mid-range model [77], [78].

3.1 Case Description

The studied large software development unit was develop-ing a complex and successful standard enterprise softwarewith 13 development teams in four locations spreadover Germany, India and China. With a total of around140 employees, each development team consisted of six to16 developers. The average company tenure of developerswas 12 years, the average tenure in this development unitwas five years and teams and individuals were well accus-tomed to working with each other. The on-premise enter-prise software solution had been developed, refined andextended for more than 10 years. Despite its market success,the product had become quite complex due to a wide range

936 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

of customers with diverse requirements. Moreover, theproduct architecture was highly integrated, exhibiting atight coupling of product functionality.

The single development teams were, with few exceptions,co-located and usually had exclusively assigned productowners and scrum masters. Several developers, architects,UI designers and quality engineers completed the compe-tence profile of each cross-functional development team.All development teams worked in the Scrum mode andapplied agile development practices such as iterative devel-opment, daily stand-ups, sprint and release planning meet-ings, sprint review meetings, team retrospectives and agiletechniques such as pair programming to different intensitiesthroughout the teams.

For planning and coordination, there were synchroniza-tion cycles across the whole development unit of four weeks,which also resembled the length of the development sprintsfor the teams. On a strategic planning level, release planningcycles were reported to comprise up to several years.

The official process for planning and coordinating thework of more than a dozen teams involved quite a populartraditional strategy, namely establishing a central team spe-cifically for that purpose. In this case, the central team was anon-developing team, consisting of the chief product owner(CPO), architects and product experts, a total of seven mem-bers. The central team was responsible for the high-levelproduct planning and facilitating coordination of activitiesacross the multiple development teams. The central teamdid not include any product owners or other representativesfrom the individual development teams that it coordinated.The central team met daily for one hour to discuss currentand pressing topics as well as the plans for the upcomingsprints. Once per sprint, the central team hosted a statusand hand-over meeting with each of the developmentteams’ product owners separately. In this meeting, the cen-tral team wanted to see what had been achieved by theproduct owner’s development team during the last sprintand communicated the backlog items and their prioritiesfor the next sprint in a directive manner. In more detail, thecentral team generated high-level work items in the form ofepics and allocated those to the individual development

teams. An epic described high-level requirements and wasprogressively broken down into more granular user storiesand subsequently into technical tasks as it passed downfrom the central team to the individual teams and then toindividuals within teams (see Fig. 3).

Fig. 2 depicts the setup of the multiteam system, i.e., thelarge software development unit. In the depicted setting,the central team was responsible for coordinating the singledevelopment teams. It thereby presented a widely appliedform of traditional higher-level planning and coordinationvia roles and hierarchies. At the same time, the single teamswere working in sprint-based iterations, consisted ofempowered team members and applied agile practicesapplicable to their contexts. Overall, the case featured cen-tral elements of a hybrid approach: a mix of top-down plan-ning via a central team and agile software developmentmethods and practices on a team level.

In the depicted organizational setup, the individualteams frequently faced mutual dependencies due to thehighly integrated and tightly coupled nature of the softwarecodebase. In fact, the software codebase resembled a busi-ness process with sequentially interdependent components(exemplified in Fig. 2 for a procurement process). In thestudied case, development team 1 was responsible for thebusiness process component C1 “Order”, i.e., developingthat particular part of the enterprise software which con-cerns the creation and processing of a customer order in aprocurement process. In sum, the case at hand constituted aconducive basis for the examination of planning activitiesin hybrid traditional-agile approaches to software develop-ment and their consequences for inter-team coordination.

3.2 Data Collection

To gain a detailed understanding of the case, we collectedqualitative data between October 2013 and November 2014.During this time, we conducted 23 semi-structured inter-views with key informants of the development unit. Ourinterviewees included the CPO, the lead architect, 11 prod-uct owners (who usually had a strong technical back-ground) and 10 scrum masters (who usually also performedas developers and had extensive experience of softwaredevelopment) from 13 development teams located in fourdifferent international locations. These informants werechosen based on their roles as they could best report oninter-team coordination issues and provide a comprehen-sive perspective of both the team level and the inter-teamlevel. Instead of focusing on single developers who view aproject from their team-internal perspectives, we activelychose to focus on roles that were directly engaged in the

Fig. 3. Backlog hierarchy.

Fig. 2. Multiteam system organizational setup.

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 937

definition and management of work on an inter-team level(CPO, lead architect) or the diffusion and reflection of workpackages on a team level (product owners, scrum masters).

Where possible, we conducted interviews face-to-face (10interviews), or else via phone (13 interviews). All 23 inter-views were recorded, summing up to 15 hours of audiomaterial, then transcribed (approximately 330 pages of tran-scripts) and subsequently analyzed with the qualitativedata analysis software NVivo 10. Additionally, we usedinternal documentation and project management data to tri-angulate our findings and increase analytical validity [76].In particular, we collected organization charts from wikipages to learn about responsibilities, members and distribu-tion of development teams, i.e., the organizational structureof the software development unit. We analyzed backlogmanagement system data to understand the content, sizeand specification of backlog items. Backlog managementdata also allowed us to cross-check our findings from thesemi-structured interviews. Product architecture mapshelped us to better understand the product and the speciali-zation of individual development teams, ultimately allow-ing us to check for or rule out alternative explanations forobserved coordination inefficiencies.

3.3 Data Analysis

We analyzed the interview data using Grounded Theory(GT) [71] to capture the emergent themes and findings.In doing so, we employed GT’s open, selective and theoreti-cal coding procedures. These coding procedures wereconducted by two of the authors individually. Emergingthemes were compared and examined and were also dis-cussed extensively amongst the other authors to ensure reli-able coding. Where categorizations of events differedbetween the authors, the particular events were discussedintensively until consensus was reached.

To explain how we applied these procedures in thisstudy, an example of working from raw interview data tothe findings of one of the categories, ’misalignment of plan-ning activities’, is presented. First, we summarized portionsof the interview transcripts into two to four words referredto as codes.

Raw Data. “What is missing today and what we need is collec-tive planning. . . If you really have to deliver an end-to-end process,you need to align each and every team and you need to plan theirdevelopments completely in a collaborative fashion. That is some-thing that we have not been able to achieve very well so far.”

Code. need to align planning; Code: planning alignment notworking

It was clear that there was a need for planning alignmentbut at the same time it was not being achieved effectively.Comparing codes from within the same interview and withthose from other interviews, we grouped the codes into ahigher level of abstraction called concepts. In this example,the concept that emerged was ’misalignment of planning’.

Concept. misalignment of planning (in general)In addition to misalignment of planning in general, other

concepts capturing misalignment of specific planning activi-ties also emerged. These concepts included misalignment of:specification and prioritization (of requirements), estimation(of effort) and allocation (of tasks). Together they captured themisalignments that were seen across four planning activities

leading to the next level of abstraction called category, in thiscase ’misalignment of planning activities’.

Category. misalignment of planning activitiesSimilarly, the second main category, lack of dependency

awareness was identified. For example, the presence of occa-sional task dependencies across teams was strongly evidentfrom multiple interviews. At the same time, it was obviousthat there was a lack of communication of tasks and progressfrom one team that led to a lack of awareness of tasks and prog-ress for the other teams and vice-versa. This led to teamsmaking inaccurate assumptions about what to expect andwhat not to expect in terms of task dependencies. Overall,these concepts highlighted a clear lack of dependency aware-ness across the teams.

Fig. 4 shows the emergence of the two categories, mis-alignment of planning activities and lack of dependency aware-ness, from their respective underlying concepts and codes.The third main category, ineffective coordination, was notonly a known problem from the beginning of the case studybut was also supported well through the data analysis insimilar ways.

Further details of open, selective coding and other GTprocedures can be found in GT’s seminal texts [71], a recentreview [79] and a dedicated paper on the use of GT in soft-ware engineering [80]. The final step of GT’s data analysis istheoretical coding, which involves conceptualizing the rela-tionships between themain categories as a set of inter-relatedpropositions [75], [80], [81]. The following section describesthe main categories. The propositions, i.e., inter-relationshipbetween the categories, and the formulation of the overalltheoretical model is described and discussed in Section 4.3.

The categories and their inter-relationships emergedfrom data analysis and were not preconceived at the outsetof the study. Nevertheless, they partly relate to conceptspresent in extant literature. When causal inter-relationshipsemerged, we therefore went from analyzing data to examin-ing the literature in order to sharpen the emergent catego-ries until they were closely tied to both the events depictedin our data and established concepts from the literature.This procedure of dialogical reasoning allowed us to prop-erly account for the events unraveling in our case while bas-ing arguments and conceptions on strong findings of prior

Fig. 4. Emergence of the categories ‘misalignment of planning activities’and ‘lack of dependency awareness’ from underlying concepts throughopen and selective coding. (ITD: inter-team dependency)

938 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

work. We illustrate this for the category lack of dependencyawareness: When we identified a dominant theme in ourdata that teams suffered particularly from being unable toidentify and address dependencies on the work of otherteams, we turned to the literature to understand alreadyexisting conceptions of this phenomenon. Prior work hasshown that higher levels of work dependencies increase thefailure proneness of software development projects [82] andhas attributed this to individuals’ inability to detect implicitworkflow interdependencies and to keep track of changingcoordination requirements over time [82]. Accordingly,related work has started to create tools aiming to increaseindividual developers’ awareness of task interdependencieswith the ultimate goal to facilitate more effective coordina-tion [83], [84], [85]. This stream of work thereby helped usmore precisely define dependency awareness with vocabu-lary already present in research (see Table 1) and reinforcedour inductively gained understanding that the absence ofdependency awareness inhibited effective coordinationacross teams. Such an approach is supported by the basictenets of GT whereby related literature can be consulted inthe later stages of theory development to support andexplain the emergent findings [71].

4 CASE STUDY RESULTS

In the following, we present the results of our study. First,we elaborate on events of ineffective coordination in thestudied case. Due to the development unit’s relatively longand stable history, the fact that there was cultural diversitybetween the development teams did not noticeably influ-ence the collaboration between the teams. This was consen-sually affirmed in our interviews. Similarly, we could notfind any evidence that coordination challenges were relatedto the distributed or co-located settings of the individualteams. In other words, the reported issues clearly happenedbetween the team and inter-team levels, regardless of thelocation or cultural background of the development teams.We first show that ineffective coordination was primarilycaused by a lack of dependency awareness across teams.We then go deeper into the analysis of root causes for thislack of dependency awareness.

4.1 Dependency Awareness

Our investigation revealed that the coordination of activitieson an intra-team level appeared to work well. Based onnearly text book-like Scrum, the single teams discussed

requirements, open issues and potential problems andresolved dependencies within their team on a daily basis.

Interviewee 11 (SM): “Every day, we discuss the topissues that need to be solved. [. . .] This is good, becauseeverybody is on the same page. Everybody knows whatissues are of top priority and what everybody needs towork on. This daily sync is very effective.”

In the monthly planning and review sessions, all teammembers including the team product owner were involved.In the daily stand-up meetings, the whole team was present.These institutionalized meetings provided room for discus-sion and most importantly instant feedback from teammembers. The scrum master facilitated these team-internaldiscussions and took care of impediments that potentiallykept his team from doing their job. At the same time, theproduct owner clearly specified new backlog items and wasavailable for questions coming from the team. Throughdescribing open tasks and next steps in their developmentefforts, individuals shared insights into potential sources ofdependencies with their team members.

In that same discussion space, team members wereimplicitly invited to speak up, share their thoughts and helpresolve ad-hoc dependencies in an organic manner. During asprint, the scrummaster blocked new tasks that were not ini-tially scheduled for the current sprint. In contrast, on aninter-team level, the development unit was facing severecoordination challenges. Several product owners reportedsituations where their entire development team was blockedby some unforeseen event. This was most frequently causedby an unidentified dependency with another team. In reac-tion to this type of situation, problems were frequently esca-lated to the central team. Escalation meant reporting theissue to the central team and thereby signaling a team’sinability to complete its own tasks for the current sprint. Thiswas reported to happen several times per sprint throughoutthe entire development unit.

Interviewee 7 (PO): “At some point it becomes clear thatsomething is wrong and then, depending on the priorityof the topic, we have internal escalations [. . .] and can’tproceed with what we were doing. [. . .] we have meetings,reprioritize and try to solve the issue.”

That is, through escalating an issue to the inter-team levelvia the central team, a team usually passed on the responsi-bility for the situation at hand, instead of taking action andattempting to resolve the source of the conflict directly with

TABLE 1Working Definitions of Key Constructs Used and Derived

Construct Working definition Primary references

Hybrid a combination of traditional, plan-driven methods with agile methods [6], [55]Planning activity alignment The degree of coherence between specification, prioritization, estimation and

allocation on team and inter-team levels[22], [31]

Dependency awareness the state of all of the system’s relevant stakeholders (on both the team andinter-team levels) having identified, recognized and established a sharedunderstanding of the existence of interdependencies and potentially resultingalignment issues

[82]

Coordination effectiveness a state of coordination, where all members of a software development MTShave a comprehensive understanding of the common goals and priorities,what is going on and when, what they as a team need to do and when

[65]

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 939

the other involved teams. This happened as a result of thehierarchical setup of the central team as the main coordinat-ing authority on the inter-team level. At the inter-team level,there were hardly any higher-level epics one team alonecould work on. Cross-team requirements were very com-mon. Therefore, not only the developed product, which rep-resented a tightly integrated business process solution, butalso the development teams were highly interconnected.Interconnections seemed to cause problems if the points ofcontact in terms of handovers, deliverables and dependen-cies in general were not clearly defined upfront. The prob-lems did not appear in those situations, however, where thecentral team could identify and communicate the majorityof the potentially critical dependencies between epics theyassigned to the development teams. Even if problems aroseduring the sprint, resolution could then usually happen in acontrolled fashion.

Interviewee 7 (PO): “Then, you either get [the deliver-able] when you need it, or [. . .] it is at least defined in away that we can re-estimate the effort. And if it is toomuch so we have to say that we cannot do it this sprint,we have to postpone it to the next. But then at least thesituation is clear and not like you rely on their inputwhich doesn’t come eventually.”

Amuchmore problematic picture presented itself in situa-tions where dependencies between teams had not been iden-tified and anticipated upfront. This led to teams blockingeach other, escalations in the middle of a sprint, delays and ahigh level of general discontent in the development unit.

Interviewee 4 (PO): “[. . .] team 1 builds something andsomehow it is forgotten to talk with team 2 and 3 and inthe end something doesn’t work because somebodyexpected that the requirement which was built by team 1is also taken into consideration in the other teams.”

Often, teams did not know of other teams’ activities andthereby were not aware of requirements towards them.Many of these task dependencies appeared to be unknownto at least one of the involved parties. Once a developmentteam was at the point where it needed the input of anotherteam and realized that for whatever reason the requiredinput could not be delivered in time, the observed reactionwas often an escalation to the central team.

Interviewee 2 (PO): “Something was built [. . .] and otherteams didn’t know about what was going on, and then the(development) processes just stopped all of a sudden; oryou knew what was needed, but the capacity just wasn’tsufficient [. . .] then you’re facing escalations.”

Clearly, the central team’s approach to ensuring goodcoordination across the teams was to prevent dependenciesfrom arising. However, this was largely seen as ineffectivegiven the size of the central team in comparison to the sizeof the large software development unit and due the fact thatno team representatives took part in the discussions.

These insights more and more raised the question as towhat might have been causing the coordination issuesbetween the teams. Statements by product owners andscrum masters indicated that teams did not seem to knowabout the requirements and dependencies of other teams.

Especially those undetected dependencies that existedbetween one’s own team and another fellow team werereported to cause problems. We noted a severe lack of depen-dency awareness in the studied case. That is, teams lacked “anunderstanding of the activities of others, which provides acontext for [their] own activity” [86, p. 1].

Interviewee 4 (PO): “[. . .] This is what doesn’t work atthe moment – that the central team launches team 1 withtopic 1, team 2 with topic 2 and team 3 with topic 3,although topics 1, 2 and 3 would also require the capacityof team 1, 2 and 3. So it’s distributed locally and monthsdown the road, you notice that the other teams shoulddeliver something, too.”

Having illustrated the conflicts and resulting problemsthat we saw, we can say that in a majority of cases wherecoordination issues became apparent, the reason was a lackof dependency awareness. Unidentified dependencies andcovered potential conflicts led to ineffective coordinationbetween the development teams which in turn had animpact on the teams’ productivity and ability to deliver.

Without being aware of dependencies to other teams, adevelopment teamwill neither be able to assess potential con-sequences, nor will it even think about ways to resolve thesedependencies. Regardless of the size of themultiteam system,it is therefore necessary for all its members to recognize andcome to a common understanding of potential or existingdependencies. We define dependency awareness as the state ofall of the system’s relevant stakeholders (on both the teamand inter-team levels) having identified, recognized andestablished a shared understanding of the existence of inter-dependencies and potentially resulting alignment issues.In single, co-located agile teams, dependency awareness hasnot been identified as an issue [87]. Yet, to the best of ourknowledge, research on dependency awareness in the con-text of hybrid approaches to large-scale software develop-ment is scarce [88]. Our case data suggests that dependencyawareness is a necessary, though not sufficient, antecedent toeffective coordination.

4.2 Misalignment of Planning Activities

Having identified a lack of dependency awareness as thecritical factor inhibiting effective inter-team coordination,we proceeded with an in-depth analysis of the root causesthat impaired dependency awareness in the first place. Datasuggest that the source of the conflict lies in the planningactivities of the development process.

Interviewee 14 (PO): “We are not able to pre-plan. [. . .]The central team [. . .] needs to have a significant amountof process clarity and then needs to reach the teams. Thenevery team needs to align their sprint according to that.[. . .] If you really have to deliver an end-to-end process,you need to align each and every team and you need toplan their developments completely in a collaborativefashion. That is something that we have not been able toachieve very well so far.”

According to our data, we see that even before theactual implementation of requirements, several planningactivities, namely specification, prioritization, estimation andallocation, were misaligned between the team and the inter-

940 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

team levels of the development unit, which caused severeproblems later on during the implementation. The misalign-ment of the four planning activities was conceptually derivedfrom the GTdata analysis as described in Section 3.3.

Particular aspects of a concept can be captured as proper-ties in GT. ‘Focus’ was captured as a property of planningconcepts. In other words, it reminds us that one of the maindimensions of misalignment was how the team and inter-team levels varied in their focus, where the former wasmore content-oriented while the latter focused on time.That is, actors either concentrated on a defined scope offunctionality that should be developed, or on a definedtimeframe or time-box. For example, for the specificationactivity, it was found that in case of the inter-team level, thecentral team’s focus was on getting a certain defined set offeatures developed, preferrably in the shortest time possi-ble. On the team-level, in contrast, the focus was on a time-boxed cycle of four weeks during which as many user sto-ries as possible would be completed. A time-oriented focuscould range from daily to sprint-, or even release-basedtime frame. In our case, a release usually spanned 12sprints, i.e., almost one year.

Similarly, two other cross-cutting dimensions of mis-alignment emerged: degree of detail and competence. Thedimension degree of detail captures the extent of details pres-ent in the requirements expressed at each level. At the inter-team level, for example, requirements were more abstract,coarse-grained concepts, such as themes or epics. At theteam-level, on the other hand, requirements were brokendown further and the degree of detail was fine-grainedon the task or user-story level. This content hierarchy isdepicted in Fig. 3.

The third dimension competence refers to the specifictechnical knowledge, expertise and project experience thatenables a certain role or entity responsible for the planningto perform their job. For example, the central team’s compe-tence to perform coarse-grained specification at the inter-team level was based on long-standing market knowledge,customer insight and a high-level view of the release plan;which the individual development teams usually lacked.On the other hand, the product owners’ and the teams’competence to perform a detailed and fine-grained specifi-cation was based on detailed technical knowledge of theirspecific product components and collective team expertise;which the central team did not possess. Incorporating theabove dimensions of misalignment, we define planning

misalignment as “the incompatible arrangement of focus,degree of detail and competence in planning activities onthe team level in relation to the inter-team level”. The find-ings are summarized in Fig. 9 and described in detail in thefollowing sections.

4.2.1 Specification

Before starting to implement a user story, the desired func-tionality first had to be clearly discussed and elaborated. Asdepicted in Fig. 3, there was a hierarchy regarding thedegree of detail of the specification. By specifying a userstory or task, the relevant and necessary informationregarding functionality, design and performance needs wasstated in a concise way. On the inter-team level, the centralteam specified coarse-grained requirements with a clearlycontent-oriented focus (Fig. 5). Their market knowledge,customer insight and a high-level view of the current releaseplan enabled the central team to provide such a high-levelspecification. Through the up-front specification of high-level epics, the central team generated a coherent picture ofthe functionality that had to be developed.

Interviewee 8 (PO): “[. . .] there’s a central team which wehave, who toss a coarse-grained backlog item, an epic, intothe team. [. . .] Once you get to the implementation it’s awhole new story. [. . .] when it’s about tossing the stuff intothe scrum teams, what they need is not what they get, causethe teams have work left to finish [from previous sprints].”

On the team level, we observed a much more time-ori-ented focus. That is, the product owner together with histeam detailed out fine-grained user stories or tasks in asprint-based manner right before the sprint in which therespective user stories should be implemented. The productowner’s competence to do the fine-grained task specifica-tion was based on specific product component knowledgeand the collective expertise of his team that he represented.Due to the time-oriented focus, only the few user storieswere detailed out that were to be implemented in theaccording sprint. Those, however, were elaborated with ahigh degree of technical detail during refinement sessionsthat were facilitated by the scrum master. If dependencieswith other teams were discovered during these sessions,this consequently happened at the time when the respectiveother teams were also detailing out their own user storiesalready and had closed their backlog for the respectivesprint. A resolution of such newly discovered dependencies

Fig. 5. Specification misalignment dimensions.

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 941

thus interfered inherently with the idea to specify user sto-ries collaboratively and just before implementation.

Viewed separately, both the central team as well as theproduct owners and scrum masters acted in a reasonableway considering their goals and their areas of competence.However, for an active alignment of specifications acrossthe two levels, we found two main impeding factors. First,the central team did not have the detailed technical viewnecessary to do the kind of specification that aims to preventall sorts of potential dependencies up front, by identifyingthem early on

Interviewee 22 (CT member): “Usually we [the centralteam] cannot anticipate all dependencies between theteams. [. . .] normally when we have problems with coor-dination, the fact that we don’t manage to synchronizethe teams in such a way that they can work in parallelwithout blocking each other comes up.”

Thus, for a traditional top-down specification of modulartasks, which would be based on detailed documentationand a high level of insight, the provided degree of detailwas simply too low. Since the central team did not gatherand incorporate any feedback about detailed specificationscoming from the development teams, they did not compen-sate for this shortcoming and the teams themselves weretasked with finding other teams affected by newly discov-ered interdependencies.

Interviewee 4 (PO): “They [central team] work on anitem level with 2-3 bullet points per [epic]. [. . .] that’swhat they dump on a team and this team then has to findthe other teams that are affected by this [epic].”

Second, the teams did have the technical expertise to dis-cover inter-team dependencies for their specified user sto-ries right before their next sprint, but they lacked lead timeand the high-level picture to resolve them with other teams.What is more, active sharing of their specification detailswith one another or with the central team was neitherencouraged nor institutionalized. Therefore, discoveredinter-team level dependencies were known to single devel-opment teams only and affected teams could not take theminto account. Together, the specification misalignment, inthe form of a lack of detail for a top-down task specificationand a lack of cross-team collaborativeness and iterativenessfor a bottom-up task elaboration led to a lack of dependencyawareness.

4.2.2 Prioritization

Once specified, the work packages for the upcoming develop-ment iteration needed to be prioritized so as to explicitly statean order of importance in which they were to be imple-mented. In the studied multiteam system, the central teamconducted an absolute, high-level prioritization of the epicsthey had specified based on their overall view of the releaseplan andmarket needs (Fig. 6). The epics they identified, how-ever, mostly related to indispensable features of the productto be released. Therefore, they assigned mostly very high pri-orities to those epics and often had only little differencebetween the priorities ofmultiple epics.

Interviewee 2 (PO): “If you’re already late [in the currentsprint] and everything has been defined as prio 1, itdoesn’t make sense to put another prio 1 on top [for thenext sprint].”

Rather than clearly differentiating priorities, the centralteam provided development teams with a sequence inwhich epics should be implemented. The effect could bedescribed as an epic-based sequencing. On the team level,each product owner did a sprint-based prioritization andreprioritization of the current backlog items based on histechnical component knowledge and a comprehensive back-log understanding. The product owner thereby created anexplicit order by which the items were to be implemented.The results of the prioritization activity were then communi-cated to the development team.

Again, our data suggest two problems with theunaligned approaches between the inter-team and the teamlevel. First, the central team set many, equally high absolutepriorities for indispensable features from a business per-spective and only infrequently reprioritized those. By conse-quence, teams had a hard time prioritizing left-over workfrom previous sprints compared to new epics. Second,through their local team level priorities, the teams resolvedteam-internal backlog dependencies. However, as develop-ment teams did not know about one another’s reprioritiza-tions and sequence of work steps, this frequently intensifiedthe effects of existing inter-team dependencies.

Interviewee 22 (CT member): “An issue which we face [. . .]was the mutual blocking of teams. Because they are stronglyinterconnected, we previously often had the situation thatpriority 1 from one teamwas priority 3 of the next team andthese two teams actually had to work together.”

Fig. 6. Prioritization misalignment dimensions.

942 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

Therefore, we can state that the rough prioritization onthe inter-team level together with the nontransparent,potentially conflicting team level reprioritizations pre-vented dependency awareness.

4.2.3 Estimation

Each product owner and development team jointly estimatedthe exact efforts for open tasks of the following sprint throughinternal discussions (Fig. 7). Whenever new informationcaused the initial estimation to be unrealistic, tasks were re-estimated. In their collaborative discussion sessions, thewhole team came upwith carefully refined effort estimations,which were very close to reality. On the inter-team level, acoarse-grained effort estimation happened in amore content-oriented manner, based on epics. The central team roughlyapproximated the epic size relying on their long experiencewith this multiteam system and their collective expertise.

Since the central team did not have such a strong time-ori-ented focus as the development teams did, we observed aconflict with the team level time-boxing. Despite applying abest effort approach, the central team’s estimations wereoften very imprecise, yet still constituted the basis for the dis-tribution of epics to the development teams. Estimations oninter-team and team levels also diverged as the much moreaccurate estimations made by single teams were kept inter-nally and could not be taken into account by other teams. Asthere was no standardized process during which the teamscould communicate their collaboratively refined effort esti-mations, no alignment of estimationwas accomplished.

Interviewee 22 (CT member): “[. . .] we give [epics] to theteams, the teams do the sprint planning [. . .] and reportto us what they achieved. Let’s say, in 9 out of 10 times,they [the teams] achieve less than what we told them todo. So for the sprint thereafter, a good percentage of theircapacity is already blocked.”

The nontransparent team level estimations also pre-vented development teams from knowing exactly when toexpect handovers from other teams. This could in turnintensify inter-team dependencies when teams were relyingon others to deliver certain functionality in order for themto complete their own tasks. The estimation misalignmentcan be summarized as an imprecise top-down effort esti-mation and a lack of feedback mechanisms for bottom-upestimation adjustment. Together, this hindered dependencyawareness.

Interviewee 2 (PO): “You have a monthly hand-overmeeting [from the central team to each developmentteam] and let me say, this is not effective at all, because itdoesn’t make sense if you have backlog items lasting forfive more sprints, to get even more on top.”

4.2.4 Allocation

After specifying, prioritizing and estimating work packages,the last step in the planning process was the allocation of thelatter to a team for implementation. On the inter-team level,the central team allocated coarse-grained epics to specializedcomponent teams based on an architecture overview andenabled through their long development unit-specific expe-rience (Fig. 8). The epic-based and sequenced top-down allo-cation was meant to fit the teams’ expertise and preventinter-team dependencies but usually happened irrespectiveof detailed team level priorities and estimations.

The epic allocation seemed to be partially predeterminedby a high degree of specialization of the development teamsin parts of the business process (see also Fig. 2). Within theself-organized scrum teams, the allocation of tasks hap-pened on a voluntary and daily basis during the dailystand-up meetings, based on the individuals’ capacities andexpertise. This process of task self-allocation was facilitatedthrough the detailed specification and the explicitly orderedsprint backlog. On the inter-team level, however, there wasvery little communication or exchange about epics betweenthe individual teams, just like in previously illustrated plan-ning activities. The development teams were aware of otherteams’ general responsibilities, but knew only little abouttheir currently assigned epics. This was also true for theteams’product owners who were the only ones to receivetheir teams’ epics for the next sprint from the central team.These handovers happend during one-on-one sessionsbetween a single product owner and the central team andthereby did not allow for gaining insights into other teams’epics, either.

Clearly, the upfront allocation of epics without a detailedspecification, prioritization and estimation prevented the cen-tral team from identifying and communicating dependencies.This resulted in a lack of dependency awareness. What ismore, many inter-team dependencies were only discoveredby the development teams during their sprint planning.How-ever, lacking lead time and a high-level overview, there wasrarely any chance for them to adjust or reallocate epics acrossteams ad hoc.

Fig. 7. Estimation misalignment dimensions.

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 943

Interviewee 22 (CT member): “Often we think that [epics]are independent and give them to the teams only to havethe experts come back to us and tell us, if I should imple-ment this, then another team has to implement somethingfirst and the other team doesn’t have time right know.”

4.3 Development of a Process Model

Theoretical coding (as explained in Section 3.3) finallyallowed us to understand the inter-relationships of themain categories: We found that the misalignment of plan-ning activities had constantly caused a lack of dependencyawareness, which had generally resulted in ineffective coor-dination. Based on this analysis, we are therefore led tobelieve that effective coordination was not possible withoutdependency awareness which, in turn, was not possiblewithout aligned planning activities between team and inter-team levels. We elaborate on this in the following.

As suggested in Section 4.1, all teams including the cen-tral team were frequently unaware of dependencies span-ning the boundaries of single teams. Quite reliably thisresulted in a) unsuccessful endeavors by teams to adaptmutually once they became aware during implementationor integration, b) in escalations to the central team whocould not easily resolve the dependencies and c) ultimatelyin process breakdowns and the need to postpone delivery.

Although a number of other reasons can also lead toineffective coordination, lack of dependency awarenesswas clearly identified as the dominant one for the reportedevents of ineffective coordination in this study. Nonetheless,we investigated also for other potential explanations of inef-fective coordination that were ultimately discarded as theydid not fit what we observed.

As one example, ineffective coordination between teamscould also be rooted in teams’ inability to adequately reacton observed dependencies rather than not being aware ofthem. We used the rare situations in which there was highdependency awareness to probe into this possibility. Wesaw that the teams were generally able to resolve dependen-cies they were aware of. For such known dependencies, thecentral team tried to resolve them already during planning.If this was not possible, the central team informed singleteams about the expected interdependencies who sortedthem out easily enough. For example, product owners andscrum masters of involved teams had phone calls severaltimes a week to communicate local progress and facilitatemutual adaptation.

Interviewee 7 (PO): “Usually it works, if they [the CT]prepared it properly [. . .] If you check all aspects againcollaboratively and document it, then usually it works.”

In sum, we found a consistent co-occurrence of ineffectivecoordination with, and only with, lacking dependencyawareness. Data from our case therefore suggest that depen-dency awareness is necessary for effective coordination of allteams. However, its presence does by no means guaranteefor effective coordination. Where only single developmentteams are aware of interdependencies, this precludes a reso-lution of dependencies through roles and hierarchy [89] aswould be typical for traditional development approaches. Ifall information were available to the entire MTS, hierar-chically higher institutions (such as a central team) couldredefine roles of single teams and re-modularize tasks toresolve interdependencies [58], [90]. Without knowing aboutall the actors involved and without knowing about thenature of the dependency, however, hierarchical mecha-nisms cannot function properly [89]. Mutual adaptation aswould be typical for agile development [33], on the otherhand, cannot work if the parties who would need to adaptmutually do not clearly share the same understanding of adependency to resolve [91]. This leads us to propose:

P1. Dependency awareness across both team and inter-teamlevels is necessary though not sufficient for effective coordinationto occur.

Moreover, misaligned planning activities on team andinter-team levels frequently caused our case teams, includ-ing the central team, to overlook dependencies. In our case,the central team was not specifying in as much detail as atraditional specification approach would require, neitherwere the teams able to collaboratively define and specifyall tasks as would be common within a single agile team.Consequently, each team on its own was not able to identifyits dependencies with other teams effectively during specifi-cation. As a result, there often was a lack of dependencyawareness on an inter-team level, which inhibited effectivecoordination. This was particularly true because the centralteam, in its aim to prevent dependencies between teams,directly allocated epics top-down to the single developmentteams, mostly without consulting other teams.

Breaking epics down into single tasks to work on, indi-vidual teams refined the planning which resulted in prior-ity-based task sequences and detailed effort estimations

Fig. 8. Allocation misalignment dimensions.

944 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

that partly deviated from the central team’s plan. Whenteams worked on isolated epics, this did not constitute aproblem and was actually desirable. Frequently, however,there were dependencies that had not been spotted and

local decisions inherently affected other teams. Conse-quently, dependencies across different teams that were notidentified by the central team via pre-specification wereusually only found far too late in a sprint when all other

Fig. 9. Effect of planning misalignment between inter-team and team level on dependency awareness. (ITL: inter-team level; TL: team level)

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 945

teams that would have been needed to resolve such depen-dencies via mutual adaptation had already committed toother highly prioritized work.

In our case, particularly misalignments between theplanning activities conducted on a team level and those con-ducted on an inter-team level resulted in impaired depen-dency awareness. In other words, misalignment of planningactivities was the dominant cause leading to a lack ofdependency awareness (Fig. 9 depicts these effects). Andwe could, in fact, not observe any situations in which theteams managed to achieve project-wide awareness of anydependency without aligning their planning activities.

From a theoretical perspective, this appears quite reason-able as each misaligned planning activity between team andinter-team levels presents an individual chance to obfuscatedependencies and aggravate their impact. As such, purelylocal specification activities that detail out requirements onshort notice clearly increase the chance of purely local dis-covery of interdependencies. Teams not involved in thespecification cannot easily know about such a discovereddependency andmuch less share the same understanding ofit. Although teams discovering dependencies may identify atechnical need for adapting a specific component in order toproceed, they may lack the high level overview of whichother team could address this need, i.e., who they actuallydepend on. Given the short time frame from specificationto implementation typical for agile development, also thepossibilities of ongoing intensive communication acrossteams are severly restricted, thereby undermining chancesfor more time-consuming communication-based coordina-tion [91]. Single teams’ planning activities further affect thesequence and timing of their contributions to the overallproduct when they locally refine and change prioritiesand effort estimations in an agile way. Where other teamsdepend on these contributions, such changes impact thoseteams’ freedom to act and execute their own plans. Withoutaligning these activities across teams, there can be no sharedview that allows for mutual adaptation or hierarchical deci-sionmaking to enforce a specific order. Lastly, the traditionaltop-down allocation of development tasks, even of coarse-grained ones, to single teams is bound to create unresolveddependencies in all complex projects [25]. When a team dis-covers such a dependency and does not know about otherteams’ task allocations, it becomes difficult to identify whothey actually depend on. Although developers and teamscan establish bottom-up routines to partition or re-allocatesuch tasks to appropriate others, this takes time and resour-ces usually not spent in organizational settings where moreefficient hierarchical coordination constitutes a viable alter-native [92]. To make either hierarchical or bottom-up coordi-nation possible, however, task allocations need to be alignedacross single teams (and central institutions) to provide allparties with the same understanding of dependencies. Basedon this reasoning and the empirical support found in ourcase study, we therefore propose P2:

P2 Planning alignment of all planning phases (specification,prioritization, estimation, allocation) is necessary though notsufficient for dependency awareness to occur.

With propositions P1 and P2, we propose a processmodel of effective coordination in hybrid settings (seeFig. 10). Importantly, this does not mean “the more alignedthe planning activities, the higher the dependency aware-ness and the higher the coordination effectiveness”. Instead,it defines the sequence of necessary conditions that need tohappen before effective coordination becomes possible. Themodel thereby holds that when planning activities are notaligned, this inhibits dependency awareness of all entities;and when there is no project-wide dependency awareness,coordination becomes ineffective [17], [54].

5 DISCUSSION

Current literature on large-scale software development sug-gests that hybrid approaches of traditional plan-driven andagile software development may provide high value in verylarge, complex and long-running development projects [6].While prior work has lined out the general conceptual dif-ferences between traditional and agile approaches [7], thereis little knowledge about the details of their compatibilityfor hybrid settings. In particular, assertions that a combina-tion appears to be promising [6], [55] but problematic [11],[29] have yet to culminate in explanations why hybrids suc-ceed or fail.

Our study addressed this research gap and explored coor-dination challenges in a hybrid setting. In summary, theinvestigated case study lent a number of insights into inter-team coordination in a hybrid setting of traditional high-level planning and agile development. We found that coor-dination issues were primarily caused when there was nocommon awareness of dependencies across teams. This lackof dependency awareness in turn resulted from themisalign-ment of separate planning activities that were conducted ona team level and on an inter-team level respectively. In par-ticular, we found that misalignments in specification andallocation inhibited dependency awareness, and misalignedprioritization and effort estimation activities further aggra-vated these issues. With this, we make the following contri-butions to research and practice.

5.1 Implications for Research

First and foremost, our study adds to prior work on hybriddevelopment settings [6], [13], [14], [55] showing thatdependency awareness constitutes a significant issue wheretop-down traditional planning needs to be brought togetherwith bottom-up agile development. Our results therebyback and extend prior research on the crucial role of depen-dencies in software projects [25], [53], [82], [93]. While thisstream of research has emphasized that coordination break-downs frequently occur when developers are not capable toinclude the right colleagues in dependency resolution [25],

Fig. 10. Process model showing relationships between planning activity alignment, dependency awareness & coordination effectiveness.

946 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

we show that organizational structures and processes ofhybrid approaches can even reinforce this incapacity.Through misaligned planning activities on team and inter-team levels, dependencies can remain concealed and conse-quently exert their known negative effects.

Prior work moreover suggests that creating hybrid devel-opment projects is possible but necessitates appropriate gov-ernance and control activities [13], [14]. The providedunderstanding of planning activity alignment and depen-dency awareness as a central antecedent of effective coordi-nation hopefully allows future research as well as industryto tailor better practices and technologies that help increasedependency awareness also on an inter-team level. In fact,research has long and successfully engaged in providingtools that help identify and highlight dependencies betweenrequirements, existing source code and newly developeditems [83], [84], [85], [93]. Our study suggests that, particu-larly in large, hybrid traditional-agile development units,such visibility is necessary and planning activities need to bealigned even before fine-grained specifications are entirelydetailed out. From a practical perspective, contemporaryconcepts such as ‘delivery stories’ described in softwaredevelopment outsourcing research [15] may potentiallyprovide a helpful starting point to achieve this visibility.Future work on dependency visibility tools may take thisinto account and provide planning activity support thathelps align inter-team level and team level planning alreadybefore and during specification.

Our findings not only re-emphasize the need for institu-tionalized coordination practices across single developmentteams, which agile methods do not incorporate today [53],[54], they also lend detailed insight into what these coordi-nation practices must be able to accomplish: such coordina-tion practices (i) must allow for involving higher levelinstitutions such as central product teams, (ii) they mustcommence prior to single teams planning their next itera-tions in detail and (iii) they must bridge the differences infocus, detail and competence that distinguish team andinter-team level actors during activities of specification, pri-oritization, estimation and allocation. We thereby add toprior work that emphasized the importance of matchingcoordination reactions to evolving dependencies [24], [25]and line out temporal as well as organizational require-ments of such coordination mechanisms.

While the collaborative and iterative work inherent toagile practices allows development teams to identify andresolve dependencies between their single tasks on the fly[23], traditional methods for planning and coordinationapplied on an inter-team level aim at preventing dependen-cies by nearly complete pre-specifications [94]. Althoughplanning activities on both inter-team and team levels maybe appropriate and well understood when viewed sepa-rately, our study suggests their alignment is crucial to dis-cover and manage inter-team dependencies.

Furthermore, we identified the main points of differencesandmisalignment between the traditional and agile planningactivities of our case. As described in Section 4.2, these differ-ences were seen along three main dimensions: focus, degree ofdetail and competence. Since our case study was an exemplarof largely ineffective coordination, we were able to identifythese specific dimensions of misalignment. As such, we donot claim these dimensions to be absolute or final, rather theycan hopefully be extended and adapted through further

research on the topic. Future studies can investigate howthese dimensions can be aligned in practice by studying suc-cessful caseswith a focus on planning alignment. Centralizedunits and processes that structurally enforce alignment [14]may constitute equally possible candidate mechanisms asinformal and process-oriented ones [13].

5.2 Recommendations for Practice

5.2.1 Improving Dependency Awareness

A direct practical implication of our findings is that regularinter-team level meetings may be required to improvedependency awareness and in turn facilitate inter-teamcoordination. For example, in addition to the Scrum-of-Scrums approach described in Section 2.2, other collabora-tive team-level meetings such as sprint planning, reviewsand retrospectives that capture agile principles of iterativedelivery and collaboration can be mirrored at the inter-teamlevel to facilitate planning alignment. The inter-team coun-terparts of these standard team-level agile meetings shouldinclude informed representatives from all teams concernedin addition to the members of the central team. This shouldestablish a two-way feedback channel between the individ-ual teams on the one hand and the central team on the other,as well as a platform for all teams to become aware of theexisting and potential dependencies between them. Whatwe are recommending differs from the SoS approach in thatit is not limited to a single status-reporting meeting, butrather encompasses joint planning, reviews, and retrospec-tive meetings. In general, the frequency and logistic needsof such meetings will likely be contingent on developmentunit size as well as on an organization’s preferred approachto large-scale agile. As such, smaller development unitsmay be able to conduct meetings with all team memberspresent. For larger software development units and teamsizes, representatives of each team may be required. Other,more traditional, meeting practices such as those conductedby senior management and market experts to create high-level product visions and roadmaps will likely still be rele-vant for companies operating in large-scale settings.

5.2.2 Aligning Planning Activities

Our findings show that awareness issues can result fromconflicting orientations toward content and time framesbetween inter-team and team levels. It may be possible toresolve such conflicts partially by preponing iterative plan-ning activities on an inter-team level, propagating results tothe team level and allowing for an iterative adjustment pro-cess between inter-team and team levels. As such, specifica-tion and prioritization on an inter-team level may take placewith sufficient lead time before the start of the next sprint ofthe development teams. Development teams may then beable to specify high-priority tasks in detail and feed resultsregarding emergent inter-team dependencies back to theinter-team level for resolution before actually committing tothe particular set of tasks for the upcoming sprint.

5.2.3 Planning Tools Development and Evaluation

Development of new tools that can be deployed in the plan-ning stages to capture dependencies during activities suchas specification, estimation, prioritization and allocationshould be considered. Popular project management toolssuch as Rally’s “ready > sync > go” [95] and VersionOne’s

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 947

enterprise agile platform [30] seem to acknowledge thevaried approaches to scaling and aim to support differentmethodologies such as SAFe, LeSS, DAD and hybridapproaches. While their effectiveness remains to be studied,we suggest that companies that evaluate such tools for theirpurposes should particularly consider to which degreethese tools are useful in achieving dependency awarenessacross development teams and help align specification, pri-oritization, estimation and allocation.

5.3 LimitationsThis single case study served the purpose of building theoryon a little understood phenomenon based on a specific reve-latory case [70], [76]. We used empirical data to inductivelycreate a process model explaining the sequence of eventsthat if interrupted inhibits effective coordination in hybridsettings of traditional planning on an inter-team leveland agile development on a team level. Importantly, thisresearch design did not aim for generalization into all othersettings of hybrid approaches which would rather followa statistical replication logic [77], [96]. Instead, it aimed forcreating a detailed and in-depth understanding of theevents and mechanisms within this case to propose a pow-erful and fitted explanation through rigorous data collectionand analysis [71], [76], [97]. In particular, while GT typicallydoes not claim generalization to all contexts, the resultingtheory or model should be adaptable to other contexts.What this means is we do not claim our model to be abso-lute or final. We want to encourage fellow researchers topick up on this model and particularly the misalignment ofplanning activities to verify or challenge their explanatoryvalue in related contexts. We welcome future studies to pro-vide extensions to the model based on unseen aspects andrefinements of the present categories and dimensions.

Although this specific case was revelatory regarding themisalignments of traditional high-level planning and agiledevelopment, we also acknowledge these elements as bound-aries to our research. Instead of claiming generalizability toall hybrids of traditional and agile development, we hope toprovide rich, valuable and detailed insights into settingswhere multiple agile teams need to collaboratively create asingle software product based on longer release cycles andsupported by more intense and structured high-level plan-ning. Additionally, we only examined one single product,namely an established, highly integrated, ongoing and thuscomplex enterprise software system. It is very reasonable toassume that the architecture of this product influenced thetechnical interdependencies of single tasks and teams. Largesoftware development units developing highlymodular soft-ware may possibly face less negative effects from misalignedplanning activities, simply because they also face less interde-pendencies between technical components altogether. Futureresearch should therefore pay close attention to softwarearchitecture and its relation to dependency awareness.

6 CONCLUSION

In this study, we aimed to investigate how and why thecombination of traditional planning on an inter-team leveland agile development on a team level leads to ineffec-tive coordination in large-scale software development. Wefound that a lack of dependency awareness is a majorcause for ineffective inter-team coordination and thatdependency awareness itself is inhibited by misaligned

planning activities across team and inter-team levels,namely specification, prioritization, estimation and alloca-tion. One avenue of future research could be the investiga-tion into how to effectively prevent the described planningmisalignments. Along these lines, an in-depth examinationof cases seems promising where inter-team coordinationworks very well so as to delineate measures how to pre-vent or resolve dependencies.

REFERENCES

[1] C. T. Schmidt, T. Kude, J. Tripp, A. Heinzl, and K. Spohrer, “Teamadaptability in agile information systems development,” in Proc.34th Int. Conf. Inf. Syst., 2013, pp. 1–11.

[2] H. Sharp and H. Robinson, “Collaboration and co-ordination inmature eXtreme programming teams,” Int. J. Hum. Comput. Stud.,vol. 66, no. 7, pp. 506–518, 2008.

[3] L.M.Maruping, V. Venkatesh, andR. Agarwal, “AControl TheoryPerspective on Agile Methodology Use and Changing UserRequirements,” Inf. Syst. Res., vol. 20, no. 3, pp. 377–399, Sep. 2009.

[4] R. Hoda, P. Kruchten, J. Noble, and S. Marshall, “Agility incontext,” in Proc. ACM Int. Conf. Object Oriented Program. Syst.Languages Appl., 2010, pp. 74–88.

[5] C. Larman and B. Vodde, Practices for Scaling Lean & Agile Develop-ment Large, Multisite, and Offshore Product Development with Large-Scale Scrum, 1st ed. Upper Saddle River, NJ, USA: AddisonWesley, 2010.

[6] J. B. Barlow, J. S. Giboney, M. J. Keith, D. W. Wilson, and R. M.Schuetzler, “Overview and guidance on agile development inlarge organizations,” Commun. Assoc. Inf. Syst., vol. 29, no. 2,pp. 25–44, 2011.

[7] B. Boehm and R. Turner, “Management challenges to implement-ing agile processes in traditional development organizations,”IEEE Softw., vol. 22, no. 5, pp. 30–39, Sep./Oct. 2005.

[8] B. Boehm and R. Turner, “Using risk to balance agile andplan-driven methods,” IEEE Comput., vol. 36, no. 6, pp. 57–66,Jun. 2003.

[9] L. Cao, K. Mohan, P. Xu, and B. Ramesh, “How extreme doesextreme programming have to be? Adapting XP practices tolarge-scale projects,” in Proc. 37th Hawaii Int. Conf. Syst. Sci., 2004,Art. no. 30083.3.

[10] L. Cao, K. Mohan, P. Xu, and B. Ramesh, “A framework for adapt-ing agile development methodologies,” Eur. J. Inf. Syst., vol. 18,no. 4, pp. 332–343, 2009.

[11] D. Badampudi, B. Fricker, and A. M. Moreno, “Perspectives onproductivity and delays in large-scale agile projects,” in Proc. 14thInt. Conf. XP Agile Processes Softw. Eng. Extreme Program, 2013,pp. 180–194.

[12] S. W. Ambler and M. Lines, Disciplined Agile Delivery: APractitioner’s Guide to Agile Software Delivery in the Enterprise.London, U.K.: Pearson Education, 2012.

[13] L. Mahadevan, W. J. Ketinger, and T. O. Meservy, “Running onhybrid: Control changes when introducing an agile methodologyin a traditional ‘waterfall’ system development environment,”Commun. Assoc. Inf. Syst., vol. 36, no. 1, pp. 77–103, 2015.

[14] N. Ramasubbu, A. Bharadwaj, and G. K. Tayi, “Software processdiversity: Conceptualization, measurement, and analysis ofimpact on project performance,” Manage. Inf. Syst. Q., vol. 39,no. 4, pp. 787–807, 2015.

[15] M. Daneva, et al., “Agile requirements prioritization in large-scaleoutsourced system projects: An empirical study,” J. Syst. Softw.,vol. 86, no. 5, pp. 1333–1353, 2013.

[16] A. Scheerer and T. Kude, “Exploring coordination in large-scaleagile software development: A multiteam systems perspective,”in Proc. 35th Int. Conf. Inf. Syst., 2014, pp. 1–11.

[17] T. Dingsøyr and N. B. Moe, “Research challenges in large-scaleagile software development,” ACM SIGSOFT Softw. Eng. Notes,vol. 38, no. 5, pp. 38–39, 2013.

[18] H. D. Benington, “Production of large computer programs,” Ann.Hist. Comput., vol. 5, no. 4, pp. 350–361, 1983.

[19] W. W. Royce, “Managing the development of large softwaresystems: Concepts and techniques,” in Proc. 9th Int. Conf. Softw.Eng., 1987, pp. 328–338.

[20] K. Beck, et al., “Manifesto for agile software development,” AgileAlliance, 2001. [Online]. Available: http://www.agilemanifesto.org/, Accessed on: Aug. 24, 2014.

948 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018

[21] N. B. Moe, T. Dingsøyr, and T. Dyba�, “A teamwork model for

understanding an agile team: A case study of a Scrum project,”Inf. Softw. Technol., vol. 52, no. 5, pp. 480–491, 2010.

[22] R. Hoda and L. K. Murugesan, “Multi-level agile project manage-ment challenges: A self-organizing team perspective,” J. Syst.Softw., vol. 117, pp. 245–257, 2016.

[23] K. Conboy, “Agility from first principles: Reconstructing the con-cept of agility in information systems development,” Inf. Syst.Res., vol. 20, no. 3, pp. 329–354, 2009.

[24] M. Cataldo, J. D. Herbsleb, and K. M. Carley, “Socio-technical con-gruence: A framework for assessing the impact of technical andwork dependencies on software development productivity,” inProc. 2nd Int. Symp. Empirical Softw. Eng. Meas., 2008, pp. 2–11.

[25] M. Cataldo and J. D. Herbsleb, “Coordination breakdowns andtheir impact on development productivity and software failures,”IEEE Trans. Softw. Eng., vol. 39, no. 3, pp. 343–360, Mar. 2013.

[26] J. C.-L. Goh, S. L. Pan, and M. Zuo, “Developing the agile IS devel-opment practices in large-scale IT projects: The trust-mediatedorganizational controls and IT project team capabilitiesperspectives,” J. Assoc. Inf. Syst., vol. 14, no. 12, pp. 722–756, 2012.

[27] T. Dingsøyr and N. B. Moe, “Towards principles of large-scaleagile development,” in Proc. XP Int. Workshop Agile Methods Large-Scale Develop. Refactoring Testing Estimation, 2014, pp. 1–8.

[28] T. Dingsøyr, N. B. Moe, T. E. Fægri, and E. A. Seim, “Exploringsoftware development at the very large-scale: A revelatory casestudy and research agenda for agile method adaptation,” Empir.Softw. Eng., pp. 1–31, 2017.

[29] D. J. Reifer, F. Maurer, and H. Erdogmus, “Scaling agile meth-ods,” IEEE Softw., vol. 20, no. 4, pp. 12–15, Jul./Aug. 2003.

[30] VersionOne, “VersionOne enterprise agile platform,” State AgileSurvey Version One, 2015. [Online]. Available: http://info.versionone.com/state-of-agile-development-survey-ninth.html

[31] P. Deemer, G. Benefield, C. Larman, and B. Vodde, “The scrumprimer version 2.0,” 2012. [Online]. Available: http://www.scrumprimer.com/, Accessed on: Aug. 18, 2015.

[32] K. Schwaber and J. Sutherland, “The scrum guide,” 2011, [Online].Available: http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf, Accessed on Jun. 02, 2014.

[33] T. Kude, S. Bick, C. T. Schmidt, and A. Heinzl, “Adaptation pat-terns in agile information systems development teams,” in Proc.22nd Eur. Conf. Inf. Syst., 2014, pp. 1–15.

[34] Definition of Scrum of Scrums, Agile Alliance Scrum Guide,2016. [Online]. Available: http://guide.agilealliance.org/guide/scrumofscrums.html, Accessed on: Mar. 14, 2016].

[35] C. Larman and B. Vodde, Scaling Lean & Agile Development: Think-ing and Organizational Tools for Large-Scale Scrum, 1st ed. Boston,MA, USA: Addison-Wesley Professional, 2008.

[36] J. Sutherland, “Agile can scale: Inventing and reinventing SCRUMin five companies,” Cut. IT J., vol. 14, no. 12, pp. 5–11, 2001.

[37] M. Paasivaara and C. Lassenius, “Communities of practice in alarge distributed agile software development organization -Case Ericsson,” Inf. Softw. Technol., vol. 56, no. 12, pp. 1556–1577, 2014.

[38] G. C. Kane and M. Alavi, “Information technology and organiza-tional learning: An investigation of exploration and exploitationprocesses,”Organ. Sci., vol. 18, no. 5, pp. 796–812, 2007.

[39] M. Alavi and D. E. Leidner, “Knowledge management and knowl-edge management systems: Conceptual foundations and researchissues,”Manage. Inf. Syst. Q., vol. 25, no. 1, pp. 107–136, 2001.

[40] B. Vodde and C. Larman, “LeSS framework,” 2016. [Online].Available: http://less.works/, Accessed on: Aug. 24, 2015.

[41] D. Leffingwell, “Scaled agile framework (SAFe),” 2014. [Online].Available: http://www.scaledagileframework.com/, Accessedon: Jun. 03, 2014.

[42] K. Schwaber, “Scaled professional scrum j nexus framework,”2016. [Online]. Available: https://www.scrum.org/Resources/What-is-Scaled-Scrum?, Accessed on: Aug. 24, 2015.

[43] K. Conboy and B. Fitzgerald, “Method and developer characteris-tics for effective agile method tailoring: A study of XP expert opin-ion,”ACMTrans. Softw. Eng.Methodol., vol. 20, no. 1, pp. 1–30, 2010.

[44] B. Fitzgerald, G. Hartnett, and K. Conboy, “Customising agilemethods to software practices at Intel Shannon,” Eur. J. Inf. Syst.,vol. 15, no. 2, pp. 197–210, 2006.

[45] G. Theocharis, M. Kuhrmann, J. M€unch, and P. Diebold, “Is water-scrum-fall reality? on the use of agile and traditional developmentpractices,” in Proc. 16th Int. Conf. Product-Focused Softw. ProcessImprovement, 2015, pp. 149–166.

[46] V. T. Heikkila, M. Paasivaara, and C. Lassenius, “ScrumBut, butdoes it matter? A mixed-method study of the planning process ofa multi-team scrum organization,” Proc. ACM/IEEE Int. Symp.Empir. Softw. Eng. Meas., 2013, pp. 85–94.

[47] P. Kettunen and M. Laanti, “Combining agile software projectsand large-scale organizational agility,” Softw. Process Improv.Pract., vol. 13, no. 2, pp. 183–193, 2008.

[48] C. Fry and S. Greene, “Large scale agile transformation in an on-demand world,” in Proc. Agile Conf., 2007, pp. 136–142.

[49] V. Heikkil€a, K. Rautiainen, and S. Jansen, “A revelatory case studyon scaling agile release planning,” in Proc. 36th EUROMICROConf. Softw. Eng. Adv. Appl., 2010, pp. 289–296.

[50] L. Lagerberg, T. Skude, P. Emanuelsson, K. Sandahl, and D. Sta�hl,

“The impact of agile principles and practices on large-scale soft-ware development projects: A multiple-case study of two projectsat Ericsson,” in Proc. IEEE Int. Symp. Empirical Softw. Eng. Meas.,2013, pp. 348–356.

[51] A. Begel and N. Nagappan, “Usage and perceptions of agile soft-ware development in an industrial context: An exploratory study,”in Proc. 1st Int. Symp. Empirical Softw. Eng.Metrics, 2007, p. 10.

[52] B. Fitzgerald, K.-J. Stol, R. O’Sullivan, and D. O’Brien, “Scalingagile methods to regulated environments: An industry casestudy,” in Proc. 35th Int. Conf. Softw. Eng., 2013, pp. 863–872.

[53] J. Vlietland andH. van Vliet, “Towards a governance framework forchains of Scrum teams,” Inf. Softw. Technol., vol. 57, pp. 52–65, 2015.

[54] M. Pikkarainen, J. Haikara, O. Salo, P. Abrahamsson, and J. Still,“The impact of agile practices on communication in softwaredevelopment,” Empir. Softw. Eng., vol. 13, no. 3, pp. 303–337, 2008.

[55] D. Batra,W. Xia, D. VanderMeer, and K. Dutta, “Balancing agile andstructured development approaches to successfully manage largedistributed software projects: A case study from the cruise lineindustry,”Commun. Assoc. Inf. Syst., vol. 27, no. 1, pp. 379–394, 2010.

[56] oxforddictionaries.com, “Hybrid,” 2017. [Online]. Available:https://en.oxforddictionaries.com/definition/hybrid

[57] J. E. Mathieu, M. A. Marks, and S. J. Zaccaro, “Multiteam sys-tems,” in Handbook of Industrial, Work and Organizational Psychol-ogy, vol. 2, N. Anderson, D. S. Ones, H. K. Sinangil, andC. Viswesvaran, Eds. London, U.K.: Routledge, 2001, pp. 289–313.

[58] J. D. Thompson, Organizations in Action: Social Science Bases ofAdministrative Theory, 48th ed. New York, NY, USA: McGraw-Hill, 1967.

[59] K. Crowston, “A taxonomy of organizational dependencies andcoordination mechanisms,” in Organizing Business Knowledge: TheMIT Process Handbook, T. W. Malone, K. Crowston, and G.Herman, Eds. Cambridge, MA, USA: MIT Press, 2003, pp. 85–108.

[60] D. E. Strode and S. L. Huff, “A taxonomy of dependencies in agilesoftware development,” in Proc. 23rd Australasian Conf. Inf. Syst.,2012, pp. 1–10.

[61] J. Howison and K. Crowston, “Collaboration through open super-position,”Manage. Inf. Syst. Q., vol. 38, no. 1, pp. 29–50, 2014.

[62] K. Crowston, J. Rubleske, and J. Howison, “Coordination theoryand its application in HCI,” Inst. Softw. Res., Paper 485, 2006,[Online]. Available: http://repository.cmu.edu/isr/485, Accessedon Feb. 25, 2014.

[63] J. A. Espinosa, F. Armour, and W. F. Boh, “Coordination in enter-prise architecting: An interview study,” in Proc. 43rd Hawaii Int.Conf. Syst. Sci., 2010, pp. 1–10.

[64] H.Mintzberg, “Structure in 5’s: A synthesis of the research on orga-nization design,”Manage. Sci., vol. 26, no. 3, pp. 322–341, 1980.

[65] D. E. Strode, B. Hope, S. L. Huff, and S. Link, “Coordination effec-tiveness in an agile software development context.,” in Proc.Pacific Asia Conf. Inf. Syst., Art. no. 183, 2011.

[66] Y. Li and A. M€adche, “Formulating effective coordination strate-gies in agile global software development teams,” in Proc. 33rdInt. Conf. Inf. Syst., 2012, pp. 1–12.

[67] D. E. Strode, S. L. Huff, B. Hope, and S. Link, “Coordination inco-located agile software development projects,” J. Syst. Softw.,vol. 85, no. 6, pp. 1222–1238, 2012.

[68] M. Yuan, X. Zhang, Z. Chen, D. R. Vogel, and X. Chu,“Antecedents of coordination effectiveness of software developerdyads from interacting teams: An empirical investigation,” IEEETrans. Eng. Manag., vol. 56, no. 3, pp. 494–507, Jul. 2009.

[69] G. Lee, J. A. Espinosa, and W. H. DeLone, “Task environmentcomplexity, global team dispersion, process capabilities, andcoordination in software development,” IEEE Trans. Softw. Eng.,vol. 39, no. 12, pp. 1753–1771, Dec. 2013.

[70] K. M. Eisenhardt, “Building theories from case study research,”Acad. Manag. Rev., vol. 14, no. 4, pp. 532–550, Oct. 1989.

BICK ETAL.: COORDINATION CHALLENGES IN LARGE-SCALE SOFTWARE DEVELOPMENT: A CASE STUDYOF PLANNING... 949

[71] B. G. Glaser, Emergence versus Forcing: Basics of Grounded TheoryAnalysis.Mill Valley, CA, USA: Sociology Press, 1992.

[72] C. Soh andM. L.Markus, “How IT creates business value: A processtheory synthesis,” inProc. 16th Int. Conf. Inf. Syst., 1995, pp. 29–41.

[73] D. Robey, M. L. Markus, and D. Robey, “Information technologyand organizational change: Causal structure in theory andresearch,”Manage. Sci., vol. 34, no. 5, pp. 583–598, 1988.

[74] P. Ralph, “Software engineering process theory: A multi-methodcomparison of sensemaking-coevolution-implementation theoryand function-behavior-structure theory,” Inf. Softw. Technol.,vol. 70, pp. 232–250, 2016.

[75] R. Hoda and J. Noble, “Becoming agile: A grounded theory ofagile transitions in practice,” in Proc. Int. Conf. Softw. Eng., 2017,pp. 141–151.

[76] R. K. Yin, Case Study Research: Design and Methods, 4th ed.Thousand Oaks, CA, USA: SAGE Publications Inc., 2009.

[77] A. S. Lee, “A scientific methodology for MIS case studies,”Manage. Inf. Syst. Q., vol. 13, no. 1, pp. 33–50, 1989.

[78] K. M. Eisenhardt and M. E. Graebner, “Theory building fromcases: Opportunities and challenges,” Acad. Manag. J., vol. 50,no. 1, pp. 25–32, 2007.

[79] K.-J. Stol, P. Avgeriou, M. A. Babar, Y. Lucas, and B. Fitzgerald,“Key factors for adopting inner source,” ACM Trans. Softw. Eng.Methodol., vol. 23, no. 2, pp. 1–35, 2014.

[80] R. Hoda, J. Noble, and S. Marshall, “Developing a groundedtheory to explain the practices of self-organizing Agile teams,”Empir. Softw. Eng., vol. 17, no. 6, pp. 609–639, 2012.

[81] B. G. Glaser, Theoretical Sensitivity: Advances in the Methodology ofGrounded Theory. Mill Valley, CA, USA: Sociology Press, 1978.

[82] M. Cataldo, P. A. Wagstrom, J. D. Herbsleb, and K. M. Carley,“Identification of coordination requirements: Implications for thedesign of collaboration and awareness tools,” in Proc. ACM20th Anni-versary Conf. Comput. Supported CooperativeWork, 2006, pp. 353–362.

[83] A. Borici, K. Blincoe, A. Schr€oter, G. Valetto, and D. Damian,“ProxiScientia: Toward real-time visualization of task and developerdependencies in collaborating software development teams,” in Proc.ICSEWorkshopCooperative HumanAspects Softw. Eng., 2012, pp. 5–11.

[84] C. R. B. de Souza, T. Hildenbrand, and D. Redmiles, “Towardvisualization and analysis of traceability relationships in distrib-uted and offshore software development projects,” in Proc. 1st Int.Conf. Softw. Eng. Approaches Offshore Outsourced Develop., 2007,pp. 182–199.

[85] T. Hildenbrand, Improving Traceability in Distributed CollaborativeSoftware Development: A Design Science Approach, 1st ed. Frankfurt,Germany: Peter Lang, 2008.

[86] P. Dourish and V. Bellotti, “Awareness and coordination inshared workspaces,” in Proc. ACM Conf. Comput.-Supported Coop-erative Work, 1992, pp. 107–114.

[87] E. Whitworth and R. Biddle, “The social nature of agile teams,” inProc. Agile Conf., 2007, pp. 26–36.

[88] E. Litwak and L. F. Hylton, “Interorganizational analysis:A hypothesis on co-ordinating agencies,” Adm. Sci. Q., vol. 6,no. 4, pp. 395–420, 1962.

[89] A. H. Van de Ven, A. L. Delbecq, and R. Koenig, “Determinants ofcoordination modes within organizations,” Am. Sociol. Rev.,vol. 41, no. 2, pp. 322–338, 1976.

[90] J. R. Galbraith, “Organization design: An information processingview,” Interfaces (Providence), vol. 4, no. 3, pp. 28–36, 1974.

[91] K. Srikanth and P. Puranam, “Integrating distributed work:Comparing task design, communication, and tacit coordinationmechanisms,” Strateg. Manag. J., vol. 32, no. 8, pp. 849–875, 2011.

[92] A. Lindberg, N. Berente, J. Gaskin, and K. Lyytinen, “Coordinatinginterdependencies in online communities: A study of an open sourcesoftware project,” Inf. Syst. Res., vol. 27, no. 4, pp. 751–772, 2016.

[93] M. Cataldo, A.Mockus, J. A. Roberts, and J. D. Herbsleb, “Softwaredependencies, work dependencies, and their impact on failures,”IEEE Trans. Softw. Eng., vol. 35, no. 6, pp. 864–878, Nov./Dec. 2009.

[94] R. W. Zmud, “Management of large software developmentefforts,”Manage. Inf. Syst. Q., vol. 4, no. 2, pp. 45–55, 1980.

[95] Rally Ready >Sync >Go. [Online]. Available: https://www.rallydev.com/, Accessed on: Aug. 24, 2015.

[96] A. S. Lee and R. L. Baskerville, “Generalizing generalizability ininformation systems research,” Inf. Syst. Res., vol. 14, no. 3,pp. 221–243, 2003.

[97] J. P. Davis, K. M. Eisenhardt, and C. B. Bingham, “Developing the-ory through simulation methods.,” Acad. Manag. Rev., vol. 32,no. 2, pp. 480–499, Apr. 2007.

Saskia Bick received the BA degree in interna-tional management from the University of AppliedSciences FH Joanneum in Graz, Austria, in 2010and the MSc degree in management and thePhD degree in information systems both from theUniversity of Mannheim, Germany, in 2013. Sheis currently working as a program lead and agilecoach with SAP SE and is a certified scrum mas-ter. Her research interests include agile softwaredevelopment, inter-team coordination and depen-dency management.

Kai Spohrer received the PhD in information sys-tems from the University of Mannheim in 2015 forhis dissertation on the effects of collaborativequality assurance on team cognition in softwaredevelopment teams. He is an assistant professorin information systems with the University ofMannheim, Germany. His research has appearedat major international conferences and he recei-ved a best paper award from the InternationalConference on Intelligent Environments. His res-earch interests include coordination and teamcognition in software development and IT health-care. He is an active member of the AIS.

Rashina Hoda received the bachelor’s degree incomputer science from LSU (USA) and the PhDdegree from Victoria University of Wellington, NewZealand. She is a senior lecturer in software engi-neering in the Department of Electrical and Com-puter Engineering, The University of Auckland,Auckland, New Zealand, where she leads theSEPTA research group. She is a certified scrummaster. Her papers appear in the IEEE Transac-tions on Software Engineering, the Information andSoftware Technology, the Empirical Software Engi-

neering, the Journal of Systems and Software, the IEEE International Con-ference on Software Engineering, and others. Her research interestsinclude human aspects of software engineering, in particular, agile softwaredevelopment, and HCI. She received a distinguished paper award atICSE2017, and has served as the research chair of Agile India 2012 and asassociate editor for ICIS (2015-2016). She is an activemember of the IEEE.

Alexander Scheerer received the diploma(M.Sc. equivalent) degree in information systemsin 2011 and the PhD degree in information systemsboth from the University of Mannheim, Germany.His research has appeared at major internationalconferences including International Conferenceon Information Systems. He is working as anagile coach and scrum master with SAP SE. Hisresearch interests include large-scale agile soft-ware development and inter-team coordination.

Armin Heinzl received the doctoral degree in1990 and the habilitation in 1995 from theKoblenz Corporate School of Management(WHU). He is a professor and chair in generalmanagement and information systems with theUniversity of Mannheim, Germany. He was a fullprofessor with the University of Bayreuth and hasheld visiting positions with Harvard, Berkeley,Irvine, ESSEC and LSE. His papers haveappeared in MIS Quarterly, the Journal of theAssociation of Information Systems, the IEEE

Transactions on Engineering Management, the Journal of Business Eco-nomics, the Journal of Organizational Computing and E-Commerce, theEvolutionary Computation, and others. His research and teaching inter-ests include IT outsourcing and governance, software developmentprocesses as well as human information behavior. He is vice editor inchief of the journal Business & Information Systems Engineering and anactive member of the ACM and the AIS.

950 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 44, NO. 10, OCTOBER 2018