agile model research paper

An official website of the United States government

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings
• Advanced Search
• Journal List
• v.5(3); 2019 Mar

Adapting the scrum framework for agile project management in science: case study of a distributed research initiative

This article explores the adoption of agile methods for the management of projects in collaborative research initiatives. The use of the scrum framework, a specific set of agile principles and practices for self-organizing cross-functional teams in software development projects, is currently being expanded to other types of organizations and knowledge management processes. The study addresses the extent to which key principles and tools usually used in scrum, due to their potentially positive influence on team dynamics and efficiency, can contribute to the collaborative management and coordination of tasks in research processes. The responses from interviews with 17 researchers, as well as participant observation and analysis of online activity, are examined and presented as a case study on the adoption of scrum practices in a distributed research centre dedicated to the evaluation of public policies. Results indicate that integrating agile methods and principles for interdisciplinary collaboration requires a high degree of flexibility and a “learn by doing” approach.

1. Introduction

1.1. team-based collaboration in research.

Team-based collaboration is a critical factor in research organizations and scientific fields, as knowledge is increasingly being generated by research teams ( Wuchty et al., 2007 ; Wagner et al., 2017 ). Literature on research practices indicates that teamwork and collaboration dominate knowledge production in academic organizations and is prevalent in large-scale international research networks ( Cooke and Hilton, 2015 ). Academics and investigatory teams working on science, engineering and social science disciplines have shifted towards collective research ( Wuchty et al., 2007 ). The benefits of research collaboration range from an increase in citations as a result of the co-authorship of papers to better use of existing resources ( Ynalvez and Shrum, 2011 ). Other benefits include the capacity to generate wider social impact through large-scale research projects ( Bammer, 2008 ), and more opportunities for knowledge transfer and learning ( Lassi and Sonnenwald, 2010 ) or for managing complexity ( Helbing et al., 2015 ).

The study of collaborative research networks from diverse perspectives has gained momentum in recent years ( Wang and Hicks, 2015 ) because funding agencies, which prioritise better use of existing resources, prestige and international reputation, are encouraging large-scale collaborative research programs ( Smykla and Zippel, 2010 ). In this respect, research collaboration may be viewed as a self-assembling entity, characterized by fuzzy boundaries and the tendency to function as networks ( Spinuzzi, 2015 ; Wang and Hicks, 2015 ) that involve not only different research institutions, but also expand to include collaboration with industry, governments or civil society ( Bridgeford and Amant, 2017 ). Collaboration may occur across sectors and types of organisations ( Bozeman and Corley, 2004 ), such as government-based research programs, that usually emphasize multidisciplinary and applied research ( Gray et al., 2001 ), or in industry, where the confines of conducting research are usually bypassed for the sake of academic publishing and the search for utility for the non-academic partners ( Perkmann and Walsh, 2009 ).

Several authors contend that this shift to research collaboration is occurring amidst a trend towards disruptive adoption of information and communication technologies (ICT) in knowledge-intensive organizations ( Jirotka et al., 2013 ; Borgman, 2010 ; Powell and Snellman, 2004 ). At present, collective research is undertaken in more distributed, reflexive and less hierarchical work arrangements ( Zuboff, 1988 ), thereby expanding the possibilities for complex multidisciplinary and interdisciplinary collaborations on varying scales ( König et al., 2013 ). In parallel to the prevailing opinion that research collaboration correlates with high productivity ( Daradoumis et al., 2012 ) and quality results ( Rigby and Edler, 2005 ; Liao, 2011 ), some scholars describe it as a difficult and ever-changing process, particularly when involving collaboration between geographically dispersed remote teams ( Eccles et al., 2009 ). Key challenges in team-based collaborative research management relate to issues of commitment, transparency or communication and monitoring ( Keraminiyage et al., 2009 ). Collaboration across disciplines also requires progressive adaptation of a shared language and different types of tools ( Jeffrey, 2003 ).

Kraut et al. (1987) , describing the process of collaborative research in scientific teams, explain how plans become progressively more detailed and specific, but can often be revised and even abandoned without negatively impacting collaboration. Other challenges in collaborative research management relate to the need for supervision and coordination among peers ( Delfanti, 2016 ), or to coordinating an activity that is continually evolving ( König et al., 2013 ). Large-scale research projects usually imply more dedication to leading and coordinating each process, from research design to the collaborative authorship of papers and reports ( Bozeman and Corley, 2004 ). In this sense, collaborative research projects often require new project management techniques ( Vom Brocke and Lippe, 2015 ). Methodologically, these additional complexities when performing scientific activities represent an evolving interdisciplinary field requiring various types of analysis of how and when collaborative research is implemented ( Sonnenwald, 2007 ; Katz and Martin, 1997 ).

1.2. Agile project management

Agile project management (APM) or “agile methods” represents a team management approach and a productivity framework that supports continuous and incremental progress on work priorities, even in the face of changes. APM has its origins in the agile processes of software development, such as Scrum, XP, DSDM, Cristal, etc., which are programming methodologies based on adaptability to any change as a means to increase the chances of success of a project ( Cohen et al., 2004 ). Most agile methods try to minimize risks during the execution of a project by developing software in iterations, which usually last from one to four weeks. Each iteration is like a miniature project of the final project, and includes all the tasks necessary to implement new functionalities: planning, requirements analysis, design, coding, testing, and documentation. An agile programming project aims to release new software at the end of each iteration, and between each iteration the team reevaluates its priorities.

APM has gained in popularity in recent years, primarily in the software industry ( Scrum Alliance, 2016 ) but is progressively breaking into other domains ( Ciric et al., 2018 ). In the late 1990s software development teams started to apply agile methods for the improvement of programming processes by making them more continuous and incremental on the basis of agile principles such as adaptability, personal and group autonomy, modularity and self-organized collaboration, as defined in the Agile manifesto ( Beck et al., 2001 ). The manifesto was a reaction to the weaknesses and rigidity of popular plan-based software production methodologies, such as the previously highly acclaimed “waterfall” method, which has been criticised mainly for its lack of responsiveness to change ( Cockburn, 2002 ). APM, more so than other management frameworks, emphasizes teamwork by focusing on the social aspects of software development ( Rosenberg and Stephens, 2003 ), channelling co-creation between programmers and other participants in self-organized, cross-functional teams ( Hoda et al., 2013 ), with collective ownership and collective responsibility as key attributes ( Robinson and Sharp, 2005 ). According to Conforto et al. (2014) APM practices include: (1) the use of the “project vision” concept, (2) simple communication tools and processes, (3) iterative planning, (4) developing activities via self-managed and self-directed teams, and (5) frequently applying project plan monitoring and updating activities.

Despite the critique by some authors that the agile manifesto principles are insufficiently grounded in theory ( Conboy and Fitzgerald, 2004 ) and claims that APM practices and principles lack focus on software architecture ( Rosenberg and Stephens, 2003 ), that it is suitable for small teams but not larger projects ( Cohen et al., 2004 ), and that it is not a panacea for effective project management ( Veneziano et al., 2014 ), the majority of peer-reviewed papers and other empirical studies highlight the benefits of adopting agile methods ( Dybå and Dingsøyr, 2008 ). The growing use of APM seems mainly due to the potential for optimizing the operative capacity of teamwork in short implementation cycles and the positive influence exerted on team dynamics ( Fernandez and Fernandez, 2008 ). Some other documented benefits of the adoption of agile methods relate to the visualization and sharing of progress on tasks, thereby maximizing possibilities for success in projects in complex and multidisciplinary environments ( Cao et al., 2009 ).

As indicated earlier in this discussion, the use of APM has expanded beyond software development to other organizational contexts ( Ciric et al., 2018 ; Rigby et al., 2016 ). Analyses have been conducted on the implementation of agile management in product development ( Lehnen et al., 2016 ; Stare, 2014 ), educational projects ( Grimheden, 2013 ), construction projects ( Demir and Theis, 2016 ), venture capital groups ( Sutherland and Altman, 2009 ), innovation processes ( Hannola et al., 2013 ) and the management of projects in libraries ( Niemi-Grundström, 2014 ) and banks (Niclasen and Stoklund, 2016). In parallel to evidence of the contribution of AMP to a more flexible and responsive organizational culture outside of the software development world ( Küpper, 2016 ), there is increasingly more academic literature on the adoption of agile methods for different types of collaborative research processes and scientific projects. For example, studies highlight the successful utilisation of APM in academia-industry collaboration ( Sandberg and Crnkovic, 2017 ; Santos et al., 2016 ; Ota, 2010 ); the application of agile methods to faculty work ( Pope-Ruark, 2017 ) and bridging the gap between research and practice in the management of case studies ( Barroca et al., 2015 ). There is evidence of success in enabling collaboration in working with and mentoring PhD students ( Hicks and Foster, 2010 ); developing prototypes in “Action Design” research projects ( Keijzer-Broers and de Reuver, 2016 ); coordinating a large-scale European research project with distributed teams ( Marchesi et al., 2007 ) and for the production of multidisciplinary research reports ( Senabre Hidalgo, 2018 ). APM can also be successfully used in managing a research and development laboratory ( Lima et al., 2012 ); adopting experimental ethnography approaches in the workplace ( Mara et al., 2013 ); using evidence-based projects for behavioural interventions ( Hekler et al., 2016 ); or adapting lean software development in the biopharmaceutical sector ( DeWit, 2011 ) or in human-centred research practices ( Armstrong et al., 2015 ).

1.3. The scrum framework

