A Coordination Perspective on Agile Software Development Diane E. Strode Whitireia Polytechnic, New Zealand
[email protected] Sid L. Huff Ivey Business School, Canada This chapter is forthcoming in: Strode, D. E., & Huff, S. L. (2014). A coordination perspective on agile software development. In S. Gao & L. Rusu (Eds.), Modern Techniques for Successful IT Project Management (pp. 128). Hershey PA, USA: IGI Global.
A Coordination Perspective on Agile Software Development Diane E. Strode Whitireia Polytechnic, New Zealand Sid L. Huff Ivey Business School, Canada
ABSTRACT Achieving success in software development projects is a perennial challenge and agile software development methods emerged to tackle this challenge. Agile software development provides a way to organise complex multi-participant software development projects while achieving fast delivery of quality software, meeting customer requirements, and coping effectively with project change. There is little understanding, however, of how such projects achieve effective coordination, which is a critical factor in successful software projects. Based on evidence from four cases, this chapter presents a theory explaining coordination in agile software projects. Three cases of agile software development contribute to the theory and a single non-agile case provides contrasting evidence. This theory defines the concepts of coordination strategy and coordination effectiveness and propositions explaining their relationship. This theory contributes to coordination literature by presenting clearly delineated concepts and their relationships in the form of a variance theory. For IT project management, this theory contributes to knowledge of coordination and coordination effectiveness in the context of agile software development.
INTRODUCTION “How can software development projects be coordinated more effectively in the presence of uncertainty?” (Nidumolu, 1995, p. 213) Agile software development offers an effective means of organising complex multi-participant software development while continuously adjusting to project uncertainty and change. While this approach is now widely accepted, it remains of intense practical and theoretical interest because of its impact on people, projects, and organisations (Ambler, 2009; Dyba & Dingsoyr, 2008; Strode, Huff, Hope, & Link, 2012; West & Grant, 2010). Agile software development differs significantly from earlier approaches to software development; because of this difference, adopting an agile approach can affect organisation structure and culture, project roles, contract negotiation, the way customers are involved in projects, system quality, and system deployment. In addition, the agile approach changes technical practices, team social interaction, team leadership, and decision-making. These wide-ranging effects mean that existing theories about software development organisations, project management, and system development need to be re-evaluated in light of this new systems development paradigm (Dingsoyr, Dyba, & Moe, 2010). This chapter contributes to this re-evaluation by presenting a theory of agile software development from a coordination perspective.
2
Long before the advent of agile software development, researchers identified effective coordination as a critical element in organisations generally, and in software development projects in particular (Curtis, Krasner, & Iscoe, 1988; Kraut & Streeter, 1995; Van de Ven, Delbecq, & Koenig, 1976). Nidumolu (1995) articulated the problem when he asked how software development projects could be effectively coordinated in the presence of uncertainty. Shortly thereafter, software developers and systems methodologists designed their agile methods specifically to deal with change and uncertainty. These methods de-emphasize traditional coordination mechanisms such as forward planning, extensive documentation, detailed contracts, strict adherence to a pre-specified process, and specific coordination roles such as that of the project manager. Instead, they favour intensive face-to-face communication and other apparently simple practices. Yet, agile software development has contributed to the success of many software projects, so arguably effective coordination of some type takes place within these projects (Agerfalk, Fitzgerald, & Slaughter, 2009; Cao & Ramesh, 2007; Dingsoyr, Dyba, & Abrahamsson, 2008; Kautz, Madsen, & Norbjerg, 2007). A large and diverse body of coordination research exists in contexts relevant to software development practice, but agile software development came into common use subsequent to much of that research. Therefore, we do not know whether existing theory adequately explains coordination within agile software development projects, or whether a new explanatory theory is needed. In studying coordination, there are two primary considerations. The first is to identify a coordination strategy, that is, those activities and artefacts in a situation that support coordinated action. The second is to identify the characteristics of a highly coordinated state. Once we understand these two aspects of coordination, it becomes possible to investigate which activities and artefacts are more, or less, effective at bringing about a highly coordinated state. Consequently, our study was guided by two research questions. How is coordination achieved when using an agile software development approach, and what is the relationship between coordination strategy and project coordination effectiveness in the context of agile software development? Following the guidelines of Eisenhardt and Graebner (2007) for theory building from positivist multi-case studies, in this chapter we develop a theory of agile software development project coordination by drawing on evidence from three independent cases of agile software development. A single contrasting case where the project was carried out with a non-agile approach is included to illustrate the boundaries of the theory. The case evidence shows that many practices in the agile projects act as coordination mechanisms. Together, these mechanisms form a project’s coordination strategy, which has three components: synchronization, structure, and boundary spanning. The cases also show that an agile coordination strategy leads to coordination effectiveness, which has both implicit and explicit components. We elaborate the relationships between these concepts in a series of propositions. The chapter is organised as follows. First, we review the current state of research on agile software development. Then we discuss coordination research in organisation studies, information systems project studies, and teamwork. Then we discuss research associating coordination with agile software development. Following this, we define our conceptual framework for the study and explain how the concepts of coordination strategy and coordination effectiveness fit within a general framework of project success. We describe our case study research method and the research findings. We then present our theoretical model of coordination in agile software development projects, with supporting evidence from the cases. Propositions linking the concepts of coordination strategy and coordination effectiveness are developed and presented. The discussion section addresses the research questions and discusses the contributions of the research to IT theory and practice. We then conclude the chapter and reflect on how further research can build on this theory of coordination.
3
LITERATURE REVIEW The Agile Development Approach Agile methods emerged in the 1990s as a reaction against existing “heavyweight” systems development methodologies that involved detailed planning, extensively documented development processes, detailed system designs, and strict project role divisions. These heavyweight methods were often unsuccessful in practice (Avison & Fitzgerald, 2006; Iivari, Hirschheim, & Klein, 2004; Olle, Sol, & Tully, 1983). In contrast, agile methods were designed to be “lightweight” to support flexible, rapid, and effective development under conditions of change, uncertainty, and time pressure (Dyba & Dingsoyr, 2008). “Agile software development” has become the catchall term describing the use of any agile method, or combination of agile methods. There are more than ten different agile methods (Strode, 2006), the most popular being Scrum, Extreme Programming (XP), and XP-Scrum hybrids (VersionOne, 2013; West & Grant, 2010). Each agile method consists of a cohesive set of practices and has a distinct focus. For example, Scrum focuses on project management, whereas XP provides techniques for rapidly producing quality software (Beck, 2000; Schwaber & Beedle, 2002). A comprehensive assessment of industrial surveys of agile software development by Stavru (2014) shows that usage of agile methods world-wide is reported at about 55%, however, these surveys vary widely in their trustworthiness. Agile methods conform to a published set of values and principles for conducting systems development (Abrahamsson, Warsta, Siponen, & Ronkainen, 2003; Hilkka, Tuure, & Matti, 2005). This unifying philosophy, published as an agile manifesto, is based on commonalities in the methods identified by early agile method authors (Beck et al., 2001). This philosophy emphasises the importance of individuals and their interactions, teamwork, production of early working software, collaboration with customers, and responding effectively to change. This is in contrast to the traditional software development focus on process, tools, documentation, contract negotiation, and following plans. Each agile method conforms only loosely to this philosophy (Conboy, Fitzgerald, & Golden, 2005). There is a substantial body of research on agile software development which follows a recognised pattern of increasing maturity from 2000 to 2014 (von Krogh, Rossi-Lamastra, & Haefliger, 2012). Initially, the research consisted of subjective personal accounts of how practitioners carried out agile software development (e.g., Marchesi, Succi, Wells, & Williams, 2003). Emerging next were objective studies employing ethnographic methods describing what occurs in these projects (Sharp & Robinson, 2004). Case studies of iterative and incremental development, studies reporting spontaneously occurring agile practices, and scalability and tailoring studies also emerged (Baskerville & Pries-Heje, 2004; Conboy & Fitzgerald, 2007; Dingsoyr et al., 2008; MacCormack, Verganti, & Iansiti, 2001; Sharp & Robinson, 2008). In 2008, Dyba and Dingsoyr comprehensively reviewed this emerging literature, identifying a lack of rigor in the body of research. Since 2008, research on agile development has generally become more rigorous and diverse, addressing various salient aspects of the agile approach. Researchers have defined agility (Conboy, 2009), developed success criteria (Misra, Kumar, & Kumar, 2009; Stankovic, Nikolic, Djordjevic, & Cao, 2013), simulated the integration and outcomes of agile practices (Cao, Ramesh, & Abdel-Hamid, 2010), and identified the effect of organisation culture on agile adoption (Strode, Huff, & Tretiakov, 2009). Research on the agile approach has contributed to understanding how agile adoption influences decision-making (Drury-Grogan & O'Dwyer, 2013), creativity (K. T. Goh, Goodman, & Weingart, 2013), globally distributed projects (J. C. Goh, Pan, & Zuo, 2013; Ramesh, Cao, Mohan, & Xu, 2006), and project funding (Cao, Mohan, Ramesh, & Sarker, 2013). As the body of research has become more mature, researchers have applied existing theories from other domains to better understand the phenomenon. Dingsoyr, Nerur, Balijepally, and Moe (2012) summarise a number of these studies. Most recently, research involving measurement of aspects of the agile approach has emerged. Examples include a seminal study of the XP practice of pair programming (Balijepally, Mahapatra, Nerur, & Price, 2009), studies of project control (Maruping, Venkatesh, & Agarwal, 2009), and the impact of agile software development on project performance (Lee & Xia, 2010). 4
Surprisingly, very little of this growing body of research utilizes a coordination perspective to explain agile software development, even though coordination is a critical issue in software development (Curtis et al., 1988; Espinosa, Slaughter, Kraut, & Herbsleb, 2007; Hoegl & Gemuenden, 2001; Kraut & Streeter, 1995; Nurmi, 2009). The following section reviews coordination literature pertinent to software development in general and describes the small body of research directly associating coordination with agile software development.
Coordination Research “When multiple actors pursue goals together, they have to do things to organize themselves that a single actor pursuing the same goals would not have to do. We call these extra organizing activities coordination” (Malone, 1988, p.5). Since a software development project team involves multiple actors working together to pursue the common goal of developing a software product, this definition provides a useful starting point for understanding coordination in this context. Early work on coordination was carried out by organisation theorists who considered coordination to be a key determinant of organisation structure. They identified various coordination modes. Coordination can be impersonal or codified, achieved by feedback, and take place in group mode or personal mode (Galbraith, 1977; Malone, 1987; March & Simon, 1958; Mintzberg, 1980; Thompson, 1967; Van de Ven et al., 1976). This classical organisational coordination theory was primarily developed in the context of routine work in work units rather than non-routine knowledge-based software development work in a project context. Therefore, this branch of coordination studies might not be directly applicable to agile software development projects. Based on an extensive literature review, Okhuysen & Bechky (2009) updated this classical coordination literature. They argue for five coordination mechanisms and three integrating conditions in organisations. Coordination mechanisms are plans and rules, objects and representations, roles, routines, and proximity with integrating conditions of accountability, predictability, and common understanding. Although Okhuysen et al. (2009) consider the framework is applicable to all organisational contexts its applicability to small co-located agile software development projects is unexplored. Malone and Crowston (1994) proposed an influential theory of coordination explaining fundamental concepts of coordination based on ideas and concepts from computer science, organisation theory, management science, economics, linguistics, and psychology. Their central tenet was that “coordination is the managing of dependencies” (Malone & Crowston, 1994, p.90). Their key ideas were: 1) a dependency occurs when the progress of one action relies on the timely output of a previous action or the presence of some specific thing; 2) coordination is needed to address dependencies; and 3) coordination is achieved by one or more coordination mechanisms, each of which addresses one or more dependencies in a situation. This theory is useful for identifying and categorising dependencies and coordination mechanisms in a situation. The present study uses Malone and Crowston’s (1994) theory of coordination as a basis for analysing dependencies and coordination mechanisms in agile software development projects. In information systems research, coordination is acknowledged as a contributing factor in software project success. Studies in this domain tend to draw on coordination concepts from organisation studies. This research is diverse, and a variety of contexts have been studied (e.g. IT projects, software projects, student projects, software teams) and a variety of “success” constructs are used (e.g. project satisfaction, productivity, process success, team effectiveness) (Aladwani, 2002; Andres & Zmud, 2001; Chen, Jiang, Klein, & Chen, 2009; MacCormack et al., 2001; Nidumolu & Subramani, 2004). Overall, this body of research shows that effective coordination is necessary but not sufficient for the success of software projects (Curtis et al., 1988; Espinosa, Lerch, & Kraut, 2002; Kraut & Streeter, 1995; Nidumolu, 1995). Coordination is also of interest in teamwork research where the focus is on implicit coordination. Implicit coordination takes many forms. Shared cognition is implicit coordination occurring within work groups without explicit speech or message passing (Rico, Sanchez-Manzanares, Gil, & Gibson, 2008). Other 5
forms of implicit coordination occur via shared mental models (Kang, Yang, & Rowley, 2006; Yuan, Vogel, Zhang, Chen, & Chu, 2007), collective mind (Weick & Roberts, 1993), expertise coordination (Faraj & Sproull, 2000), or team mental models (Mohammed, Ferzandi, & Hamilton, 2010). Research has also identified a team cognition coordination concept (Fiore & Salas, 2004). Although these concepts are all slightly different, together they suggest that there is more to coordination than the explicit forms referred to in Malone and Crowston’s (1994) coordination theory and in organisation theory more generally. Another carefully argued theoretical framework drawing on all of this prior research and amalgamating implicit and explicit coordination, coordination in teams, and coordination in distributed work groups was developed by Espinosa, Lerch, and Kraut (2004). This framework was developed to explain coordination in distributed teams, including distributed software development teams. Cao and Ramesh (2007) were perhaps the first to recognise that classical coordination theory might explain why agile software development is effective. They argued that the coordination mechanisms suggested by agile methods are consistent with the coordination mechanisms proposed by organisation theorists and proposed that agile software development projects will use more personal and group coordination modes. More recently, Barlow, Giboney, Keith et al. (2011) have argued for a methodology selection framework based on the organisation theorist Thompson’s (1967) ideas on interdependencies and coordination, that is coordination by standardisation, planning, and mutual adjustment. Neither of these studies have an empirical basis. In agile software development contexts, ethnographic and case studies research have observed a variety of coordinative practices in co-located and distributed agile projects. For example, MacKenzie, and Monk (2004) observed that coordination in an XP project was achieved using unit testing, card games for planning, and a concurrent versioning system. Sharp, Robinson and Petrie (2009) researched six agile teams over five years and observed that a publically viewable wallboard displaying stories, tasks, work allocations, and progress to completion was a significant coordinating mechanism in these projects. Pikkarainen et al. (2008) applied Malone and Crowston’s ((1994) coordination theory to data from two co-located agile projects and concluded that communication substituted for documentation in coordinating these projects. Hoda, Marshall, and Noble (2010) identified a coordinator role that emerges in small co-located agile projects. Furthermore, after performing a longitudinal case study of distributed development across India and Denmark, Pries-Heje and Pries-Heje (2011) showed that Scrum is effective as a project management approach because it provides appropriate mechanisms for coordination, communication, social integration, and control. Although there are many approaches to studying coordination in the extant literature, all have shortcomings in explaining or predicting the effectiveness of agile software development. To date, coordination research in the agile context has been either purely conceptual or has identified which practices act to achieve coordination. There appear to be few empirically-based studies developing theory with coordination as a central lens.
Conceptual Framework The conceptual framework for the present study draws on two of the previously mentioned theories of coordination. The first, proposed by Espinosa, Lerch, and Kraut (2004), was built from arguments and empirical studies of teamwork coordination in distributed software development and other organisational contexts. Although their theory is not immediately applicable to co-located agile projects, it does provide two directly relevant coordination concepts and it is the most broad-based theory available that is grounded to some extent on coordination in software projects. This theory provides two overarching concepts that are adapted for our conceptual model. Espinosa et al. (2004) propose that task dependencies are managed with coordination mechanisms, and that coordination mechanisms interact in a process of “coordinating” to bring about a “state of coordination.” We have relabelled these concepts to make a clearer distinction between them. Coordinating becomes “coordination strategy”. We use the term 6
strategy in the sense of “an instance” rather than “a plan” (Allen, 1990). Strategy concerns what is done in a project to achieve coordination. State of coordination becomes “coordination effectiveness”, which is the outcome of a coordination strategy. The second theoretical contribution came from Malone and Crowston’s (1994) coordination theory. Their notion, that coordination mechanisms are used to manage, or address, dependencies in a situation, is central to the concept of coordination strategy in our study. Therefore, embedded within our conceptual framework are the following two principles:
A dependency occurs when the progress of one action relies upon the timely output of a previous action, or the presence of some specific thing. A coordination mechanism is an entity (person or artefact) or activity (practice or technique) addressing one or more dependencies in a situation.
Furthermore, the conceptual framework in our study proposes that coordination mechanisms in typical colocated agile software development projects consist of various agile method practices (e.g., pair programming, sprint backlog, information board) along with other development practices (e.g., configuration management tools) not specific to agile methods. All such coordination mechanisms might contribute to project coordination, not just those that are agile software development practices. This led to the following definition.
A coordination strategy is manifested as a group of coordination mechanisms used in a situation. Coordination mechanisms form a strategy because they are selected consciously by project stakeholders, rather than occurring without forethought.
Drawing from these arguments, the conceptual framework guiding this study is depicted in Figure 1. The literature review identified that coordination contributes to software project success (Espinosa et al., 2004) and this is also shown in Figure 1, but the focus of the study is solely on coordination, therefore project success and its other antecedents are considered outside the scope of the study. Insert here: Figure 1 The conceptual framework of coordination in agile software development projects
The preceding arguments led to the formulation of two research questions: 1. How is coordination achieved when using an agile software development approach? 2. What is the relationship between coordination strategy and project coordination effectiveness in the context of agile software development? Answering these questions required a stepwise process. The first step was to identify the coordination strategy of each case of agile software development. To understand the coordination strategy of a case the dependencies and the coordination mechanisms they address were identified. Based on the findings from the three cases of agile software development, a generic coordination strategy was defined. The second step was to define coordination effectiveness based on the findings from the three cases of agile software development. The third step was to explore the relationship between coordination strategy and coordination effectiveness based on the findings from the three cases of agile software development. Finally, to explore the boundary of the theory and assess how well it explains agile software development projects rather than software development projects in general, the coordination strategy and coordination effectiveness of a non-agile project was compared with that of the agile projects.
RESEARCH METHODOLOGY To explore the concepts identified in the conceptual framework and answer the research questions we used a positivist multi-case study research approach. This is a well-accepted way to investigate 7
phenomena in systems development contexts when events cannot be controlled and when it is important to capture the detail in the situation (Darke, Shanks, & Broadbent, 1998; Eisenhardt, 1989; Pare, 2004; Yin, 2003). Furthermore, this method is suitable for building testable theory, which was the principal objective of the research (Eisenhardt & Graebner, 2007). The unit of analysis, or case of interest, was the agile software development project with co-located participants. Case selection followed a replication logic strategy, which is a tactic recommended in case study design (Eisenhardt, 1989; Miles & Huberman, 1994; Pare, 2004; Yin, 2003). This involves selecting cases that are similar and therefore likely to provide similar results (literal replications), or selecting dissimilar cases that are likely to provide contrasting results for predictable reasons (theoretical replications). The study consisted of three literal replications of agile software development projects. One theoretical replication, which was a project not using an agile method, was also selected. This number of cases was deemed large enough to identify patterns of coordination across cases, while providing detail rich enough to ensure coordination mechanisms could be thoroughly explored within each case. This design also provided evidence to clarify if findings from agile projects would be similar or dissimilar to that of nonagile projects. Each project was a ‘typical’ case selected because it was expected to show normal or average characteristics (Pare, 2004). The cases of agile software development met pre specified selection criteria regarding the development method, team size, and location. Projects were selected if they were using XP, Scrum, or a combination of practices from these methods. The team size had to be between 2 and 10 team members, and team members had to be co-located. The non-agile project was selected according to the same size and co-location criteria as the agile projects. When selecting interviewees we gathered data from people taking a range of roles within each project such as programmers, analysts, project leaders, and testers to ensure a variety of perspectives on the project, its dependencies, and coordination mechanisms. Whenever possible we interviewed at least half of the people on each team. The primary data collection method was semi-structured interviews of project team members. An interview schedule appropriate for collecting data on coordination in software development projects was developed based on suggestions by Crowston (1991) for identifying coordination mechanisms and dependencies, McChesney and Gallagher (2004) for software project profiles, and Spradley (1979) for interviewing in natural situations. In each project, the selected project team members were interviewed individually for up to 1½ hours using a standard set of questions. Points of interest or unclear responses arising in the interviews or during observation sessions were probed for further explanation. Source data included the interview transcripts, field notes taken during observation of work sites and when attending meetings, project documents, photographs of the work sites, and questionnaire data. Questionnaires were used to gather data efficiently on the organisation, project, and the agile method practices used on a project. These interview schedules and questionnaires are available in Strode (2012). Interviews of project team members focused on three topics: specific questions about the participants’ background, open-ended questions about the participants’ daily work practices to elicit the coordination mechanisms used in the project, and three final questions designed to elicit perceptions of project coordination effectiveness including: 1. What makes this project well-coordinated? 2. What interferes with coordination on this project? 3. In your opinion, based on all of the software development projects you have worked on, what is a well-coordinated project? The first step in data analysis was to prepare a full description of each case using a common framework. This description included details of the organisation, project, technologies, team, development method,
8
and any problems in the project that emerged during the interviews. The description was sent to one project participant for verification, and any factual errors found in the description were corrected. The second step in data analysis was within-case analysis. All interviews were transcribed and entered into the qualitative data analysis tool NVivo™ for ease of qualitative coding. A general inductive coding approach was followed (Miles & Huberman, 1994; Thomas, 2006) guided by heuristics for analysing dependencies and coordination mechanisms developed by Crowston and Osborne (2003). Their two-part procedure includes:
Dependency-focused analysis. Identify dependencies, and then search for coordination mechanisms. In other words, look for dependencies and then ask which activities manage those dependencies. Failure to find such activities might suggest potentially problematic unmanaged dependencies. Activity-focused analysis. Identify coordination mechanisms, and then search for dependencies. In other words, identify activities in the process that appear to be coordination activities, and then ask what dependencies those activities manage. This approach asks directly whether all observed coordination activities are necessary (Crowston & Osborn, 2003, p. 352).
Each case was analysed independently of the others using both dependency-focused and activity-focused analysis. This produced analytical codes describing the instances of coordination and dependency identified in the transcripts. Codes identified in the first case were used as starter codes for the second case, and codes from the second case acted as starter codes for the third case, and so on. New codes were added as they emerged from each case during the analysis. The final step was to check all cases against the final list of codes. To address validity and reliability we followed the guidelines of Dubé and Paré (2003). They describe 34 quality criteria to achieve rigor and address validity and reliability in positivist case study research in information systems. Each criteria relevant to a single researcher, multi-case study was met in this study.
THE CASES The three agile software development projects were code named Land, Storm, and Silver, and the nonagile case was named Rock. Table 1 provides key project data, shows the number of interviews carried out, and the roles of the interviewees. The four cases were similar in size and were all co-located. They varied in two dimensions, complexity and the extent of customer collaboration. Storm was the most complex project because it had the largest team and involved replacing a legacy system with multiple new systems that had to be integrated seamlessly with one another and with systems in New Zealand and internationally. Silver was moderately complex with new technologies for the developers to learn while reproducing a straightforward reporting system. Land was the simplest system involving a single developer working with a business analyst, web designer, and three customer proxies, and the new system was developed with well-understood technologies. The second dimension where the projects varied was in the extent of involvement of the customer (or knowledgeable end user) with the team. Although in Scrum and XP projects it is considered best practice to embed a permanent customer representative in the team, typically this does not occur. This situation has been reported by Cao, Ramesh and Baskerville (2007) in 10 cases of XP and Scrum, and in three XP cases by Martin, Biddle, and Noble (2004). In Storm, the end-user group was committed to and concerned about the project but they were not consistently available for consultation. This group consisted of 80 people working on rotating shifts and no one customer representative was constantly available for consultation. These end-users were located in a room adjacent to the software project team. Land had three proxy end-users (the true end user was the New Zealand public using the services of the organisation) who were considered part of the team, but they were not constantly available because they were located elsewhere in the building at times and were involved in other projects too. Silver’s customer was in a client organisation and direct communication with end-users was difficult to arrange. A designated manager from the client organisation provided 9
requirements, and that person was difficult to contact. In Rock, the complexity of the project was similar to Storm in team size, the multiple systems to integrate. Rock was similar to Land in that the customer was the general public using the services provided by the organisation. No customer representative was co-located within Rock and the business analyst determined requirements by consulting within the business in the early phase of the project and writing business use cases. Multiple internal stakeholders in various business units had a strong interest in the project outcome and they were consulted occasionally on requirements during the project. Table 1 Overview of the cases Land Organisation type Organisation size Project purpose
Government
Contractual basis
In-house development
Development methodology Team size Interviews Roles of interviewees
Storm
Silver
Rock
Commercial service provider 200 in Australasia, Asia and Europe To migrate a critical legacy system to a modern technology platform
Commercial software development firm 20 in NZ
Retail bank
To provide a replacement reporting system for an external client Development for external client
Scrum
Independent contractors working on the client site Scrum and XP
To replace and enhance an online system for viewing transaction information In-house development
Scrum and XP
Waterfall
6
10
5
2 Project manager Software developer
5 Project manager Software developers (2) Tester Domain expert
4 Development manager Scrum coach Software developers (2)
7 (rising to 15 in the final phase) 4 Business analyst Analyst programmer Test analyst Technical designer
2000 in NZ To improve the organisations’ interactions with the public
5000+
Dependency analysis Each case was analysed using the dependency-focused analysis technique to identify the project’s dependencies. An example of the analysis of some dependencies from project Land is shown in Table 2. Each instance of a dependency found in the transcripts was given a meaningful label (e.g., expertise dependency) and a definition. The explanation column in Table 2 shows the logic used to link the dependency with a coordination mechanism. This analysis uncovered the following dependencies: expertise, requirement, task allocation, historical, activity, business process, technical, and entity dependencies. Salient aspects of these dependencies were used to group them into a three distinct higher-level dependency categories: knowledge dependencies, task dependencies, and resource dependencies. Knowledge dependencies included expertise, requirement, task allocation, and historical dependencies. Task dependencies included activity and business process dependencies, and resource dependencies included technical and entity dependencies. Strode and Huff (2012) and Strode (2013) describe further details of this aspect of the research. Note that each dependency
10
was not found in every case, for example Land did not provide evidence for the historical or technical dependencies found in Silver and Storm (see Figure 2).
Table 2 Examples of dependencies in project Land Dependency Expertise
Definition A situation wherein technical or task information is known only by a particular person and this affects progress
Requirement
A situation wherein domain knowledge or a requirement is not known and must be located or identified and this affects progress
Evidence “…in terms of who to ask within the business specific questions, year, it was in the weekly meetings, I figured out that Brian was doing this, Mary was doing this, and the other Mary had a different role entirely.” [Land, Project Manager] “So, in our sprint planning meetings we would figure out what was needed for the next sprint and do some kind of design work on what the screen might look like, exactly what validation was required, those kinds of things.” [Land, Project Manager]
Explanation The developer discovered the role and expertise (dependency) of the other team members at the weekly sprint planning meetings (coordination mechanism). Without this information, the developer would not know who to go to for information about the existing system functions or information on technical support issues. The whole team sat together in the iteration planning meeting (sprint) (coordination mechanism), planning the tasks to complete in the coming iteration and working together to formalise requirement details. Without this session, the developer and other team members would not know the requirement details (dependency).
Coordination mechanism analysis Each case was analysed using the activity-focused analysis technique to identify coordination mechanisms. The complete set of coordination mechanisms identified in a case comprised its unique coordination strategy. To form the coordination strategy for a case, individual coordination mechanisms were identified then grouped into higher-level categories based on their similar functions. Over all agile projects, eight distinct types of coordination mechanisms were found and named synchronisation activities, synchronisation artefacts, boundary spanning artefacts, boundary spanning activities, availability, proximity, substitutability, and a coordinator role. Table 3 states the definitions for each of these coordination mechanisms and provides illustrative quotes from the case interviews. This analysis allowed us to construct a 2 x 2 table for each case showing each dependency and its associated coordination mechanisms. Figure 2 is an example of one of these tables. Each coloured cell in the table comprises one or more pertinent evidentiary quotes from the case. Figure 2 shows two examples of such quotes. Note that evidence for each coordination mechanism was not found in every case, for example, Land did not provide evidence for boundary spanning activity or the coordinator role. A complete list of all coordination mechanisms found in each case is available in Strode (2012). Insert here: Figure 2 Dependencies and coordination mechanisms for project Land
11
A THEORY OF COORDINATION IN AN AGILE CONTEXT Our theory of coordination in co-located agile software development projects was developed from the case analyses. According to Weber (2012), a theory has five elements including things of interest (concepts or constructs), associations between concepts, system states defining how theoretical concepts interact, boundaries defining the limits of a theory, and propositions. Propositions are the logical consequences or predicted outcomes of the interactions between theoretical concepts. We built the theory inductively and systematically from case evidence but we present the theory according to the elements of theory. First, we present the concepts, then the associations, system states and boundaries, and finally the propositions. Strode, Huff, Hope, and Link (2012) have presented a prior version of this theory. In the present version, we have simplified the theory presentation by removing the antecedents to coordination strategy described in the initial version. In addition, in this chapter we draw on evidence from a non-agile project to illustrate the boundaries of the theory. Figure 3 shows the theory as a diagram. The numbers in Figure 3 indicate propositions linking the theoretical concepts. Insert here: Figure 3 Coordination in co-located agile software development projects
Coordination Strategy Developing a general concept of coordination strategy involved first identifying the individual coordination strategy of each agile case, that is the individual coordination mechanisms in use, and then amalgamating and generalizing from these individual strategies to derive a generic concept. The resultant concept has three distinct groups of coordination mechanism; each group forms a component of the strategy concept. These components are named synchronisation, structure, and boundary spanning (see Table 3). The first component, synchronisation, is a relation that exists when things occur at the same time, or are simultaneous (Allen, 1990, p. 1236). In our theory, synchronisation is achieved with synchronisation activities and synchronisation artefacts produced and used (or consumed) during those activities. Synchronisation activities occur at different frequencies: once per project, once per iteration or sprint, daily, and ad hoc (at random). For example, as shown in Figure 2, Land had an iteration zero planning session that occurred once during the first sprint (named “iteration zero” by the project team members). This involved the whole team meeting at the same time and place to consider technologies, architecture, major user stories and priorities. This synchronisation activity occurred once during the project. Further synchronisation activities occurred at each sprint in Land (and similarly in the other agile projects). For example, an iteration planning session was held once per iteration. Synchronisation activities also occurred daily, for example the daily stand up meeting was held in Storm and Silver, whereas in Land the project team members ensured they all met at some stage each day. The software release in Land occurred whenever it best suited the project stakeholders and involved the whole project team working together to prepare the release. This is categorised as an ad hoc synchronisation activity. Synchronisation artefacts are straightforward. For example, as shown in Figure 2, a product backlog was created and updated during Land’s iteration planning sessions. Other projects involved different artefacts, for example Silver and Storm used wallboards, a product backlog, story cards, task notes, and a variety of other artefacts in their synchronisation activities. The second component, structure, is defined as the arrangement of and relations between the parts of something complex. The structure component is formed from three distinct categories of coordination mechanism: proximity, availability, and substitutability (Table 3 shows examples). The third component of a coordination strategy is boundary spanning, which occurs when someone within the project must interact with other organisations, or other business units outside of the project to achieve project goals. 12
The three categories of boundary spanning are boundary spanning activities, the production of boundary spanning artefacts, and a coordinator role. Similar to synchronisation activities, boundary spanning activities occurred once per project, per iteration (for example, a regular product demonstration to the customer), and ad hoc. Table 3 Definitions of coordination strategy components Component Synchronisation activity
Synchronisation
Synchronisation artefact
Proximity
Structure
Availability
Substitutability
Definition An activity involving all project team members that brings them together at the same time and place for some prearranged purpose. Activities occur once per project, per iteration, daily, or ad hoc Any physical thing generated during synchronisation activities that contains information used by all project team members in accomplishing their work. The nature of the artefact may be visible to the whole team at a glance or largely invisible but available. An artefact can be physical or virtual, temporary or permanent The physical closeness of individual project team members. Adjacent desks provide the highest level of proximity
Project team members are continually present and able to respond to requests for assistance or information Project team members are able to perform the work of another to maintain time schedules
Boundary Spanning
Boundary spanning activity
Activities (team or individual) performed to elicit assistance or information from some unit or organisation external to the project. Activities occur once per project, per iteration, or ad hoc
Boundary spanning artefact
An artefact produced to enable coordination beyond the project team and project boundaries. The nature of the artefact may be visible to the whole team at a glance or largely invisible but available. An artefact can be physical or virtual, temporary or permanent A role taken by a project team member specifically to support interaction with people who are not part of the project team but who provide resources or information to
Coordinator role
13
Evidence “I think the weekly meetings. We had a weekly kind of catch up where everybody attended and I think that was really important to just make sure everyone was on the same page and no one was drifting too much.” [Land, Software Developer] Storm and Silver both used a large prominently displayed wallboard posted on a wall where all project team members could see it. This wallboard followed a typical Scrum method layout and displayed stories related to the sprint, tasks, progress columns, and indications of who was working on which task or story. “We definitely had a daily team meeting on the IT side of it. The business members were not necessarily always involved in that, which is again largely around the lack of colocation…”.[Land, Project Manager] “But you know the developers are right there and we just turn around and involve one of them in the discussions. “ [Storm, Tester] “And basically, everyone is considered equal; they can work on anything.” [Silver, Developer]. “We are not going to have specialist areas where one person can only do a certain type of code. And that went for coding, and testing, and making user stories.” [Silver, Scrum coach] “…the main people we annoy with that are the operations group... The people who look after the servers; and we suddenly go “oh by the way in two weeks we want to release this new thing to you” and they go “well I’m not sure I can be ready in two weeks” and you go [rolls his eyes].” [Storm, Project Manager] “…so when a [end user] does come down me it’s like “I was trying out this screen Sam and it doesn’t seem to work” [Storm, Tester] The artefact in this quote is the working software acting as a coordination mechanism between the end user and the tester
"They [the engineers] always pop down and talk to me if they are experiencing … an issue, and I generally end up being a bit of an entry point for them into the rest of the team because I guess I talk to them a lot
Component
Definition the project
Evidence more than … everyone else does. I arrange meetings." [Tester, Storm]
Project Rock was analysed in the same way as the agile projects. Project Rock used practices and activities typical of a waterfall process (Royce, 1987), which is a process with distinct phases of analysis, design, coding, and testing. Thummadi, Shiv, and Lyytinen (2011) compare waterfall and agile approaches in a useful empirical study for the interested reader. In Rock, the project team maintained strict role differentiation and included in the team a project manager, mainframe and front-end developers, a business analyst, and tester developers. In addition, the team size varied during the project fluctuating from one to 15 team members with a stable core of seven during the interview period. The project requirements were collected by the systems analyst and recorded as use cases prior to the project starting, and testing was carried out after the bulk of the code was developed. Rock was found to use some coordination mechanisms for synchronisation, structure, and boundary spanning but was only superficially similar to the agile software development projects. Rock differed in three distinct ways from the strategy of the agile projects. Firstly, because there were no iterations in Rock there were considerably fewer synchronisation activities when compared with the agile projects. Lacking iterations meant that the whole team met once at project initiation, daily at stand up meetings, and other interactions were unplanned (ad hoc). This frequency of synchronising activities is significantly lower than the agile projects where one to three formal meetings were held at each iteration (e.g. iteration planning, product demonstration, retrospective). Secondly, Rock had an additional coordination strategy component that we named an impersonal artefact (i.e. a policy, procedure, or plan). These impersonal artefacts included a use case specification, system design specification, and a defect document. The third difference between this project and the agile projects was that substitutability, one of the three components of structure, was not apparent in Rock. Project team members could not readily substitute for one another because each team member was assigned a specialised role and substituting for another project team member (i.e. taking on another person’s task) was not considered appropriate. New members would be added to the project if work tasks could not be handled by the assigned team member. Although the coordination strategy defined for the three agile projects overlaps somewhat with the Rock’s strategy, overall the coordination strategy concept derived from the agile software development projects is not a close fit with the coordination strategy found in this non-agile project. This indicates that the boundary of our theory is the co-located agile software development project rather than all software development projects with a similar profile.
Coordination Effectiveness The literature on organising knowledge, people, and things divides coordination into explicit and implicit forms. Explicit coordination is broadly defined as that which occurs when two or more team members use overt mechanisms such as schedules, plans, and procedures, and send communication messages to one another using formal or informal, oral or written, transactions to integrate their work (Espinosa et al., 2004; Nonaka, 1994; Rico et al., 2008; W. P. Wang, Kleinman, & Luh, 2001). Implicit coordination occurs when team members anticipate the actions and needs of their colleagues and adjust their behaviour accordingly without preplanning or direct communication (Nonaka, 1994; Rico et al., 2008; W. P. Wang et al., 2001). Evidence for explicit and implicit coordination emerged from the agile project’s data. Research participants identified three explicit components and four implicit components of coordination effectiveness. The three explicit components include right thing, right place, and right time. That is, when dependencies are well managed with coordination mechanisms, then the right things are in the right place, at the right time. Four implicit components were identified: know why, know what is going on and when, know what to do and when, and, know who is doing what. Table 4 defines each component and provides sample evidence for these findings drawn from the case interviews and observations. Following the 14
advice of Eisenhardt and Graebner (2007), that the literature should be used alongside case study evidence when building theory from case studies, we decided to include an additional component into the coordination effectiveness concept. This additional component of implicit coordination effectiveness is based on software development and agile software development literature. Firstly, Faraj and Sproull’s (2000) research on expertise coordination in software teams found that “knowing who knows what” is an important aspect of coordination. In the agile domain, Wang and Conboy (2009) found that stand up meetings, as used in Storm and Silver, support “knowing who knows what” in a study of XP projects. In addition, Yu and Petter (2014) propose that a variety of agile practices including stand up meetings, contribute to the development of shared mental models. Shared mental models involve knowing who has what task and teamwork knowledge within a team. Ryan and O’Connor (2012) found empirical support for the agile approach in a field test of the influence of transactive memory systems, and the quality and quantity of social interactions on team tacit knowledge. Transactive memory systems involve a group “having a shared awareness of who knows what” (Ryan & O’Connor, 2012, p. 3). They found that transactive memory is a predictor of team tacit knowledge accounting for 9% of the variance. These arguments and empirical findings led us to include “Know who knows what,” in the characterisation of implicit coordination effectiveness. Figure 4 illustrates the concept of coordination effectiveness. Table 4 Sample evidence for explicit and implicit coordination Right thing Right place Right time
Know why - team members have a shared understanding of the project goal and the project priorities
Know what is going on - everyone on the team knows what is going on and when Know what to do everyone on the team knows what they need to do and when
Know who - everyone on the team knows who is
Evidence of explicit coordination “As long as these people were accessible to Mark (right thing), the communication would be flowing, but if these people were not accessible (right place), or there was a time lag (right time), then coordination becomes problematic.” [Land, Developer] “You want someone (right thing) to be able to react at the time (right time) something happens.” [Storm, Project Manager] Evidence of implicit coordination “No one is able to say ‘this one is more important than that one, so stop working on that one’. There are different groups of people all saying ‘this is the top priority’. And no one able to say, ‘Ok, you have got three things of equal priority; in fact they are in this order of 1, 2, and 3. No one able to make that decision, or get agreement on those relative priorities, and so you are left in a position of three equally important high priority things…So that was the obstacle to the coordinating thing.” [Land, Project manager] “To me, coordination is basically running in the same direction, meaning there is a shared goal and people know what they are supposed to do.” [Silver, agile coach] “Because I think the result of that was that decisions took longer than they should have. So when they were talking about, ‘Ok well what is the real, you know, what is this part of the system going to look like’, well it depends on what those guys of doing, and what these guys are doing.” [Land, Developer] “So those things [sprints, stand-ups, retrospectives, planning sessions] were the bread and butter that meant we [all] knew the things that we were doing.” [Silver, Developer] “My team, I can tell if they are well co-ordinated by the fact that they are not confused about what they have to do each day I guess, if they know what they are doing and what they have to do next; then they are well co-ordinated.” [Storm, Project manager] “I have definitely worked in smaller companies, where no one has actually gone to the trouble of spelling out the process, it has just been assumed…you know, ‘how are we going to capture requirements’, ‘what are we considering “done’’.” You know a lot of that stuff, in a lot of organisations, a process is not really clearly defined. No one has gone to the trouble of saying, all right, well, when you have done this, then we can say that this is done, and it will go to the next stage.” [Land, Developer] “I guess from a developer point of view, just being in the situation where you have a good understanding of everything that you need to do. Everything that is happening;
15
doing what and how their work fits with other peoples work
everything that is happening around it.” [Storm, Developer]
Insert here: Figure 4 The coordination effectiveness concept
Coordination effectiveness was also assessed in project Rock. Perceptions of coordination effectiveness in this project were the same as those emerging from the agile projects. Where Rock differed from the agile cases was in participant perceptions of how coordination effectiveness is achieved, that is, what coordination mechanisms are most appropriate for achieving effective project coordination. Perceptions in Rock were influenced by the distinct roles taken within the team. Participants expected their roles would determine who does what, who knows what, and that someone in a particular role, the business analyst in this case, would ensure that work was progressing. Note that in the following discussion, the components of implicit coordination are italicised so they are easy for the reader to identify. In Rock, explicit coordination effectiveness was perceived as a smooth flow of work from one group such as developers, to another group such as testers. Implicit coordination effectiveness also emerged. For example, participants identified a shared goal, (knowing why), as contributing to coordination effectiveness, and they explained that when the team size grew quickly from seven to 15 the shared goal began to break down and the team members’ did not always understand “what they’re actually doing, and why.” [Rock, Analyst]. Evidence for knowing what is going on and when, was found. Participants reported that they used the Kanban style of wallboard to display work items, which they used to understand which work tasks were waiting to be addressed, what tasks were being worked on, and what tasks were recently completed. Note that the Kanban wallboard differs significantly from a Scrum-style wallboard because the Kanban wallboard shows a continuous stream of work rather than work for a single sprint. This team organised their board by role. Each role, such as analyst, developer, and tester, had a row on the board displaying the tasks and task progress related to that role. Knowing what to do and when was identified as contributing to project coordination effectiveness in Rock For example, one project member reported that when a team members did not know what task to start working on next, or failed to address a task “sitting on something because they don’t know what to do” [Rock, Tester] these situations held up progress. Strict role divisions influenced perceptions of who is doing what. A team member would assume they knew what another person on the project was doing because they understood that person’s role and what that role typically involved (i.e. mainframe developer, tester, middleware developer). A project member reflected, “Their individual role in relation to the other roles, because if that’s defined at the start then the coordination will just flow.” [Rock, Analyst] Evidence supporting, know who knows what, was also found in Rock, whereas no direct evidence for this was found in the three agile projects. The strict role divisions in Rock could explain why evidence for know who knows what appeared in the non-agile project and not the agile projects. In Rock, each person had different expertise, therefore knowing who knows what, was important. In the agile teams without such strict role divisions, knowing who knows what might be less of an issue because role divisions are less strict, and substitutability of roles was valued and encouraged. Evidence from the non-agile project and the three agile projects shows a similar pattern of implicit and explicit components. Across all projects, although their coordination strategies were different, their perceptions of coordination effectiveness were very similar. This indicates that the concept of 16
coordination effectiveness in its current form applies to both agile and non-agile projects with a similar profile.
Associations, States, Boundaries, and Propositions The elements of a theory include not only theoretical concepts, but also associations between concepts, states of the theoretical system, and boundaries. One principal association emerged for this theory of coordination: an agile coordination strategy comprising synchronisation, structure, and boundary spanning components is associated with a level of coordination effectiveness engaging both implicit and explicit components. The coordination strategy concept was found to have two distinct states determined by the relationship of the customer with the project team. When the customer forms part of the project team, boundary-spanning activities are considerably reduced. For example, in Land, the customer representatives were treated as part of the project team and participated in all synchronisation activities (e.g. regular meetings) and boundary-spanning activity was not identified in the project. In contrast, in Storm and Silver, the customers were external to the team and multiple formal and informal boundary spanning activities, along with a coordinator role in Storm, were needed to maintain effective coordination. These states are described as follows. 1. When the customer is part of the project team, this requires a coordination strategy including coordination mechanisms for synchronisation and structure to achieve coordination effectiveness. 2. When the customer is external to the project team this requires a coordination strategy including coordination mechanisms for synchronisation, structure, and boundary spanning to achieve coordination effectiveness. A second state of the theory concerns the relationship between strategy and effectiveness. We found the use of iterations to organise the project (i.e. activities occurring once per sprint) reduced the need for formal documentation. Stated more formally, a coordination strategy using iteration synchronisation (e.g. regular, scheduled meetings) does not require impersonal artefacts (e.g., formal documentation) to achieve coordination effectiveness. Project Rock provided evidence to support this finding because their coordination strategy without iteration synchronisation did require impersonal artefacts to achieve coordination effectiveness. The most salient boundary of this theoretical system is the co-located agile software development project. Based on the profiles of the cases informing the theory, boundary conditions are defined as follows. 1. A software development project using practices from Scrum, or Scrum and Extreme Programming with iterations (sprints) of one or two weeks. 2. A distinct and identifiable project team of 2 to 10 people who work concurrently and full-time on the project, and who are located in close proximity within the same room in direct line of sight of one another. 3. A project with a clear business purpose that is either providing a software product for another business unit within the organisation, or for an external organisation. 4. A project with a distinguishable customer or proxy customer. This can be a single person, a group, or groups of people. Coordination effectiveness was initially defined in the conceptual framework guiding this study as the outcome of a particular coordination strategy. Evidence for a relationship between the two concepts was derived from the case evidence and stated in the following four propositions. Proposition 1 is presented in two forms that occur depending on the relationship of the customer to the project team. Proposition 1 a. A coordination strategy that includes synchronisation and structure coordination mechanisms improves project coordination effectiveness when the customer is included in the project 17
team. Synchronisation activities and associated artefacts are required at all frequencies: once per project, per iteration, daily, and ad hoc. Proposition 1 b. A coordination strategy that includes synchronisation, structure, and boundary spanning coordination mechanisms improves project coordination effectiveness when the customer is an external party to the project. Synchronisation activities and associated artefacts are required at all frequencies – project, iteration, daily, and ad hoc. Boundary spanning activities and associated artefacts are required at all frequencies: once per project, per iteration, and ad hoc. Many coordination mechanisms contribute to both implicit and explicit coordination. Some coordination mechanisms tend to promote only implicit coordination, whereas others promote only explicit coordination. Propositions 2, 3, and 4 reflect these tendencies. In the following, salient phrases within quotes are shown in bold font. Synchronisation activities and their associated artefacts increase implicit coordination. For example: “…everything that we know about what we do, what we are building is through those meetings. The idea has always been that if you are doing something …, you have to decide if it is important enough, but if it is important enough that other people need to know it, and they might disagree with you, then you should grab everyone around the table and have that kind of talk. [Storm, Developer] This excerpt is evidence for a synchronisation activity (i.e. informal face-to-face negotiation) at ad-hoc frequency (these meetings were held as and when needed) influencing implicit coordination effectiveness, in particular, know why or shared goal (i.e. “everything we know about what we do”). A second, and more complex, example from Storm involved three different coordination mechanisms all influencing implicit coordination effectiveness. This excerpt is called Excerpt A, and is used in developing arguments to support propositions 2, 3, and 4. “We’ve got the [Scrum wallboard], but you wouldn’t, we don’t do locks, so you can get people working in the same code area, but generally…, people are … aware of what other people are doing, sorry, in the same room, people are kind of aware of what people are working on.” [Storm, Tester] So this awareness, where does this awareness come from? [Researcher] “The board and cross-team talk. But then, even if you do edit the same files, you can merge them again. Or if there was significant change, if someone declares,…that ‘I’m [going to] rewrite this whole thing, it needs complete refactoring’ or ‘it is just so ugly the way we were doing it’ they will announce that to the team. They’ll say, ‘no-one bother going into this module ‘cos I’m just going to rip it to bits’. ” [Storm, Tester] Excerpt A provides evidence that a coordination mechanism categorised as an ad hoc synchronisation activity (i.e. “cross-team talk”) contributes to implicit coordination effectiveness, in particular know who is doing what (i.e. “people are aware of what other people are doing”). Furthermore, this excerpt is also evidence that a coordination mechanism categorised as a synchronisation artefact (i.e. “Scrum wallboard”) influences implicit coordination effectiveness, in particular know who is doing what. Proposition 2 is derived from these considerations. Proposition 2. Synchronisation activities at all frequencies: once per project, per iteration, daily, and ad hoc, along with their associated synchronisation artefacts, increase implicit coordination effectiveness. When project team members are in close proximity, especially when they are in the same room with adjacent desks, they become more aware of the work of other team members by observing and overhearing their activities. They may also become familiar with how their own task fits with others’ tasks; in 18
other words, they know why they are performing their task. In addition, they learn what is going on and when, they come to know who is doing what, and they become aware of who knows what. For example, Excerpt A shows that a coordination mechanism categorised as proximity (i.e. “in the same room”) influences implicit coordination effectiveness, in particular know who is doing what (i.e. “what people are working on”). When a project team member is consistently and freely available, other team members can readily consult that person whenever they need to, and at short notice. Availability therefore raises project team members’ awareness about who knows what in the project. For example: “But if there is a sticky problem [that] is right inside our team, if you are blocked, need some help, to tap anyone else on the shoulder and grab them and get them to help unblock you…” [Storm, Project Manager] When project team members can perform each other’s tasks because they have overlapping skill sets this is substitutability. Substitutability raises awareness about who knows what because to perform the work of another, you come to understand what they know and do not know. For example, in Storm with everyone similarly skilled in Java, the developer said: “…we all know, since we are in a team of four or five people, what each person is going to be best tackling. And you just go ‘yes’, I will do that, and no one argues. We just know which ones to grab next.” [Storm, Developer] Proposition 3 is derived from such evidence. Proposition 3. Structural coordination mechanisms including close proximity, high availability, and high substitutability increase implicit coordination effectiveness. The purpose of boundary spanning is to acquire physical (e.g. servers) or informational (information about requirements or the technical domain) resources for the project. Activities such as meetings with vendors and customers, artefacts such as official requests, and someone on the project team taking a coordinator role all contribute to boundary spanning. Such activities ensure that required resources, the right things, are in the right place, at the right time, so that project progress is not hindered in any way. For example: “…they [the engineers who are the end users] literally sit in the room next door, so we jump up from our desk and go over to their desk and talk with them or bring them into our room, get them to sit down and look at it over our shoulder and talk through it with us. So it is … a little bit random who we get, and it has been narrowing down for [Startpoint] project just the same way it narrowed down for the [Carboy] project. Each one tends to narrow down to certain people you find who can tell you the right information.” [Storm, Project] This example shows an ad hoc boundary spanning activity (i.e. jumping up from your desk and going to the next room to consult with an end-user) increasing explicit coordination effectiveness (i.e. accessibility to the right information). Proposition 4 is based on evidence of this nature. Proposition 4. Boundary spanning coordination mechanisms including boundary-spanning activities at all frequencies: once per project, per iteration, and ad hoc, their associated boundary-spanning artefacts, and a coordinator role increases explicit coordination effectiveness.
DISCUSSION This chapter has presented a theory of coordination in agile software development projects. This theory addresses the research questions posed in the introduction section. We found that agile software development projects are coordinated using a strategy that combines three broad types of coordination mechanism for synchronising, structuring, and boundary spanning. Some mechanisms act to synchronise 19
the agile software development project team by bringing them all together at regular intervals and producing and using (or consuming) synchronising artefacts (e.g. story cards, and task notes). Another group of mechanisms structure the project team activities via proximity, availability, and substitutability of roles. Boundary spanning mechanisms form a third set of mechanisms. Boundary spanning mechanisms are not standard agile method practices but additional mechanisms adopted by a project team when their customer is not closely involved in the daily life of the project. In addition, we found evidence in the agile software development projects supporting our initial idea that coordination effectiveness is an outcome of coordination strategy. Coordination effectiveness was found to have explicit and implicit components. Explicit coordination involves the right thing being in the right place at the right time, whereas implicit coordination is formed from the project team having shared goals, knowing what is going on and when, knowing what to do and when, knowing who is doing what, and knowing who knows what. Our theory is a variance theory because it argues that coordination mechanisms acting together to form a coordination strategy (things done to achieve coordination) creates, or leads to, a state of coordination effectiveness (Markus & Robey, 1988). This evidence was formalised in four propositions that explain the links between components of the coordination strategy, and explicit and implicit components of coordination effectiveness. Although our coordination theory is built from evidence drawn from case studies of software development, some elements in the theory are apparent in the extant coordination literature. Synchronisation is recognised as a fundamental element of coordination by Arrow, McGrath, and Berdahl (2000) who define coordination, as “a synchronization and sequencing of member actions in time and place” (p. 2). Furthermore, based on an extensive literature review, Okhuysen et al. (2009) proposed common coordination mechanisms and integrating conditions that occur in all forms of organisation. A number of these coordination elements occur in our theory including bringing groups together (our term is synchronisation), substitution (our term is substitutability), proximity, creating a common perspective (shared goal), and scaffolding. Okhuysen et al. (2009) use the term scaffolding to mean any reminder of which tasks still need to be done, and who needs to do them, in order to complete the work. In our theory, similar elements are “know what is going on and when,” and “know what to do and when.” Our theory also supports the conjecture of Cao and Ramesh (2007) that agile software development projects use more personal and group coordination modes to coordinate effectively. Our theory includes synchronisation activities and boundary spanning activities for coordinating the project. These types of coordination mechanism involve frequent meetings of the agile project team members, and meetings of the project team with the customer both as a group and between individuals. Therefore, aspects of the coordination in our observed agile software development projects supports this conjecture. Boundary spanning activity is well recognised in organisation studies. In that literature, boundary spanning occurs when different organisations or groups within organisations separated by location, hierarchy, or function, interact to share expertise (Levina & Vaast, 2005). We found that boundary spanning was needed when the customer was not consistently available to the project team. The customers in Storm, Silver, and Rock were all in separate business units, or were external clients, and boundary spanning was a necessary coordination mechanism to ensure team members had relevant requirements and could maintain coordination effectiveness (e.g. they “know what to do and when”). Finally, the coordinator role is also found in the literature. This role was identified by Hoda, Noble, and Marshall (2010) in agile projects where the customer was not co-located with the project team. The concept of coordination effectiveness is weakly defined in extant literature. Based on Malone and Crowston’s (1994) coordination theory, Espinosa et al. (2004) proposed that effective coordination occurs when dependencies in a situation are well managed. The problem is how to assess straightforwardly when dependencies are well managed. Our coordination effectiveness concept provides a way to carry out this assessment. Based on grounded data the concept provides two precisely defined explicit and implicit outcomes that can readily be operationalised.
20
A useful finding arising from the analysis of agile software development projects and a non-agile colocated project of similar size and complexity is an understanding that participants in both types of project had a common perception of what coordination effectiveness means in a software development project. Therefore, a single measure of coordination effectiveness might be applicable to all types of software development project. Although our theory incorporates many previously recognised elements of coordination, we have proposed a variance theory implying cause and effect, whereas most coordination theories such as those of Malone and Crowston (1994) and Okhuysen et al. (2009) are descriptive. Therefore, the theory presented in this chapter can be tested in future research using quantitative methods.
CONTRIBUTIONS This research makes theoretical and practical contributions. Our coordination theory is unique to the domains of IT project management, information systems development, and agile software development. The theory has distinct concepts defined in detail based on evidence from agile software development projects and distinct boundaries, associations, states, and testable propositions explaining the relationship between concepts. Contrasting evidence from a non-agile project showed that the coordination strategy concept fits less well outside of the agile context, whereas the concept of coordination effectiveness appears to be common to both agile and non-agile projects. Another contribution is to IS and IT project success literature. Project success has many antecedents, one of which is project coordination (Curtis et al., 1988; Nidumolu, 1995). This study deepens and extends our understanding of the way coordination is achieved, and consequently contributes to our understanding of the achievement of software project success. This theory informs practitioners in two ways. Firstly, practitioners can use the coordination strategy concept as an aid in identifying which agile practices to choose to achieve coordination coverage by ensuring they assemble coordinative practices to achieve synchronisation, structure, and boundary spanning. Secondly, practitioners can use the coordination effectiveness concept as a guide for qualitatively assessing the coordination effectiveness of a project at various time points providing an early warning system when dependencies in their project are not being managed effectively.
FUTURE RESEARCH DIRECTIONS Further work would be useful to confirm the efficacy of the theory presented in this chapter and refine its concepts and proposed relationships. Future research should aim to verify the concept of coordination strategy (i.e. certain agile practices acting as coordination mechanisms), and in particular the relative contribution of synchronisation (especially at different iteration durations), structure, and boundary spanning coordination mechanisms, along with any interaction effects between these coordination components. Further verification of the concept of coordination effectiveness, in particular the contribution of, and interaction between, implicit and explicit coordination would be valuable, especially at different phases of a project and under various project conditions. The relationship between coordination strategy and coordination effectiveness, in particular the effect of different coordination strategies on implicit and explicit coordination effectiveness is another area for investigation. This would mean investigating and comparing agile software development projects using different agile practices with a coordinative function, and the impact of these different strategies on coordination effectiveness. In this way, the most effective mechanisms could be selected for coordinating projects. Further use for this concept might be to compare the coordination effectiveness of distributed agile and co-located agile projects, agile and non-agile projects, and between different system development methodologies that provide different coordination strategies. In particular, newer approaches to development such as lean development with Kanban processes.
21
Another benefit of having an operationalised and empirically tested coordination theory would be to use it as a basis to investigate the contribution of coordination effectiveness to project success or effectiveness. Project success is not yet formally defined and research such as this would make an important and longlasting contribution to IT project management literature and practice.
CONCLUSION This research contributes a theory of coordination to the information systems field that explains coordination in co-located agile software development projects. After an extensive review of coordination literature, it was apparent that although coordination is considered an important factor in organisations, IT projects, teams, and agile software development, there is no targeted theory explaining coordination in agile software development projects. Our purpose was to build a unique theory based on empirical evidence from cases of software development. We found that agile software development embodies effective coordination by assembling coordination mechanisms that support project team synchronisation, structures a project by supporting proximity, availability, and role substitutability, and incorporates boundary-spanning mechanisms. Such a coordination strategy leads to coordination effectiveness comprising implicit and explicit elements. This theory has utility for theorists as the concepts are grounded in literature and empirical evidence and can potentially be applied in other contexts. Practitioners can used this theory to select agile practices to better coordinate projects, and potentially to measure agile project effectiveness. We conclude by observing that this theory has future value because it provides a basis for understanding and measuring the coordination effectiveness of existing and new forms of agile software development as this increasingly popular development approach evolves.
REFERENCES Abrahamsson, P., Warsta, J., Siponen, M. K., & Ronkainen, J. (2003). New directions on agile methods: A comparative analysis. Proceedings of the 25th International Conference on Software Engineering, ICSE'03 (pp. 244-254). Washington, DC, USA: IEEE Computer Society. Agerfalk, P. J., Fitzgerald, B., & Slaughter, S. A. (2009). Flexible and distributed information systems development: State of the art and research challenges. Information Systems Research, 20(3), 317328. Aladwani, A. M. (2002). An integrated performance model of information systems projects. Journal of Management Information Systems, 19(1), 185-210. Allen, R. E. (1990). The Concise Oxford Dictionary of Current English (8 ed.). Oxford: Clarendon Press. Ambler, S. W. (2009). Agile adoption rate survey results: February 2008 Retrieved 20 July, 2011, from http://www.ambysoft.com/surveys/agileFebruary2008.html Andres, H. P., & Zmud, R. W. (2001). A contingency approach to software project coordination. Journal of Management Information Systems, 18(3), 41-70. Arrow, H., McGrath, J. E., & Berdahl, J. L. (2000). Small groups as complex systems: Formation, coordination, development, and adaptation. Thousand Oaks, CA: Sage. Avison, D., & Fitzgerald, G. (2006). Methodologies for developing information systems: A historical perspective. In D. Avison, S. Elliot, J. Krogstie & J. Pries-Heje (Eds.), The Past and Future of Information Systems: 1976-2006 and Beyond (pp. 27-38). Boston: Springer. Balijepally, V., Mahapatra, R., Nerur, S., & Price, K. H. (2009). Are two heads better than one for software development? The productivity paradox of pair programming. MIS Quarterly, 33(1), 91118.
22
Barlow, J., Giboney, J., Keith, M., Wilson, D., & Schuetzler, R. (2011). Overview and guidance on agile development in large organizations. Communications of the Association for Information Systems, 29(1), 25-44. Baskerville, R., & Pries-Heje, J. (2004). Short cycle time systems development. Information Systems Journal, 14(3), 237-264. Beck, K. (2000). Extreme Programming Explained: Embrace Change. Boston: Addison-Wesley. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Thomas, D. (2001). Manifesto for agile software development. . Retrieved 1 January 2012, from http://www.agilemanifesto.org Cao, L., Mohan, K., Ramesh, B., & Sarker, S. (2013). Adapting funding processes for agile IT projects: An empirical investigation. European Journal of Information Systems, 22(1), 191-205. Cao, L., & Ramesh, B. (2007, March April). Agile software development: ad hoc practices or sound principles? IT Pro, 41-47. Cao, L., Ramesh, B., & Abdel-Hamid, T. (2010). Modeling dynamics in agile software development. ACM Transactions on Managment Information Systems, 1(1), 1-26. Chen, H.-G., Jiang, J. J., Klein, G., & Chen, J. V. (2009). Reducing software requirement perception gaps through coordination mechanisms. The Journal of Systems and Software, 82(4), 650-655. Conboy, K. (2009). Agility from first principles: reconstructing the concept of agility in information systems development. Information Systems Research, 20(3), 329-354. Conboy, K., & Fitzgerald, B. (2007). The views of experts on the current state of agile method tailoring. In T. McMaster, D. Wastell, E. Ferneley & J. DeGross (Eds.), IFIP International Federation for Information Processing (Vol. 235, pp. 217-234). Boston: Springer. Conboy, K., Fitzgerald, B., & Golden, W. (2005). Agility in information systems development: A threetiered framework. In R. Baskerville, L. Mathiassen, J. Pries-Heje & J. DeGross (Eds.), Business Agility and Information Technology Diffusion. IFIP TC8 WG 8.6 International Working Conference May 8-11, 2005, Atlanta, Georgia, U.S.A. (pp. 36-49). New York: Springer. Crowston, K. (1991). Towards a coordination cookbook: recipes for multi-agent action. (PhD), Massachusetts Institute of Technology, Cambridge, Mass. Retrieved from http://hdl.handle.net/1721.1/49303 Crowston, K., & Osborn, C. S. (2003). A coordination theory approach to process description and redesign. In T. W. Malone, K. Crowston & G. A. Herman (Eds.), Organizing Business Knowledge: The MIT Process Handbook (pp. 335-370). Cambridge, Massachusetts: The MIT Press. Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287. Darke, P., Shanks, G., & Broadbent, M. (1998). Successfully completing case study research: Combining rigour, relevance and pragmatism. Information Systems Journal, 8(4), 273-289. Dingsoyr, T., Dyba, T., & Abrahamsson, P. (2008). A preliminary roadmap for empirical research on agile software development. Proceedings of the Agile 2008 Conference (pp. 83-94): IEEE Xplore digital library. Dingsoyr, T., Dyba, T., & Moe, N. (Eds.). (2010). Agile software development: Current research and future directions. Heidelberg: Springer-Verlag.
23
Dingsoyr, T., Nerur, S., Balijepally, V., & Moe, N. (2012). A decade of agile methodologies: Towards explaining agile software development. The Journal of Systems and Software, 85(6). Drury-Grogan, M., & O'Dwyer, O. (2013). An investigation of the decision-making process in agile teams. International Journal of Information Technology and Decision Making, 12(6), 1097-1120. Dube, L., & Pare, G. (2003). Rigor in information systems positivist case research: Current practice, trends, and recommendations. MIS Quarterly, 27(4), 597-635. Dyba, T., & Dingsoyr, T. (2008). Empirical studies of agile software development: A systematic review. Information and Software Technology, 50(9-10), 833-859. Eisenhardt, K. M. (1989). Building theories from case study research. The Academy of Management Review, 14(4), 532-550. Eisenhardt, K. M., & Graebner, M. E. (2007). Theory building from cases: Opportunities and challenges. Academy of Management Journal, 50(1), 25-32. Espinosa, A. J., Lerch, F. J., & Kraut, R. E. (2004). Explicit versus implicit coordination mechanisms and task dependencies: One size does not fit all. In E. Salas & S. M. Fiore (Eds.), Team Cognition: Understanding the Factors that Drive Process and Performance (pp. 107-129). Washington DC: American Psychological Association. Espinosa, A. J., Lerch, J., & Kraut, R. (2002). Explicit vs. implicit coordination mechanisms and task dependencies: One size does not fit all. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/kraut/www/RKraut.site.files/articles/Espinosa03ExplicitVsImplicitCoordination.pdf Espinosa, A. J., Slaughter, S. A., Kraut, R. E., & Herbsleb, J. D. (2007). Team knowledge and coordination in geographically distributed software development. Journal of Management Information Systems, 24(1), 135-169. Faraj, S., & Sproull, L. (2000). Coordinating expertise in software development teams. Management Science, 46(12), 1554-1568. Fiore, S. M., & Salas, E. (2004). Why we need team cognition. In E. Salas & S. M. Fiore (Eds.), Team Cognition (pp. 235-248). Washington, DC: American Psychological Association. Galbraith, J. R. (1977). Organization design. Reading, MA: Addison-Wesley. Goh, J. C., Pan, S. L., & Zuo, M. (2013). Developing the agile IS development practices in large-scale IT projects: The trust-mediated organizational controls and IT project team capabilities perspectives. Journal of the Association for Information Systems, 14(12), 722-756. Goh, K. T., Goodman, P. S., & Weingart, L. R. (2013). Team innovation processes: An examination of activity cycles in creative project teams. Small Group Research, 44(2), 159-194. Hilkka, M.-R., Tuure, T., & Matti, R. (2005). Is extreme programming just old wine in new bottles: A comparison of two cases. Journal of Database Management, 16(4), 41-61. Hoda, R., Noble, J., & Marshall, S. (2010). Organizing self-organizing teams. Proceedings of the IEEE/ACM International Conference on Software Engineering, ICSE 2010, May 2-9, 2010 (pp. 285-294). New York, NY: ACM. Hoegl, M., & Gemuenden, H. G. (2001). Teamwork quality and the success of innovative products. Organization Science, 12(4), 435-449. Iivari, J., Hirschheim, R., & Klein, H. K. (2004). Towards a distinct body of knowledge for information systems experts: Coding ISD process knowledge in two IS journals. Information Systems Journal, 14(4), 313-342. 24
Kang, H.-R., Yang, H.-D., & Rowley, C. (2006). Factors in team effectiveness: Cognitive and demographic similarities of software development team members. Human Relations, 59(12), 1681-1710. Kautz, K., Madsen, S., & Norbjerg, J. (2007). Persistent problems and practices in information systems development. Information Systems Journal, 17(3), 217-239. doi: 10.1111/j.13652575.2007.00222.x Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69-81. Lee, G., & Xia, W. (2010). Toward agile: an integrated analysis of quantitative and qualitative field data on software development agility. MIS Quarterly, 34(1), 87-114. Levina, N., & Vaast, E. (2005). The emergence of boundary spanning competence in practice: Implications for implementation and use of information systems. MIS Quarterly, 29(5), 335-363. MacCormack, A., Verganti, R., & Iansiti, M. (2001). Developing products on "Internet Time": The anatomy of a flexible development process. Management Science, 47(1), 133-150. MacKenzie, A., & Monk, S. (2004). From cards to code: How extreme programming re-embodies programming as collective practice. Computer Supported Cooperative Work, 13(1), 91-117. Malone, T. W. (1987). Modeling coordination in organizations and markets. Management Science, 33(10), 1317-1332. Malone, T. W. (1988). What is coordination theory? Sloane School of Management Working Paper # 2051-88. http://hdl.handle.net/1721.1/2208 Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87-119. March, J. G., & Simon, H. A. (1958). Organization. New York: Wiley. Marchesi, M., Succi, G., Wells, D., & Williams, L. (Eds.). (2003). Extreme programming perspectives. Boston: Addison-Wesley. Markus, M. L., & Robey, D. (1988). Information technology and organizational change: causal structure in theory and research. Management Science, 34(5), 583-598. Maruping, L. M., Venkatesh, V., & Agarwal, R. (2009). A control theory perspective on agile methodology use and changing user requirements. Information Systems Research, 20(3), 277-399. McChesney, I. R., & Gallagher, S. (2004). Communication and coordination practices in software engineering projects. Information and Software Technology, 46(7), 473-489. Miles, M. B., & Huberman, A. M. (1994). Qualitative Data Analysis (2 ed.). Thousand Oaks: Sage. Mintzberg, H. (1980). Structure in 5's: A synthesis of the research on organization design. Management Science, 26(3), 322-341. Misra, S. C., Kumar, V., & Kumar, U. (2009). Identifying some important success factors in adopting agile software development practices. Journal of Systems and Software, 82(11), 1869-1890. Mohammed, S., Ferzandi, L., & Hamilton, K. (2010). Metaphor no more: A 15-year review of the team mental model construct. Journal of Management, 36(4), 876-910. Nidumolu, S. (1995). The effect of coordination and uncertainty on software project performance: Residual performance risk as an intervening variable. Information Systems Research, 6(3), 191219.
25
Nidumolu, S., & Subramani, M., R. (2004). The matrix of control: Combining process and structure approaches to managing software development. Journal of Management Information Systems, 20(3), 159-196. Nonaka, I. (1994). A dynamic theory of organizational knowledge creation. Organization Science, 5(1), 14-37. Nurmi, A. (2009). Coordination of multi-organizational information systems development projects evidence from two cases. Journal of Information Technology Theory and Application (JITTA), 10(3), 1-10. Okhuysen, G. A., & Bechky, B. A. (2009). Coordination in organizations: an integrative perspective. The Academy of Management Annals, 3(1), 463-502. Olle, T. W., Sol, H. C., & Tully, C. (Eds.). (1983). Information Systems Design Methodologies: A Feature Analysis. Proceedings of the IFIP WB 8.1 Working Conference on Feature Analysis of Information Systems Design Methodologies. Amsterdam: North-Holland. Pare, G. (2004). Investigating information systems with positivist case study research. Communications of the Association for Information Systems, 13(1), 233-264. Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P., & Still, J. (2008). The impact of agile practices on communication in software development. Journal of Empirical Software Engineering, 13(3), 303-337. doi: 10.1007/s10664-008-9065-9 Pries-Heje, L., & Pries-Heje, J. (2011). Why Scrum works. Proceedings of the Agile Conference 2011, Salt Lake City, UT (pp. 20-28): IEEE Xplore digital library. doi: 10.1109/AGILE.2011.34 Ramesh, B., Cao, L., Mohan, K., & Xu, P. (2006). Can distributed software development be agile? Communications of the ACM, 49(10). Rico, R., Sanchez-Manzanares, M., Gil, F., & Gibson, C. (2008). Team implicit coordination processes: A team knowledge-based approach. Academy of Management Review, 33(1), 163-184. Royce, W. W. (1987). Managing the development of large software systems Proceedings of the 9th International Conference on Software Engineering (Reprinted from Proceedings, IEEE WESCON, August 1970 p. 1-9. Originally published by TRW) (pp. 328-338). Los Alamitos, CA: IEEE Computer Society Press. Ryan, S., & O’Connor, R. V. (2012). Social interaction, team tacit knowledge and transactive memory: Empirical support for the agile approach Proceedings of Researching Agile development of Information SystEms (RAISE) Conference, 11 October, 2012. . London, UK. Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum. Upper Saddle River, New Jersey: Prentice Hall. Sharp, H., & Robinson, H. (2004). An ethnographic study of XP practice. Empirical Software Engineering, 9(4), 353-375. Sharp, H., & Robinson, H. (2008). Collaboration and co-ordination in mature eXtreme programming teams. International Journal of Human-Computer Studies, 66(7), 506-518. Sharp, H., Robinson, H., & Petre, M. (2009). The role of physical artefacts in agile software development: two complementary perspectives. Interacting with computers, 21(1-2), 108-116. Spradley, J. P. (1979). The Ethnographic Interview. New York: Holt, Rinehart and Winston. Stankovic, D., Nikolic, V., Djordjevic, M., & Cao, D.-B. (2013). A survey study of critical success factors in agile software projects in former Yugoslavia IT companies. Journal of Systems and Software, 86(6), 1663-1678. 26
Stavru, S. (2014). A critical examination of recent industrial surveys on agile method usage. The Journal of Systems and Software, In press. doi: http://dx.doi.org/10.1016/j.jss.2014.03.041 Strode, D. E. (2006). Agile methods: a comparative analysis. In S. Mann & N. Bridgeman (Eds.), Proceedings of the 19th Annual Conference of the National Advisory Committee on Computing Qualifications, NACCQ 2006 (pp. 257-264). Wellington: NACCQ. Strode, D. E. (2012). A theory of coordination in agile software development projects. (PhD), Victoria University of Wellington, New Zealand. Retrieved from http://hdl.handle.net/10063/2505 Strode, D. E. (2013). Extending the dependency taxonomy of agile software development. In P. Antunes, M. A. Gerosa, A. Sylvester, J. Vassileva & G. de Vreede (Eds.), Lecture Notes in Computer Science: Vol. 8224. Proceedings of the 19th International Conference on Collaboration and Technology, CRWIG 2013, Wellington, New Zealand, 30 October to 1 November (pp. 274-289). Berlin Heidelberg, Germany: Springer-Verlag. Strode, D. E., & Huff, S. L. (2012). A taxonomy of dependencies in agile software development Proceedings of the 23rd Australasian Conference on Information Systems, ACIS 2012, 3-5 December, Geelong, Australia (pp. 1-10). Strode, D. E., Huff, S. L., Hope, B., & Link, S. (2012). Coordination in co-located agile software development projects. The Journal of Systems and Software, 85(6), 1222-1238. doi: 10.1016/j.jss.2012.02.017 Strode, D. E., Huff, S. L., & Tretiakov, A. (2009). The impact of organizational culture on agile method use. Paper presented at the The Forty-Second Annual Hawai'i International Conference on System Sciences, HICSS-42, Hawaii, USA. Thomas, D. R. (2006). A general inductive approach for analyzing qualitative evaluation data. American Journal of Evaluation, 27(2), 237-246. doi: 10.1177/1098214005283748 Thompson, J. D. (1967). Organization in Action. Chicago: McGraw-Hill. Thummadi, B. V., Shiv, O., & Lyytinen, K. (2011, 7-13 August). Enacted routines in agile and waterfall processes. Paper presented at the Agile Conference. Van de Ven, A. H., Delbecq, A. L., & Koenig, R. (1976). Determinants of coordination modes within organizations. American Sociological Review, 41(2), 322-338. VersionOne. (2013). Annual state of agile development survey results. Retrieved 24 September, 2013, from http://www.versionone.com/state-of-agile-survey-results/ von Krogh, G., Rossi-Lamastra, C., & Haefliger, S. (2012). Phenomenon-based research in management in organisation science: When is it rigorous and does it matter? Long Range Planning, 45(4), 277298. Wang, W., & Conboy, K. (2009). Understanding agility in software development from a complex adaptive systems perspective. Paper 429. Proceedings of the 17th European Conference on Information Systems (pp. 1-13). Verona, Italy. Wang, W. P., Kleinman, D. L., & Luh, P. B. (2001). Modeling team coordination and decisions in a distributed dynamic environment. In G. M. Olson, T. W. Malone & J. B. Smith (Eds.), Coordination Theory and Collaboration Technology (pp. 673-710). Mahwah, New Jersey: Lawrence Erlbaum Associates. Weber, R. (2012). Evaluating and developing theories in the information systems discipline. Journal of the Association for Information Systems, 13(1), 1-30.
27
Weick, K. E., & Roberts, K. H. (1993). Collective mind in organizations: Heedful interrelating on flight decks. Administrative Science Quarterly, 38(3), 357-381. West, D., & Grant, T. (2010). Agile development: Mainstream adoption has changed agility. 1-20. http://www.osp.ru/netcat_files/18/10/h_d8eddd303b6cf0c38c23601c4363bee4 Yin, R. K. (2003). Case Study Research (3 ed.). Thousand Oaks: Sage. Yu, X., & Petter, S. (2014). Understanding agile software development practices using shared mental models theory. Information and Software Technology, 56(8), 911-921. Yuan, M., Vogel, D., Zhang, X., Chen, Z., & Chu, X. (2007). Antecedents of coordination effectiveness of software developer dyads from interacting teams: an empirical investigation. Paper presented at the 11th Pacific-Asia Conference on Information Systems.
28
Figure 1
29
Figure 2
30
Figure 3
31
Figure 4
32
