A Taxonomy of Inter-Team Coordination Mechanisms in Large-Scale Agile

Abstract

In large-scale agile software development, many teams work together to achieve overarching project goals. The more teams, the greater the coordination requirements. Despite the growing popularity of large-scale agile, inter-team coordination is challenging to practice and research. We conducted a case study over 1.5 years in a large-scale software development firm to better understand which inter-team coordination mechanisms are used in large-scale agile and how they support inter-team coordination. Based on a thematic analysis of 31 interviews, 113 hours of observations, and supplemental material, we identified 27 inter-team coordination mechanisms. From this, we offer the following contributions. First, we propose a taxonomy of interteam coordination with three categories: coordination meetings, such as communities of practice, inter-team stand-ups, and retrospectives; coordination roles, such as the program architects and the platform team; and coordination tools and artefacts, such as Slack and JIRA as well as inter-team task boards, product backlogs, and roadmaps. Second, the coordination mechanisms displayed combinations of four key characteristics, technical, organizational, physical, and social (TOPS), which form the basis of the TOPS framework to capture the multifaceted characteristics of coordination mechanisms. Technical relates to the software product and/or technical tools supporting software development. Organizational pertains to the structural aspects of the organization. Physical refers to tangible or spatial characteristics. Social captures interpersonal and community-based characteristics. Finally, the taxonomy and the TOPS framework provide a knowledge base and a structured approach for researchers to study as well as for software practitioners to understand and improve inter-team coordination in large-scale agile.

A longitudinal explanatory case study of coordination in a very large development programme: the impact of transitioning from a first- to a second-generation large-scale agile development method

“…In the following, we show knowledge to date on the group, personal and impersonal modes of coordination. Note that a recent case study on interteam coordination mechanisms offers an alternative taxonomy, categorizing mechanisms according to the four characteristics of technical, organizational, physical, and social (Berntzen et al 2022). We have chosen to use the modes proposed by Van de Ven (1976) to easier relate to previously published theory on interteam coordination.…”

Scaling scrum with a customized nexus framework: A report from a joint industry‐academia research project

“…13,55,60,[62][63][64][65] Therefore, instead of taking on an entire framework, large organizations often develop hybrid approaches depending on contextual criteria, where a customized agile method and traditional project management practices co-exist in different configurations alongside each other. 4,12,13,63,[65][66][67][68] However, guidance on applying any of the "off-the-shelf" frameworks outside of its prescribed process hardly exists, 51 while practitioners rarely have expertise in situational method engineering 5,8,14 and thus have to resort to unstructured approaches. Unfortunately, taking account of difficulties in anticipating what method fragments to choose and how to combine them effectively, 69 ad hoc tailoring usually does not bring expected software process improvements.…”

“…Last but not least, our work strengthens the previous findings that large-scale agile adoption is not a one-and-done affair by just taking into use off-the-shelf, but an iterative process of stepwise refinement by context-based tailoring. 4,6,12,32,68 AUTHOR CONTRIBUTIONS Andrzej Joskowski: Conceptualization (equal); methodology (supporting); investigation (lead); writing -original draft (equal). Adam Przybyłek: Conceptualization (equal); methodology (lead); supervision (lead); visualization (lead); writing -original draft (equal); writing -review and editing (supporting).…”

“…3 Nonetheless, as the vast majority of software development projects are unique, they cannot be properly supported by any off-the-shelf framework implemented in its original, textbook format. [4][5][6][7][8][9][10][11][12][13] Besides, not all organizations are ready to fully implement any framework in a one-time shift regarding organizational, cultural, and technical aspects, 13,14 whereas there are no gradual approaches or guidelines for large-scale agile transformation. 15,16 Indeed, previous studies have reported numerous challenges while adopting such frameworks, 4,6,17 including a mismatch between framework and organization, 6,7,13 controversies within the framework, [18][19][20] complex organization setup, 15,20 changes in management structure, 6,15,19,21,22 fluctuating company's policies, 15,19,21 and change resistance.…”

“…15,16 Indeed, previous studies have reported numerous challenges while adopting such frameworks, 4,6,17 including a mismatch between framework and organization, 6,7,13 controversies within the framework, [18][19][20] complex organization setup, 15,20 changes in management structure, 6,15,19,21,22 fluctuating company's policies, 15,19,21 and change resistance. 15,19,20 Not surprisingly, it has been acknowledged that agile methods often need to be tailored to accommodate specific situations [6][7][8]12,14,[23][24][25] or issues (e.g., risk management). 26 Tailoring software engineering methods can be classified into one of two approaches -namely, situational method engineering and method configuration 5,27 (some researchers consider method configuration as a particular form of situational method engineering).…”