The scrum framework is one of the most adapted APM principles and practices ( Lei et al., 2017 ). The scrum methodology facilitates the coordinated activity of programmers who break their work into small tasks that can be completed within fixed duration cycles or “sprints”, tracking progress and re-planning in regular meetings in order to develop products incrementally. The first reference to the term “scrum” appeared in Nonaka and Takeuchi's (1995) “The New New Product Development Game”, where it was defined as a holistic approach to flexible, autonomous and dynamic teamwork with six main characteristics, namely “built-in instability, self-organizing project teams, overlapping development phases, ‘multilearning’, subtle control, and organisational transfer of learning.”

In their study on leading technological companies in Japan and in the United States, via interviews with CEOs and engineers about how they developed successful innovative products, the authors identified those key characteristics and defined them as follows. (1) Built-in instability: when top management offers a project team a wide measure of freedom and also establishes challenging goals. (2) Self-organizing project teams: when groups take initiatives and develop an independent agenda for their work. (3) Overlapping development phases: instead of a sequential approach (where a project goes through several phases in a step-by-step fashion) the overlapping approach emphasizes speed and flexibility, and enhances shared responsibility and cooperation. (4) ‘Multilearning’: when team members engage in a continual process of trial and error, “learning by doing” along two dimensions: across multiple levels (individual, group, and institutional) and across diverse functions. (5) Subtle control: although teams can be largely on their own, management establishes checkpoints to prevent instability, ambiguity and tension, while in parallel there's also control through “peer pressure”. (6) Organisational transfer of learning: participants transfer their learning to others outside the group, creating conditions for new projects, and also by assigning key individuals to subsequent projects. Knowledge is also transmitted through the organization by converting project activities to standard practice.

Given the focus on a team's collective intelligence, the scrum framework usually requires facilitation to improve teamwork and motivation, to clarify who's doing what, to help with conflict resolution techniques, and to ensure that team members contribute ( Rigby et al., 2016 ). Like the rest of the team, the facilitator or “Scrum Master”, who can be an experienced colleague or a professional hired for such purpose, works on a Kanban board, which is used to document the elements, as well as enable the social aspects of tasks ( Sharp et al., 2009 ). The Scrum Master, therefore, performs the role traditionally assumed by a project manager or team leader and, in this case, is responsible for implementing scrum values and practices, as well as removing impediments ( Cervone, 2011 ).

Subjecting each task to “development sprints” (a period of work averaging 14–20 days) is another practice that is directly related to the scrum methodology ( Abrahamsson et al., 2017 ). Sprints, which are iterative cycles where a given project is developed or enhanced to produce new increments, are usually initiated with a planning meeting at which participants agree on a list of tasks to be performed by the end of a specified period. During the sprint, the team meets daily in short meetings called “standups” to track work progress and communicate ( Friess, 2018 ) and, if necessary, resolve issues ( Marcal et al., 2007 ). At the end of the sprint, a review or “retrospective” meeting is held at which the team examines developments that occurred during the sprint ( Marcal et al., 2007 ). Interested stakeholders may also attend this meeting. Another scrum practice that is directly related to the APM framework, in this case derived from Lean production models, involves the small, regular releases of “minimum viable products”, as opposed to final, fully completed and evaluated outputs at the end of long periods ( Münch et al., 2013 ).

Whether following the scrum methodology or more “light” and simple aspects of the APM framework, the adoption of a Kanban board is useful for its practicality and for tracking implementation on a daily basis ( Anderson et al., 2012 ). The literal translation of Kanban, which is of Japanese origin, is “visual” (Kan) “board” (Ban). Using Kanban, work is broken down into tasks, with descriptions shown on cards or Post-It notes that are displayed on a shared board (usually with separate columns to reflect process). In this way, workflows are visible to all members of the team ( Ahmad et al., 2013 ). Whether via physical or digital tools, the Kanban board infuses the agile development process with high visibility –providing a means of displaying the work assignments of the team, communicating priorities, making it easier to highlight bottlenecks, and helping to optimize efforts ( Cocco et al., 2011 ). This key aspect of shared visibility and dynamism in the coordination of teamwork —a paradigm focused on doable and transparent tasks— is a basic tenet of the adoption of scrum practices in collaborative processes and organizational structures outside of the software development context ( West et al., 2010 ).

2. Background

As the previous section argues, agile methods constitute an increasingly popular management process based on principles of adaptive planning, continuous improvement, frequent consultation with participants and small and regular releases ( Cao et al., 2009 ), as well as simplicity and dynamism ( Abrahamsson et al., 2017 ). In this paper —an exploratory analysis— the focus is on the appropriation of scrum as a methodological framework and its experimental use in the management of distributed and interdisciplinary research initiatives, with the aim of identifying the experiences and perceptions of researchers in the adoption of APM principles and practices, as well as the potential benefits and limitations.

In this regard, the paper seeks to answer the following research questions:

• • Which conditions favour the appropriation of APM for research collaboration?
• • To what extent can specific scrum principles and tools be adopted in interdisciplinary contexts?
• • What are the limitations and advantages of adapting agile methods in a distributed research organisation?

The UK-based Centre for the Evaluation of Complexity Across the Nexus (CECAN, cecan.ac.uk) is the focus of this case study. CECAN, a research centre hosted by the University of Surrey, was established in 2016 and comprises more than 50 members working in 14 different academic organisations such as the University of Warwick, the University of York, Cranfield University and Newcastle University. Conceived as a network of social scientists, policy makers, policy analysts and experts, CECAN explores, tests and promotes innovative policy evaluation approaches and methods pertaining to food, energy, water and the environment across nexus domains. The organisation carries out this mission through the implementation of a series of ‘real-life’ case study projects with UK partner institutions including the Economic and Social Research Council (ESRC), the Natural Environment Research Council (NERC), the Department for Environment Food and Rural Affairs (DEFRA), and the Department for Business, Energy and Industrial Strategy (BEIS), among others.

CECAN teams develop case studies and other interdisciplinary initiatives around research methodologies, complex systems, policy evaluation (in areas related to sustainability or economic promotion), as well as new evaluation and assessment methods. As a distributed initiative incorporating experts from diverse knowledge areas with varying levels of dedication and time capacity for projects, and in the absence of a central physical office or shared space, it required a specific approach to coordination and management. For this purpose, from its early operations, CECAN adopted some APM principles and practices derived from the scrum framework, as well as a digital Kanban board for managing the information and knowledge generated by its teams.

This case study utilised three methodological approaches and data sources: participant observation, analysis of online activity and semi-structured interviews. This combination of approaches forms the basis for the analysis of the adoption of agile principles and practices and the scrum framework at CECAN. A six-month period of participant observation of various activities hosted by CECAN resulted in the generation of a database of observation notes. The notes covered team dynamics and references to APM principles and practices in four meetings and two workshops, as well as the direct experience of facilitating an agile process for a specific project with four participants from CECAN. The observation notes and direct experience, together with the parallel literature review on agile principles and the adoption of agile practices in a variety of contexts, served as the basis for the development of the structure and areas of analytical focus.

The statistical and content analysis involved group interactions on the digital Kanban tool Trello ( trello.com ). Trello, a web-based project management application, is used as the main channel for coordination and knowledge sharing at CECAN. Data gathered by exporting JSON files and manual scraping of web content from 43 Trello boards facilitated the understanding of patterns of interaction between levels of activity and types of interaction. More specifically, to observe the correlation between the number of active participants, topics covered on each board and relevant actions on cards (change of status, comments and attachments) were analysed. This provided an overview of relevant interactions as well as active projects related to the centre, and allowed for more detailed coverage of the use of digital Kanban boards, which was one of the topics addressed by the interview questions and the data analysis.

An interview protocol, designed as the third and main source of data for the study, was used for seventeen semi-structured interviews with researchers (nine men and eight women) from diverse disciplines and institutions who have experience with the adoption of agile practices in their projects ( Table 1 ). The interview questions were developed with the goal of obtaining different perspectives on the experiences of researchers with the use of agile methods for collaboration in their projects. Using the semi-structured approach, the interviews took the form of conversations guided by questions on APM practices, the scrum framework, teamwork and research activity, which naturally evolved through relevant threads of conversation. The participants varied by field, academic background and experience; some were early-career while others were mid- to late-career. Ten researchers (RC), from several universities and backgrounds who collaborate with CECAN on regular basis, were interviewed. Among them, six interviewees had the specific role of Scrum Master at CECAN, with responsibility for the coordination of various case studies, on which other researchers and stakeholders from various institutions collaborate. The remaining seven interviewees (RE) were researchers and practitioners affiliated with institutions outside CECAN, who also had direct experience in the application of agile principles, to some extent, in research or academic-related projects. These seven additional interviews were conducted in the same period as the other ten, and served as a control group for contrasting diverse observations and for understanding widely important issues derived from interviews to CECAN members.

Researchers and agile practitioners interviewed.

To capture interview data accurately, each interview (which lasted approximately one hour per participant) was audio-recorded and later transcribed for coding. Using a grounded theory approach, data was coded for emerging themes ( Martin and Turner, 1986 ). Themes were discovered through a recursive coding process, then grouped into three areas of inquiry related to the research questions ( Table 2 ): (1) conditions for adopting agile methods in research, (2) adoption of scrum practices and tools, and (3) limitations and advantages of APM adoption in a distributed research organisation. Results were collated into a structured corpus of voices following that sequence, with the most representative and relevant answers selected from interviewees.

Themes derived from interviews in relation to research questions.

The results elaborate the relationship between key principles and practices derived from the literature review on agile methods and principles and reflect the findings based on activity and perceptions of participants, while at the same time integrating a description of the basic features of the scrum framework adapted during its experimental adoption.

In relation to the interviews conducted for this study, although the method as applied in this case does not require an ethical committee approval from the author's institution (Universitat Oberta de Catalunya), all the interviewees volunteered for it and signed a consent for participation accordingly, guaranteeing that confidentiality as a participant will remain secure, and that subsequent uses of records and data will be subject to standard data use policies which protect the anonymity of individuals and institutions.

4.1. Conditions for adopting agile methods in research

From the observations and interviews conducted with CECAN researchers, from the outset, it appears that the underlying rationale for selection was premised on key features of the scrum framework and agile methodology such as flexibility, autonomy and self-organisation.

4.1.1. Complex and changing setting

Since the early operations of CECAN in 2016, its executive board promoted the idea of adopting scrum methods as a possible solution for the self-management of projects, from case studies or workshop organisation to other publication-oriented initiatives. The complexity of conducting research with groups of stakeholders who operate under existing policies, while also setting an evaluation framework for new ones, demonstrates, as one participant observed, that “unpredictable events can come along and change the system potentially” (RC1). This need to regularly adapt activity to a complex context, in a new research institution with more than 30 researchers involved (most of them part-time, and usually collaborating from a range of institutions), also presented a significant management challenge, where it seemed “quite hard for any individual to regularly keep up with all that's going on” (RC2).

4.1.2. Capacity for self-organisation

Another key agile principle relates to the focus on the interactions of self-organised teams. In this case, the scrum framework facilitated regular interaction and feedback among participants. The adoption of the scrum framework was based on the same logic of self-organisation of CECAN, with teams assembled according to the interest or potential contribution of each participant to specific topics, with a logic of combining diverse disciplines and points of view. In this way, as one participant noted, “the vision comes from everyone and it is not like that one person got the direction, it actually emerges from the collective expertise of the group” (RC3).

From the perspective of participants in CECAN case studies, self-motivation was a key factor in many of the parallel projects of the centre, which usually started with very open internal calls:

The initial asking of people who wanted to be involved had to be very open, anyone who thinks they want to help is welcome to. So, I'd have that as a founding principle (RC4).

In this sense, challenges in self-organising, and especially self-assignment in adopting scrum methods for knowledge-based tasks, were cited by other researchers and professionals outside of CECAN.

An ideal scrum team is that which can sit together for a long time and listen to each other. This can significantly augment your learning process. But my theory about research is that you usually don't have this kind of team (RE1).

4.1.3. Flexibility

From observations and interviews with CECAN researchers, the flexibility of the scrum framework seemed to be one of the main reasons why APM principles were considered useful and put into practice: “I felt that this was a way of rationalizing the process that we were already doing and getting it a little bit more structural, while still valuing the flexibility that we had” (RC7).

When interviewed, researchers from outside of CECAN, who have experienced the use of agile practices in academic and research settings, also considered the extent to which it is important to be flexible and start by adapting only some of the scrum principles (to avoid excessive rigidity in its application):

If you take scrum very literal it might not work. For example, if you have divided the project into small areas and manage each one with scrum then it might be very difficult to have four daily meetings in four different groups is an hour of work every day. (RE1).

4.1.4. Adaptivity

Many participants viewed the agile framework as an interesting alternative, and a clear, easy concept to communicate and agree on. It is noteworthy that this occurred in the context of an organisation that deals regularly with the analysis and implementation of methodological approaches in areas of research and evaluation, adapting to different institutional environments and ways of working.

When you use the word ‘agile’, I think people don't question it. I think in a natural language sense, in an English sense, the meaning of the word has relevance and it sounds fine. If you say ‘we're going to work in an agile way’, I think that communicates quickly the idea (RC4).

Researchers interviewed from outside of CECAN also highlighted the importance of “learn by doing” during the initial adaptation of the scrum methodology to their specific domains, realising that it meant a way of approaching management by progressively trying things out:

We were already working with an agile approach but we had not called it ‘agile’. Later on, we started formalizing things and picking up more and more scrum tools and techniques to improve the ways we manage our projects (RE2).

4.2. Adoption of scrum principles and tools

One of the fundamental principles of the self-organising, small operative teams at CECAN was to be innovative at the management level to gain efficiency in collaboration.

We needed to adopt an approach where you can have a consensual decision making that's not necessarily a top down process, but more of a bottom up process of dialogue of mutual interaction (RC6).

It is also important to highlight that CECAN's approach to the adoption of the scrum framework was not based on specific, dedicated training or an expert coach hired for the task. It was instead based more on an evolving interpretation of the APM principles and on experimentation on the basis of an explorative, self-taught approach to the concept.

It was according to what was required and people's individual availability and restraints, and managing that set of interactions. Evidently, we were at each stage constantly thinking about agile. ‘We might have to do this and this. That's what we should do’ (RC6).

4.2.1. Facilitation roles (Scrum masters)

Soon after that initial meeting at which the core principles of the scrum framework were introduced, several of the researchers collaborating with CECAN started to adopt some of its key elements. The role of Scrum Master was one of the principles adopted. At CECAN, the role was conceived as a coordinator for case studies, which had on average four, but up to eight participants ( Fig. 1 ). CECAN Scrum Masters viewed their role as the link between specific tasks and objectives and other collaborator researchers, as well as the liaison with policymakers and representatives from government agencies. This key role was performed by CECAN researchers instead of professional Scrum Masters, and was focused on coordination, facilitating connections and providing guidelines for specific case studies.

Diagram of the scrum adaptation for research and evaluation projects at CECAN.

At CECAN, Scrum Masters were seen as connectors of expertise and coordinators guided by shared goals, as one participant explained, “I see the role of Scrum Master as a kind of intermediary in an interdisciplinary project like this one. The expertise that a Scrum Master acquires is in linking an expert to an expert and that itself requires [a] particular set of expertise for CECAN, this is an ongoing challenge” (RC9).

In this sense, the role of Scrum Master could be considered an appropriation and reinterpretation. It was one of the key agile practices adopted at CECAN, and although perceived by some participants as not fully implemented, the Scrum Master seemed to play a critical facilitation role and contributed to expanding agile management practices to the various research initiatives and projects. As corroborated by the following comment from one participant, the facilitation role provided participants with transparency and guidance, as opposed to a command and control approach, as they engaged in joint activities.

The role is very much one of a leading rather than controlling. That has to be the case because there's actually quite a lot of skill involved in managing a group of researchers for whom you have … to align management responsibility. We are a consortium of fourteen different academic organisations. If I wanted to tell you or anybody else in the team ‘you have to do this, … because I'm telling you to’ they will just go away (RC2).

Considering the high volume of case studies, publications and other tasks related to CECAN activity, for researchers acting as Scrum Masters there was also the opportunity to learn from colleagues doing the same, or even to share the role:

[In a specific project] There's really two of us acting as Scrum Master because we're covering a broad complex area of policy, to which both of us bring complementary experience. So, he and me communicate, I would say, daily. With other colleagues in CECAN, usually it's once a week at least (RC1).

It is also significant the extent to which the responsibility of having a facilitation and coordination role required additional networking efforts and expertise from researchers new to the concept:

[The Scrum Master role] It was slow to develop initially. I think it was partly about building trust and establishing relationships with the policy partners, and deciding what they wanted out of the process, and really getting a grip of what they wanted to do, how they wanted to work with CECAN (RC10).

4.2.2. Kanban boards

At CECAN—a “distributed virtual organization, with so many people doing so many things with different time involvement” (RC5)—the Kanban board was one of the agile management practices adopted. The CECAN boards were digital and created using Trello, a web-based project management application, in a format replicating Post-It notes ( Fig. 2 ). The Trello boards were one of the main channels of documentation for the centre. They were managed mainly by the Scrum Masters, and were accessed by the other CECAN researchers and occasionally by external collaborators or other stakeholders.

Screenshot of one of the CECAN Trello boards, with different tasks on cards.

As explained in the excerpt below, each new initiative or discussion was eventually translated into modular pieces of information. This represents a novel way of accessing updated and valuable knowledge for the entire organisation about the progress of projects.

One of the ways that CECAN is trying to adopt an agile approach was to set up the use of Trello boards and the use of Trello as a system for those who were engaging in case studies, but also those who were engaging in non-case study activities. To update not just their own group, but the rest of CECAN as well. The use of Trello was a way of leading the case studies, updating data for example with case study notes, and what was happening on the case studies, and any particular event that was going on (RC6).

The results from a basic statistical analysis of communication and interactions on the various Trello boards at CECAN ( Fig. 3 ) suggest that there is a relative correlation between more active users on each board, the number of cards assigned to participants and activity related to assigned cards (usually displacing them on the board according to workflows, or content edits). There appeared to be no correlation with publishing comments on cards and attaching documents to cards, as this occurred less regularly, apart from some exceptions. This would confirm that the Trello tool was used consistently through the different boards and related projects, following the typical APM process for visualizing workflows. On average, however, the analysis of the aggregated data shows that only a minority of researchers were active on the Trello platform (despite the entire organisation having full access to all the boards), which represents an unequal distribution of participation.

Statistic of cards on each Trello board, ordered by number of active users.

A comparison of the most active Trello boards, an analysis of the different levels of engagement with the tool, as well as an observation of the progressive familiarization with its functionalities and connection to APM principles, revealed that participants generally viewed their experience in using the Trello boards as an evolving process parallel to the levels of intensity and activity in the organisation. This observation is supported by the following statement from a participant who was less active in interacting or generating cards, but benefited from accessing the Trello boards: “It has proved a useful kind of map of how the case studies have evolved, sort of a narrative, if you like, a narrative of kind of key points within each of the case studies and how they developed,” (RC10).

Trello was generally perceived as practical and aligned with the need to specify, visualize and assign tasks for case studies or publications, and also “useful to have a quick overview of what is happening, and to understand what other people are doing in a quick way” (RC4). However, it represented a way of working and adapting to a specific type of interface with a significant learning curve, to which not all researchers found it easy to adapt:

I have done a lot of different projects within different project management and communication tools and it becomes too complicated in my mind (RC9).

This coincides with experiences from other researchers, and the following excerpt highlights that some colleagues, perhaps on the basis of their digital literacy, perceive this type of tool as a barrier:

There was a senior researcher struggling through it and ended up in chaos. She did not want to adapt to these things. If I said ‘Put this on the Trello board, we do not need to implement the whole thing, we can manage with something’ her response would be like, ‘Oh! What is this? I do not want to install this. I do not want to join this, it's complicated’ (RE1).

4.2.3. Development sprints

With respect to the adoption of scrum methods at CECAN, the concept of sprints was less explicit or used among participants. For example, the practice of establishing regular “standup” meetings, or retrospective meetings at the end of each sprint period was not routinely followed. Instead, researchers usually established collective agreements about the duration and responsibilities related to specific tasks, depending on the project.

Like other key aspects of agile management practices, this sprint principle —although not used with the same rigour as in software development contexts— was progressively incorporated into the logic of shared communication at CECAN:

All of those things require structured communication baseline and tasks and milestone baseline. The point is not only moving forward but also ensuring that we are still understanding each other with constant feedback (RC3).

However, from some comments emanating from the interviews, the sprint also seems to be a problematic concept to appropriate from software development processes and to adopt for the peculiarity of research tasks:

Usually two weeks long, I think everyone would agree that this is how long a sprint should be. I found it funny because probably in the tech world it works, but when you have a different type of tasks the two-week period is a bit arbitrary. In one of our case studies I had workshops which were organized about one month in advance, which made a very good sense of working in sprints (RC7).

When compared with other practitioners and researchers with longer experience using agile methods in non-software contexts, there seems to be a significant difference in the way sprints were adopted at CECAN and how they were experienced in other cases, where they constituted a central part of the process:

You just don't do one sprint, it is more like doing sprints after sprints after sprints. By doing that and looking at things in many different ways, we get incredible depth (RE3).

Sometimes we block entire evenings without any other task, or plan one-day trips to finish an article with another author. Then 10 hours working and although the article is not over, it is properly drafted (RE4).

4.2.4. Incremental development

It should also be noted that the concept of incremental development by small and regular releases (derived from the Lean principle of “minimum viable products”), when initially adopted from software development, was perceived as another complex approach to be tackled in the context of academic research.

We do work considering minimum viable products in a way, by thinking about stages of our work. For example, from a case study to a paper, and all the steps in between. But we don't use these exact words, is more implicit than explicit (RC5).

However, this practice, once adopted, served as an inspiration or key principle for some participants. As with the principle of sprints, some researchers developed an understanding and progressive process of adaptation of the concept of incremental research results, particularly in relation to the other organisations and stakeholders with whom they collaborated. As two participants observed:

What became quite useful I think in the use of the agile approach with [Stakeholder organisation A] was to say ‘we're going to iterate. We know right from the beginning there's going to be a lot of iterations'. To be able to describe that to them at the beginning. They never expected a final product suddenly to appear out of nowhere (RC4).

We start out with a set of objectives, but we have to adapt along the way. The set of objectives might change or how we meet those objectives might need to change, following the idea of continuous and feedback loops. That's how we're working in collaboration with [Stakeholder organisation B], but we're also having to touch base with them on a regular basis, because things are changing (RC1).

Outside of CECAN, other researchers also expressed familiarity with the principle, with some researchers even adopting and adapting the concept for use in their own research findings and academic writing.

‘Minimal viable finding’ is related to the way we are able to focus our research in every two weeks timeframes. ‘Here are things which are more promising and we are going to focus in this process’. We usually find several things but this is about highlighting something which we are going to promise and are going to deliver (RE3).

4.3. Challenges of APM adoption in a distributed research organisation

4.3.1. need for balance.

Given the special nature of research activity, and the need for flexibility in terms of allowing experts to add value through their knowledge and expertise, there was a constant effort at CECAN to balance, adaptively, the need to produce results and to advance in the evaluation of policies without “having a hierarchical [structure of] control” (RC2). In this sense, some participants perceived the achievement of this balance as one of the most challenging aspects of assimilating new coordination approaches, and the need of leadership through the Scrum framework as a key factor for providing results without sacrificing autonomy. For some participants, when compared with the expectations implied by APM self-organisation, these attempts appeared to be not always successful.

4.3.2. Offline vs online context

It is also important to highlight at this stage that there are few opportunities, in the context in which CECAN operates as a distributed research initiative, to meet offline in face-to-face meetings, with the result that facets such as self-organisation become more complicated (and usually require varying levels of online interaction), as described by this respondent:

I feel the biggest challenges with me while trying to do agile and scrum with CECAN is that we are remote, so it is difficult to have the immediate emergency or urgency of something that I need to do, compared to if you are seeing someone in person (RC7).

Limitations in team size and difficulties in adapting online because of individual research styles were also viewed as key issues that need to be resolved for agile methods to function effectively in this context.

[A specific publication project] started with probably 12 people who were interested but it was very difficult to get momentum of any kind. Everyone was interested in being involved but there was no momentum to start doing anything. So, in discussion with A., we decided to make the group much smaller to just three members. After this change, we have been working smoothly (RC7).

4.3.3. Proliferation of kanban boards

Due to the initial recommendations on the use of Trello at CECAN, the boards were used for the management of various types of projects, and not only case studies for publication but also for planning of workshops, the design of new methodologies or the evaluation of policies. As a result, there seemed to be a proliferation of boards, which were not always useful or used in accordance with agile principles. One participant expressed the following view:

I think that Trello works best where people have defined responsibilities for a board and know who to contact, plus have predefined rules which are particular to a board. Probably, this concept has not been as clear to the users as it could have been, partially due to the fact that it is a new concept for everyone (RC7).

The experiences recounted by participants on the use of Trello boards as a discussion channel reflect their expectations about the tool in relation to their communication needs, given the complexity and limits of interchanging knowledge from their individual locations and institutions. Others highlighted the difficulty of adopting new digital tools instead of developing new strategies focused on the physical context.

4.3.4. Trust in relationships

The high volume of case studies, publications and other tasks reflected on the numerous Trello boards, afforded researchers acting as Scrum Masters the opportunity to learn from colleagues in similar positions, or for sharing the role, and thereby learn about the implications of managing case studies as Scrum Masters in a more networked and interactive way. However, as far as the responsibility of the facilitation and coordination role is concerned, as one participant explained, the extent to which it required additional effort and progressive ‘learn-by-doing’ expertise from researchers new to the concept is significant.

It was slow to develop initially. I think it was partly about building trust and establishing relationships with the policy partners, and deciding what they wanted out of the process, and really getting a grip of what they wanted to do, how they wanted to work with CECAN (RC10)

This view is similar to that of other researchers who experienced the same challenges in similar roles in research-oriented or academic contexts other than CECAN.

4.3.5. Types of research

In some of the interviews, there was often a return to the question about the extent to which it is possible to adopt agile principles in all types of research or whether, as in the view of some CECAN participants, APM principles represent a methodological framework that is more suitable to applied research and contexts where time constraints and pressure from stakeholders make it more applicable and imperative.

There are projects which are quite theoretical, with basic research, where this kind of agile is probably not likely to be very helpful. So, I wouldn't want to force agile on every piece of research (RC2).

In contrast, confirming interest in the scrum framework from a wider perspective, in front of the same question other interviewees commented how APM practices were incorporated into their own research organisations, outside of their collaboration with CECAN:

I have seen it working nicely across a variety of domains. In my small department we started it from zero, we have been doing it and have witnessed it progress. Now, we are about ten people (RC3).

I am working with two other people on projects who are not part of the original CECAN team, they have been subcontracted to come in and help work on it. I have been ‘scrumming’ with them offline, not using the traditional forums like Trello (RC7).

4.3.6. Ad hoc adoption

However, other perspectives also addressed the complexity of applying agile principles to CECAN research and evaluation outputs and the key limitations of time and resources, as well as its correlation with the need for more flexibility in coordination:

I think adopting an agile approach in a prescriptive way it's not necessarily effective. It's easy to be quite agile in the sense of having a very weekly sense of meetings, at a particular time on a particular day, if the people that are involved are not overly constrained in terms of time or labour or any sort of resource constraints. When they are, then you have to be quite adaptable or flexible according to the regularity, according to the main principal parties involved. So, I think from that perspective, more open agile use approach is perhaps more effective than a prescript one that says ‘we're going to be this regular in terms of when our meetings are going to happen, when we need to update the Trello board, so on and so forth’ (RC6).

In this respect, other experts with experience in the utilisation of agile principles outside of CECAN also emphasized the importance of flexibility and openness when adopting these methodologies, instead of following blindly the rules and proceedings as they are established in software development processes.

I have come up with methodologies, and I know that they're all made up, there are frictional of context specific tricks, and methods, and tools and thinking. Agile presupposes that the ‘big box’ methodologies can ignore context in a way. Like a call and response mechanism which is very rule based and explicit, and I don't think that this is how a method works (RE5).

4.3.7. Institutional culture

For other researchers, who are familiar with scrum and agile methods, another key issue is related to the complexity and the management challenges embedded at the institutional level in universities and scientific departments:

The group can be agile but it faces a system like the academia and the university that is not agile. So, the motivation to do research and at the same time adapt to new ways of doing is complicated to manage (RE4).

Managers of research projects and IPs are not trained in project management, nor these skills are covered in PhD courses or similar. You can only self-learn about it, or explore on your own your ability to do so by acquiring collaboration skills and techniques (RE7).

5. Discussion

The objective of this article was to explore the adoption of agile methods in a distributed research initiative, and especially the appropriation of the scrum framework as a coordination and communication solution for the management of collaborative interdisciplinary projects. Taking into account the specific characteristics applicable to research in academic and scientific areas (as a separate context from software development processes, where the APM framework was developed and is widely used), the adoption seemed successful overall in that it facilitated the generation of new dynamics of collaboration, benefiting from some APM principles and practices in various ways. However, the process was also challenging and had some limitations in terms of a shared understanding and coherent application of the scrum framework, when compared to similar experiences in the use of agile methods in research projects.

In this regard, according to the data obtained from interviews, the adoption of agile methods in research collaboration is suited to organisations embedded in complex and changing settings, with some capacity for self-organisation, flexibility and adaptivity to new management approaches, which connects with the description of organizational networks ( Spinuzzi, 2015 , p. 58). On the other hand, relevant challenges identified for APM adoption in research point to issues related to: (1) the needed balance between efficiency and autonomy of participants, (2) the limitations of the online context for coordinating activity, (3) the tendency to proliferation of kanban boards; (4) the need to build trust in relationships when coordinating, (5) the type of research activity carried out, (6) time and resources constraints, (7) the importance of tailoring scrum principles to activities, and (8) the institutional culture of academic and research organisations.

Integrating agile methods and practices for interdisciplinary collaboration requires high degrees of flexibility and “learn by doing” approaches, similar to other project management methodologies and approaches ( Lauren, 2018 , p. 30). In this sense, the scrum framework constitutes a methodological framework that can be counterproductive if it is too ambitiously or rigidly implemented in this type of context, as indicated in the literature on the utilisation APM outside of the software development sector ( Ciric et al., 2018 ). According to Nonaka and Takeuchi (1995) , this type of participative management can be favourable for several types of agile development where conditions such as “built-in instability, self-organizing project teams, overlapping development phases, ‘multilearning’, subtle control, and organizational transfer of learning”, converge and are present to some extent in the philosophy of the collaboration initiative. When adopted by academic participants and experts familiar with research or evaluation methods, the scrum framework seems to be an easy concept to transfer and experiment with, even though specific tailoring to the idiosyncrasies of collaboration and personal motivations may be required when adapting APM ( Gandomani et al., 2014 ). Also, as attested by the literature on agile software development, characteristics such as team size and specificities such as the online tools required for operating in distributed contexts seem critical, as well as its suitability for small groups but not for large projects ( Cohen et al., 2004 ), or the significant complexity that may be experienced when adopted by remote as opposed to collocated project teams ( Paasivaara et al., 2009 ; Teasley et al., 2000 ).

Scrum principles adopted by various research teams, as analysed in this study, were seen as a valuable addition to the coordination of projects, with diverse levels of agreement about their successful implementation and perceived challenges. For CECAN self-organised teams, in a networked context requiring new participation strategies, working on case studies following APM principles provided a structured approach to a different style of management of evaluation and research-related tasks. Teams perceived positive attributes that are also referenced in previous studies about agile methods, including easy adoption and relation to project success ( Serrador and Pinto, 2015 ), as well as improved teamwork through the focus on human and social factors ( Dybå and Dingsøyr, 2008 ). Several interviewees highlighted the key role of the Scrum Master as facilitator but showed less agreement in relation to new concepts when applied to scientific activity such as “sprint development”, or the importance of small and regular releases of research outputs, when applied to scientific activity.

Studies on agile management have demonstrated the benefits to be gained with respect to fostering trust and cohesion in teams ( McHugh et al., 2012 ). Empirical evidence points to a correlation with differing levels of shared leadership, team orientation, cross-functionality, internal learning processes and team autonomy ( Moe et al., 2009 ; Stettina and Heijstek, 2011 ). This seems to be the case as well in the specific research context studied at CECAN, and also when contrasted with perspectives from other researchers who are familiar with agile methods. Some of the limitations of agile methods addressed by academic literature are also present in this case, such as the difficulties experienced by certain individuals or personality types in properly integrating into agile teams ( Whitworth and Biddle, 2007 ). As well as the constraints perceived as inherent to the tradition of academic institutions and the lack of new management practices in scientific activity ( Pope-Ruark, 2017 ), or difficulties in adapting to digital tools by senior researchers, some other complexities of adopting agile methods for research were evident. For instance, the timeframes for developing intellectual activity, and the motivation for doing so, can vary significantly depending on the type of project. Also, some researchers held the view that there should be a balance between prescriptive and adaptable formulas for this type of dynamic management.

In relation to specific tools, only a relative minority of researchers were active on the Trello platform, despite the entire organisation having full access to all the boards. This unequal distribution of participation via the digital Kanban board seems to represent a typical “90/9/1 principle” or “power law” ( Nielsen, 2006 ), usually present in online communities of peer production, where the fact that a large percentage of people do not contribute does not necessarily constitute a problem or put at risk the achievement of common goals ( Fuster Morell, 2014 ). In this sense, for a number of researchers, the proliferation of Trello boards represented an organisational challenge in terms of managing the tasks in progress and staying on top of all the boards, once several boards were in active use, which coincides with the findings of other studies about the adoption of digital Kanban boards for knowledge management in distributed organisations ( McLean and Canham, 2018 ).

Lessons learned from this case study point to the need to reconsider the suitability of the scrum framework as the best agile approach for distributed research management. Future studies should explore if more open interpretations of APM practices (which for example focus on the regular but less structured updating of tasks via Kanban boards) could be more successfully adopted in this context, or if on the contrary, additional scrum practices (such as regular “standups” in short periods, or retrospective meetings) could improve the adaptation of APM principles and practices adapted to research activity. Another relevant issue emanating from this exploratory study relates to whether the adoption of professional agile facilitation (by experts in scrum or other agile practices and not researchers) is important and should be addressed with a comparative focus in future cases. As one of its main limitations, this study did not gather data that could compare adoption in such terms. Finally, in relation to the critical factor of remote, distributed research teamwork, another line of inquiry should address how agile practices could be used effectively in fully allocated science teams, where sharing the same physical space could benefit from the use of offline Kanban boards, as opposed to digital ones.

Declarations

Author contribution statement.

Enric Senabre Hidalgo: Analyzed and interpreted the data; Contributed reagents, materials, analysis tools or data; Wrote the paper.

Funding statement

This work was supported by CECAN and University of Surrey under a Fellowship grant agreement.

Competing interest statement

The authors declare no conflict of interest.

Additional information

No additional information is available for this paper.

• Abrahamsson P., Salo O., Ronkainen J., Warsta J. 2017. Agile Software Development Methods: Review and Analysis. arXiv preprint arXiv:1709.08439. [ Google Scholar ]
• Ahmad M.O., Markkula J., Oivo M. Software Engineering and Advanced Applications (SEAA), 2013 39th EUROMICRO Conference on. IEEE; 2013. Kanban in software development: a systematic literature review; pp. 9–16. [ Google Scholar ]
• Anderson D.J., Concas G., Lunesu M.I., Marchesi M., Zhang H. International Conference on Agile Software Development. Springer; Berlin: 2012. A comparative study of Scrum and Kanban approaches on a real case study using simulation; pp. 123–137. [ Google Scholar ]
• Armstrong P., Gordon R., Hoffecker E., Krystalli R., Leith K., Stinchfield B., Wilson K. MIT; Cambridge, MA: 2015. Lean Research: Defining Rigor. Working Paper, MIT D-Lab-The Fletcher School of Law and Diplomacy. [ Google Scholar ]
• Bammer G. Enhancing research collaborations: three key management challenges. Res. Pol. 2008; 37 (5):875–887. [ Google Scholar ]
• Barroca L., Sharp H., Salah D., Taylor K., Gregory P. Bridging the gap between research and agile practice: an evolutionary model. Int. J. Syst. Assur. Eng. Manag. 2015:1–12. [ Google Scholar ]
• Beck K., Beedle M., van Bennekum A., Cockburn A., Cunningham W., Fowler M., Kern J. 2001. Manifesto for Agile Software Development. http://agilemanifesto.org/ Retrieved from. [ Google Scholar ]
• Borgman C.L. MIT Press; 2010. Scholarship in the Digital Age: Information, Infrastructure, and the Internet. [ Google Scholar ]
• Bozeman B., Corley E. Scientists' collaboration strategies: implications for scientific and technical human capital. Res. Pol. 2004; 33 (4):599–616. [ Google Scholar ]
• Bridgeford T., Amant K.S. Taylor & Francis; 2017. Academy-Industry Relationships and Partnerships. [ Google Scholar ]
• Cao L., Mohan K., Xu P., Ramesh B. A framework for adapting agile development methodologies. Eur. J. Inf. Syst. 2009; 18 (4):332–343. [ Google Scholar ]
• Cervone H.F. Understanding agile project management methods using scrum. OCLC Syst. Serv. Int. Dig. Libr. Persp. 2011; 27 (1):18–22. [ Google Scholar ]
• Ciric D., Lalic B., Gracanin D., Palcic I., Zivlak N. 2018 IEEE International Symposium on Innovation and Entrepreneurship (TEMS-ISIE) IEEE; 2018, March. Agile project management in new product development and innovation processes: challenges and benefits beyond software domain; pp. 1–9. [ Google Scholar ]
• Cocco L., Mannaro K., Concas G., Marchesi M. International Conference on Agile Software Development. Springer; Berlin: 2011, May. Simulating kanban and scrum vs. waterfall with system dynamics; pp. 117–131. [ Google Scholar ]
• Cockburn A. Agile software development joins the “Would-Be” crowd. Cut. IT J. 2002; 15 (1):6–12. [ Google Scholar ]
• Cohen D., Lindvall M., Costa P. An introduction to agile methods. Adv. Comput. 2004; 62 :1–66. [ Google Scholar ]
• Conboy K., Fitzgerald B. Proceedings of the 2004 ACM Workshop on Interdisciplinary Software Engineering Research. ACM; 2004, November. Toward a conceptual framework of agile methods: a study of agility in different disciplines; pp. 37–44. [ Google Scholar ]
• Conforto E.C., Salum F., Amaral D.C., da Silva S.L., de Almeida L.F.M. Can agile project management be adopted by industries other than software development? Proj. Manag. J. 2014; 45 (3):21–34. [ Google Scholar ]
• Cooke N.J., Hilton M.L., editors. Enhancing the Effectiveness of Team Science. National Academies Press; Washington, D.C.: 2015. [ PubMed ] [ Google Scholar ]
• Daradoumis T., Roca M., Grasman S.E., Faulin J. Collaborative and distributed e-research: innovations in technologies, strategies, and applications. In: Juan A.A., editor. Information Science Reference. 2012. [ Google Scholar ]
• Delfanti A. Users and peers. From citizen science to P2P science. Cell. 2016; 21 :01. [ Google Scholar ]
• Demir S.T., Theis P. 24th Annual Conference of the International Group for Lean Construction, Boston, USA. 2016. Agile design management–the application of scrum in the design phase of construction projects. [ Google Scholar ]
• DeWit T. Lean techniques: the QC lab can reduce product lead times. Qual. Assur. J. 2011; 14 (3-4):72–75. [ Google Scholar ]
• Dybå T., Dingsøyr T. Empirical studies of agile software development: a systematic review. Inf. Softw. Technol. 2008; 50 (9):833–859. [ Google Scholar ]
• Eccles K., Schroeder R., Meyer E.T., Kertcher Z., Barjak F., Huesing T., Robinson S. Proceedings of NCeSS International Conference on e-Social Science, Cologne, June. 2009. The future of e-research infrastructures; pp. 24–26. [ Google Scholar ]
• Fuster Morell M. Governance of online creation communities for the building of digital commons: viewed through the framework of the institutional analysis and development. In: Madison M.J., Strandburg K., Frischmann B., editors. Governing the Knowledge Commons. Oxford University Press; Oxford: 2014. [ Google Scholar ]
• Fernandez D.J., Fernandez J.D. Agile project management agilism versus traditional approaches. J. Comput. Inf. Syst. 2008; 49 (2):10–17. [ Google Scholar ]
• Friess E. “Filling to capacity”: an exploratory study of project management language in agile scrum teams. Tech. Commun. 2018; 65 (2):169–180. [ Google Scholar ]
• Gandomani T.J., Zulzalil H., Ghani A.A., Sultan A.B.M., Sharif K.Y. How human aspects impress Agile software development transition and adoption. Int. J. Softw. Eng. Appl. 2014; 8 (1):129–148. [ Google Scholar ]
• Gray D.O., Lindblad M., Rudolph J. Industry–university research centers: a multivariate analysis of member retention. J. Technol. Transf. 2001; 26 (3):247–254. [ Google Scholar ]
• Grimheden M.E. Can agile methods enhance mechatronics design education? Mechatronics. 2013; 23 (8):967–973. [ Google Scholar ]
• Hannola L., Friman J., Niemimuukko J. Application of agile methods in the innovation process. Int. J. Bus. Innov. Res. 2013; 7 (1):84–98. [ Google Scholar ]
• Hekler E.B., Klasnja P., Riley W.T., Buman M.P., Huberty J., Rivera D.E., Martin C.A. Agile science: creating useful products for behavior change in the real world. Transl. Behav. Med. 2016; 6 (2):317–328. [ PMC free article ] [ PubMed ] [ Google Scholar ]
• Helbing D., Brockmann D., Chadefaux T., Donnay K., Blanke U., Woolley-Meza O., Perc M. Saving human lives: what complexity science and information systems can contribute. J. Stat. Phys. 2015; 158 (3):735–781. [ PMC free article ] [ PubMed ] [ Google Scholar ]
• Hicks M., Foster J.S. Department of Computer Science; 2010. Adapting Scrum to Managing a Research Group. http://www.cs.umd.edu/∼mwh/papers/score.pdf Technical Report #CS-TR-4966. Retrieved from. [ Google Scholar ]
• Hoda R., Noble J., Marshall S. Self-organizing roles on agile software development teams. IEEE Trans. Softw. Eng. 2013; 39 (3):422–444. [ Google Scholar ]
• Jeffrey P. Smoothing the waters: observations on the process of cross-disciplinary research collaboration. Soc. Stud. Sci. 2003; 33 (4):539–562. [ Google Scholar ]
• Jirotka M., Lee C.P., Olson G.M. Supporting scientific collaboration: methods, tools and concepts. Comput. Support. Coop. Work. 2013; 22 (4-6):667–715. [ Google Scholar ]
• Katz J.S., Martin B.R. What is research collaboration? Res. Pol. 1997; 26 (1):1–18. [ Google Scholar ]
• Keijzer-Broers W.J., de Reuver M. vol. 9661. Springer; NY: 2016. Applying Agile design sprint methods in action design research: prototyping a health and wellbeing platform; pp. 68–80. (Proceedings of the 11th International Conference on Tackling Society's Grand Challenges with Design Science). [ Google Scholar ]
• Keraminiyage K., Haigh R., Amaratunga D. Achieving success in collaborative research: the role of virtual research environments. J. Inf. Technol. Constr. 2009; 14 :59–69. [ Google Scholar ]
• König B., Diehl K., Tscherning K., Helming K. A framework for structuring interdisciplinary research management. Res. Pol. 2013; 42 (1):261–272. [ Google Scholar ]
• Kraut R.E., Galegher J., Egido C. Relationships and tasks in scientific research collaboration. Hum. Comput. Interact. 1987; 3 (1):31–58. [ Google Scholar ]
• Küpper S. Proceedings of the 20th International Conference on Evaluation and Assessment in Software Engineering. ACM; NY: 2016. The impact of agile methods on the development of an agile culture: research proposal: [the agile evolution] p. 1. [ Google Scholar ]
• Lauren B. 2018. Communicating Project Management: a Participatory Rhetoric for Development Teams. Routledge. [ Google Scholar ]
• Lassi M., Sonnenwald D.H. vol. 15. 2010. Identifying factors that may impact the adoption and use of a social science collaboratory: a synthesis of previous research. (The Seventh International Conference on Conceptions of Library and Information Science (CoLIS)—“Unity in Diversity”). No. 3. [ Google Scholar ]
• Lehnen J., Schmidt T.S., Herstatt C. Bringing agile project management into lead user projects. Int. J. Prod. Dev. 2016; 21 (2-3):212–232. [ Google Scholar ]
• Lei H., Ganjeizadeh F., Jayachandran P.K., Ozcan P. A statistical analysis of the effects of scrum and kanban on software development projects. Robot. Comput. Integr. Manuf. 2017; 43 :59–67. [ Google Scholar ]
• Liao C.H. How to improve research quality? Examining the impacts of collaboration intensity and member diversity in collaboration networks. Scientometrics. 2011; 86 (3):747–761. [ Google Scholar ]
• Lima I.R., de Castro Freire T., Costa H.A.X. Adapting and using scrum in a software research and development laboratory. Rev. Sist. Inf. FSMA. 2012;(9):16–23. [ Google Scholar ]
• Mara A.F., Potts L., Bartocci G. Proceedings of the 31st ACM International Conference on Design of Communication. ACM; NY: 2013. The ethics of agile ethnography; pp. 101–106. [ Google Scholar ]
• Marcal A.S.C., Soares F.S.F., Belchior A.D. Software Engineering Workshop, 2007. SEW 2007. 31st IEEE. IEEE; Washington, D.C: 2007, March. Mapping CMMI project management process areas to SCRUM practices; pp. 13–22. [ Google Scholar ]
• Marchesi M., Mannaro K., Uras S., Locci M. Distributed scrum in research project management. In: Concas G., Damiani E., Scotto M., Succi G., editors. Agile Processes in Software Engineering and Extreme Programming. XP 2007. vol. 4536. Springer; Berlin: 2007. pp. 240–244. (Lecture Notes in Computer Science). [ Google Scholar ]
• Martin P.Y., Turner B.A. Grounded theory and organizational research. J. Appl. Behav. Sci. 1986; 22 (2):141–157. [ Google Scholar ]
• McHugh O., Conboy K., Lang M. Agile practices: the impact on trust in software project teams. IEEE Softw. 2012; 29 (3):71–76. [ Google Scholar ]
• McLean J., Canham R. Managing the electronic resources lifecycle with kanban. Open Inf. Sci. 2018; 2 (1):34–43. [ Google Scholar ]
• Moe N.B., Dingsøyr T., Røyrvik E.A. Putting agile teamwork to the test –a preliminary instrument for empirically assessing and improving agile software development. In: Abrahamsson P., Marchesi M., Maurer F., editors. Agile Processes in Software Engineering and Extreme Programming. XP 2009. vol. 31. Springer; Berlin: 2009. pp. 114–123. (Lecture Notes in Business Information Processing). [ Google Scholar ]
• Münch J., Fagerholm F., Johnson P., Pirttilahti J., Torkkel J., Jäarvinen J. Lean Enterprise Software and Systems. vol. 167. Springer; Berlin: 2013. Creating minimum viable products in industry-academia collaborations; pp. 137–151. (Lecture Notes in Business Information Processing). [ Google Scholar ]
• Nielsen J. Participation inequality: lurkers vs. contributors in internet communities. Jakob Nielsens Alertbox. 2006 [ Google Scholar ]
• Niemi-Grundström M. Developing, evaluating and managing library with agile methods. Libr. Manag. 2014; 35 (6/7):481–485. [ Google Scholar ]
• Nonaka I., Takeuchi H. Oxford University Press; NY: 1995. The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. [ Google Scholar ]
• Ota M. Scrum in research. In: Luo Y., editor. Cooperative Design, Visualization and Engineering Proceedings of the 7th International Conference (CDE 2010) Springer; Berlin: 2010. pp. 109–116. [ Google Scholar ]
• Paasivaara M., Durasiewicz S., Lassenius C. 4th International Conference on Global Software Engineering, ICGSE'09. IEEE; Washington, D.C.: 2009. Using scrum in distributed agile development: a multiple case study; pp. 195–204. [ Google Scholar ]
• Perkmann M., Walsh K. The two faces of collaboration: impacts of university-industry relations on public research. Ind. Corp. Change. 2009; 18 (6):1033–1065. [ Google Scholar ]
• Pope-Ruark R. University of Chicago Press; 2017. Agile Faculty: Practical Strategies for Managing Research, Service, and Teaching. [ Google Scholar ]
• Powell W.W., Snellman K. The knowledge economy. Ann. Rev. Sociol. 2004:199–220. [ Google Scholar ]
• Rigby D.K., Sutherland J., Takeuchi H. Harvard Business Review; 2016. Embracing Agile. May. [ Google Scholar ]
• Rigby J., Edler J. Peering inside research networks: some observations on the effect of the intensity of collaboration on the variability of research quality. Res. Pol. 2005; 34 (6):784–794. [ Google Scholar ]
• Robinson H., Sharp H. The social side of technical practices. In: Baumeister H., Marchesi M., Holcombe M., editors. Extreme Programming and Agile Processes in Software Engineering. XP 2005. vol. 3556. Springer; Berlin: 2005. pp. 100–108. (Lecture Notes in Computer Science). [ Google Scholar ]
• Rosenberg D., Stephens M. Apress; NY: 2003. Extreme Programming Refactored: the Case against XP. [ Google Scholar ]
• Sandberg A.B., Crnkovic I. Proceedings of the 39th International Conference on Software Engineering: Software Engineering in Practice Track. IEEE Press; Washington, D.C: 2017. Meeting industry: academia research collaboration challenges with agile methodologies; pp. 73–82. [ Google Scholar ]
• Santos N., Fernandes J.M., Carvalho M.S., Silva P.V., Fernandes F.A., Rebelo M.P., Machado R.J. International Conference on Computational Science and its Applications. Springer International Publishing; NY: 2016. Using scrum together with UML models: a collaborative university-industry R&D software project; pp. 480–495. [ Google Scholar ]
• Scrum Alliance . 2016. The State of Scrum Report 2017 Edition. https://www.scrumalliance.org/learn-about-scrum/state-of-scrum/2017-state-of-scrum Retrieved from. [ Google Scholar ]
• Senabre Hidalgo E. Management of a multidisciplinary research project: a case study on adopting agile methods. J. Res. Pract. 2018; 14 (1):2. [ Google Scholar ]
• Serrador P., Pinto J.K. Does agile work? – a quantitative analysis of agile project success. Int. J. Proj. Manag. 2015; 33 (5):1040–1051. [ Google Scholar ]
• Sharp H., Robinson H., Petre M. The role of physical artefacts in Agile software development: two complementary perspectives. Interact. Comp. 2009; 21 (1–2):108–116. [ Google Scholar ]
• Smykla E., Zippel K. OISE; 2010. Literature Review: Gender and International Research Collaboration; p. 936970. Report prepared with funding from NSF. [ Google Scholar ]
• Sonnenwald D.H. Scientific collaboration. Ann. Rev. Inf. Sci. Technol. 2007; 41 (1):643–681. [ Google Scholar ]
• Spinuzzi C. University of Chicago Press; 2015. All Edge: Inside the New Workplace Networks. [ Google Scholar ]
• Stare A. Agile project management in product development projects. Proc. Soc. Behav. Sci. 2014; 119 :295–304. [ Google Scholar ]
• Stettina C.J., Heijstek W. European Conference on Software Process Improvement. Springer; Berlin, Heidelberg: 2011, June. Five agile factors: helping self-management to self-reflect; pp. 84–96. [ Google Scholar ]
• Sutherland J., Altman I. Agile Conference, 2009. AGILE'09. (pp. 350-355) IEEE; 2009, August. Take no prisoners: how a venture capital group does scrum. [ Google Scholar ]
• Teasley S., Covi L., Krishnan M.S., Olson J.S. Proceedings of the 2000 ACM Conference on Computer Supported Cooperative Work. ACM; 2000, December. How does radical collocation help a team succeed? pp. 339–346. [ Google Scholar ]
• Veneziano V., Rainer A.W., Haider S. 2014. When Agile is Not Good Enough: an Initial Attempt at Understanding How to Make the Right Decision. arXiv preprint arXiv:1402.5557. [ Google Scholar ]
• Vom Brocke J., Lippe S. Managing collaborative research projects: a synthesis of project management literature and directives for future research. Int. J. Proj. Manag. 2015; 33 (5):1022–1039. [ Google Scholar ]
• Wagner C.S., Whetsell T.A., Leydesdorff L. Growth of international collaboration in science: revisiting six specialties. Scientometrics. 2017; 110 (3):1633–1652. [ Google Scholar ]
• Wang J., Hicks D. Scientific teams: self-assembly, fluidness, and interdependence. J. Inf. 2015; 9 (1):197–207. [ Google Scholar ]
• West D., Grant T., Gerush M., D'silva D. Agile development: mainstream adoption has changed agility. Forrester Res. 2010; 2 (1):41. [ Google Scholar ]
• Whitworth E., Biddle R. Agile Conference (AGILE) IEEE; Washington, D.C.: 2007. The social nature of agile teams; pp. 26–36. [ Google Scholar ]
• Wuchty S., Jones B.F., Uzzi B. The increasing dominance of teams in production of knowledge. Science. 2007; 316 (5827):1036–1039. [ PubMed ] [ Google Scholar ]
• Ynalvez M.A., Shrum W.M. Professional networks, scientific collaboration, and publication productivity in resource-constrained research institutions in a developing country. Res. Pol. 2011; 40 (2):204–216. [ Google Scholar ]
• Zuboff S. Basic Books; NY: 1988. In the Age of the Smart Machine: the Future of Work and Power. [ Google Scholar ]

Agile planning and development methods

Ieee account.

• Change Username/Password
• Update Address

Purchase Details

• Payment Options
• Order History
• View Purchased Documents

Profile Information

• Communications Preferences
• Profession and Education
• Technical Interests
• US & Canada: +1 800 678 4333
• Worldwide: +1 732 981 0060
• Contact & Support
• About IEEE Xplore
• Accessibility
• Terms of Use
• Nondiscrimination Policy
• Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest technical professional organization dedicated to advancing technology for the benefit of humanity. © Copyright 2023 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.

Proceedings of the Future Technologies Conference

FTC 2020: Proceedings of the Future Technologies Conference (FTC) 2020, Volume 3 pp 357–364 Cite as

Research on Various Software Development Lifecycle Models

• Nabeel Asif Khan 17  
• Conference paper
• First Online: 31 October 2020

1404 Accesses

2 Citations

Part of the Advances in Intelligent Systems and Computing book series (AISC,volume 1290)

Software development life cycle models define a guideline for the design, development and testing of the software. These models ensure that software meets the customer requirements and is developed within the given timeframe and budget. There are various SDLC models used for software development. This paper describes various types of traditional SDLC models like waterfall mode, v model and spiral model. It also describes contemporary models like agile model and RAD model. The paper also highlights the importance of security procedures in software development life cycle process. The basic motive of this paper is to study variety of models and make a relative study of them to understand their advantages and disadvantages.

• Software development life cycle
• Software requirement specification
• Software design document
• Secure SDLC

This is a preview of subscription content, access via your institution .

Buying options

• Available as PDF
• Read on any device
• Instant download
• Own it forever
• Available as EPUB and PDF
• Compact, lightweight edition
• Dispatched in 3 to 5 business days
• Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Kumar, S., Dubey, P.: Software development life cycle (SDLC) analytical comparison and survey on traditional and agile methodology, Abhinav Nat. Mon. Refereed J. Res. Sci. Technol. 2 (8) 2013

Google Scholar  

Nanda, M.P.: Productivity improvement through agile transformation. J. Manage. Res. Anal. 5 (4), 211–218 (2018)

Bhatnagar, M.V., Rather, M.A.: A comparative study of software development life cycle models. J. Appl. Innov. Eng. Manage. 4 (10), 23–29 (2015)

Navita: A study on software development life cycle & its model. In: International Journal of Engineering Research in Computer Science and Engineering, September 2017

Kavitha, D., Lalband, N.: Software engineering for smart healthcare applications. Int. J. Appl. Innovative Technol. Exploring Eng. 8 , 325–331 (2015)

Dubey, D., Mishra, A.: A comparative study of different software development life cycle models in different scenarios. Int. J. Adv. Res. Comput. Sci. Manage. Stud. 1 (5) 2013

Idrees, M., Iqbal, S.Z.: Z-SDLC model: a new model for software development life cycle (SDLC). Int. J. Eng. Adv. Res. Technol. 3 , 8 (2017)

Mani, Y.K.: A review paper on software development lifecycle models. J. Emerg. Technol. Innovative Res. 5 (2), 2018

de Vicente Mohino, J., Bermejo Higuera, J., Bermejo Higuera, J.R., Sicilia Montalvo, J.A.: The application of a new secure software development life cycle (S-SDLC) with agile methodologies. Electronics 8 (11), 1218 (2019)

Kaur, S.: International Journal of Advanced Research in Computer Science and Software Engineering, November 2015

Download references

Author information

Authors and affiliations.

Arizona State University, Tempe, AZ, 85281, USA

Nabeel Asif Khan

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Nabeel Asif Khan .

Editor information

Editors and affiliations.

Faculty of Science and Engineering, Saga University, Saga, Japan

Prof. Dr. Kohei Arai

The Science and Information (SAI) Organization, Bradford, West Yorkshire, UK

Supriya Kapoor

Prof. Rahul Bhatia

Rights and permissions

Reprints and Permissions

Copyright information

© 2021 Springer Nature Switzerland AG

About this paper

Cite this paper.

Khan, N.A. (2021). Research on Various Software Development Lifecycle Models. In: Arai, K., Kapoor, S., Bhatia, R. (eds) Proceedings of the Future Technologies Conference (FTC) 2020, Volume 3. FTC 2020. Advances in Intelligent Systems and Computing, vol 1290. Springer, Cham. https://doi.org/10.1007/978-3-030-63092-8_24

Download citation

DOI : https://doi.org/10.1007/978-3-030-63092-8_24

Published : 31 October 2020

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-63091-1

Online ISBN : 978-3-030-63092-8

eBook Packages : Intelligent Technologies and Robotics Intelligent Technologies and Robotics (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Find a journal
• Publish with us

Members-only Content

• Monthly Member Events
• Event Session Videos
• Experience Reports
• Research Papers
• Share a Community Event
• Submit an Article to the Blog
• Submit a Member Initiative
• Promote a Training Event

Become an Agile Alliance member!

Your membership enables us to offer a wealth of resources, present renowned international events, support global community groups, and so much more! And, while you’re supporting our non-profit mission, you’ll also gain access to a range of valuable member benefits. Learn more

• Join Us Today
• Member Portal
• Membership FAQs
• Terms and Conditions
• Corporate Members

Agile Conferences

• Agile en Español
• Agile MiniCon: Future of AI
• Agile en Chile 2024
• All Agile Alliance Events
• Past Conferences

Free Member Events

• Member Events Calendar
• BYOC Lean Coffee
• Agile Tech Talks
• Member Meet & Greet
• Agile Coaching Network
• Community Events
• Non-profit Events
• Agile Training
• Sponsored Meetup Groups
• Submit a Non-profit Event
• Submit a For-profit Training
• Event Funding Request
• Global Events Calendars

• Events Calendar
• BYOC – Lean Coffee
• Member Meet & Greet
• View All Events
• Submit an Event
• Meetup Groups
• Past Conferences & Events

Agile Essentials is designed to bring you up to speed on the basic concepts and principles of Agile with articles, videos, glossary terms, and more.

Agile Essentials

Download the Agile Manifesto

To download a free PDF copy of the Agile Manifesto and 12 Principles of Agile, simply sign-up for our newsletter. Agile Alliance members can download it for free.

• Agile Essentials Overview
• Agile Manifesto
• 12 Principles Behind the Manifesto
• A Short History of Agile
• Subway Map to Agile Practices
• Agile Glossary
• Introductory Videos

Recent Blog Posts

Meet the Agile2024 Program Team – Reese Schmit

Neurodiversity and invisible disabilities in Agile

Reimagine Agile: Back to Basics, Forward to the Future

View all blog posts

Agile Resources

• Remote Working Guide
• Event Sessions
• Content Library

Sustainability Manifesto

The  Agile Sustainability Initiative has created the Agile Sustainability Manifesto in an effort to grow awareness about sustainability within the Agile community and inspire a more sustainable way of working. Read and sign now

MEMBER INITIATIVES

• Agile Sustainability Initiative
• Agiledemics Initiative
• Principle 12 Initiative
• Agile in Color Initiative
• Agile Coach Camp Worldwide

View all initiatives

Your Community

Global development.

• LATAM Community
• India Community

• Community Groups
• Community Services
• Member Initiatives
• LATAM Community Development
• India Community Development
• Volunteer Signup

Global Affiliates

OUR POLICIES

Become a sponsor.

Being an Agile Alliance sponsor is a great way to introduce your company to our members to build awareness around your products and services. Agile2023 sponsorships are going fast, but they’re great opportunities still available! Learn more >

• About Agile Alliance
• Code of Conduct
• Board of Directors
• Agile Alliance Brazil
• Agile Alliance New Zealand
• Policies, Reports & Bylaws
• Logo and Media Files
• Become a Sponsor

• Program Team
• Call for Submissions

XP 2024 Call for Submissions

25th international conference on agile software development june 4-7, 2024 • bolzano, italy.

• 25 Years of XP – Special Track
• Research Papers Track
• AI and Agile
• Coaching for Agile
• Engineering
• Leadership and Culture
• Process Innovation
• Product and Design
• Research Workshops Track
• Agile Training and Education Track
• Experience Reports Track
• Posters Track
• Lighting Talks Track

Important Dates

• Abstracts due: Feb 2, 2024 (voluntary)
• Submission deadline: Feb 09, 2024
• Notification to authors: Mar 25, 2024
• Camera-ready due: April 12, 2024

* All dates are defined as the end of the day anywhere on Earth (AoE).

Submissions

XP is the premier Agile software development conference combining research and practice. It is a unique forum where Agile researchers, practitioners, thought leaders, coaches, and trainers gather to present and discuss their most recent innovations and research results.

At its inception over 25 years ago, the XP conference focused solely on eXtreme Programming. It quickly widened its scope to include all modern Agile approaches and all the developing aspects of agility. XP draws people from around the globe, providing a diverse and inclusive environment for learning and inspiring conversations.

The theme for XP 2024 is “Reflect, Adapt, Envision,” a retrospective and futuristic view of the progress of the field and the future steps for the community.

Topics of Interest

We invite submissions of unpublished high-quality research papers full (15 pages) and short (8 pages), related to Agile and Lean software development. Full papers should present completed research that addresses a research problem and document the details and results of a study. Short papers are expected to communicate emerging research results and/or trends that have the potential to be further developed.  Such papers may also present a vision on a given topic that addresses long-term challenges and opportunities that are thoroughly justified or related to prior literature. We welcome submissions addressing topics across the full spectrum of Agile software development, broadly on Agile, and on issues of concern to researchers or practitioners (or both).

The connection between industry and academia is a core value of the XP conference. The academic track welcomes researchers and studies in methods and practices of software development and, in particular, invites those around these topics, especially if they incorporate the theme of XP2024 on “Making a Difference: Past and Future of the XP Conferences”:

• Empirical studies and evaluations of the progress in the field
• Foundations and conceptual studies
• Evaluation-based research agendas
• Evolution of agile practices and agile culture
• Leadership and coaching
• Human aspects, morale, values, ethics, and beliefs
• Diversity & Inclusion in Agile
• Business and startups
• Business and enterprise agility
• Software startups
• Global software development and offshoring
• Large-scale agile organizations
• Measurement and metrics for projects, processes, software, and teams
• Qualitative/quantitative improvement techniques
• Tools and techniques for Agile and lean development
• Agile Architecture
• Engineering and management
• Testing, release management, and deployment
• Test-driven Development, Pair Programming, and Refactoring
• Development and operations (DevOps)
• Continuous engineering and automation
• Requirements gathering
• Product management
• Teaching experiences
• Empirical studies with students
• Emerging topics
• Agility for regulated AI systems
• Agile ML Engineering
• Sustainability for teams, products, development, business models and management
• Games and game-based techniques

Submissions based on empirical studies conducted in industry-academia collaboration are encouraged.

The XP 2024 main conference proceedings will be published by Springer in the Lecture Notes in Business Information Processing (LNBIP) as Open Access.

Submissions will be screened on rigor and relevance and then evaluated by at least three program committee members based on soundness, significance, novelty, verifiability, and presentation quality.

All submissions must conform to the LNBIP formatting and submission instructions. See the instructions for authors here.

The paper should not exceed 15 pages (full papers) and 8 pages (short papers).

There is no limit on the number of submissions an author may submit, but authors are advised to focus on quality rather than quantity.

By submitting to the XP Research Papers Track, authors acknowledge that they are aware of and agree that papers submitted to XP 2024 must not have been published elsewhere and must not be under review or submitted for review elsewhere while under consideration for XP 2024. Please read the Code of Conduct for Authors.

Papers must be submitted electronically via EasyChair by the defined deadline.

Please note – The abstract deadline is voluntary, so you can still submit after that deadline.

If you have any questions or comments, please contact the track chairs.

Track Co-Chairs

• Darja Smite, Blekinge Institute of Technology ( email )
• Eduardo Guerra, Free University of Bozen-Bolzano ( email )
• Back to top

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Our Cornerstone Corporate Supporting Members

Our Corporate Supporting Members are vital to the mission of Agile Alliance.  Click here to view all corporate members.

©2023 Agile Alliance  |  All Rights Reserved  |  Privacy Policy

©2023 Agile Alliance All Rights Reserved  |  Privacy Policy

• Welcome back!

Not yet a member? Sign up now

• Renew Membership
• Agile Alliance Events
• Agile en Chile
• Resources Overview
• Agile Books
• Content Library by Category
• Content Standards
• Privacy Policy
• Cookie Policy

Privacy Overview