Keywords

1 Introduction

Emerging in the 1990s, agile methods have transformed and brought unprecedented changes to software development practice by strongly emphasizing change tolerance, continuous delivery, and customer involvement [1, 2]. With these agile methods, self-organizing teams work closely with business customers in a single-project context, maximizing customer value and quality of delivered software product through rapid iterations and frequent feedback loops [1]. The success of agile methods for small, co-located teams has inspired enterprises to increasingly apply agile practices to large-scale endeavors [2, 3]. Since the initial application of agile methods was originally intended for small, co-located teams, many organizations are uncertain how to introduce them at scale and therefore face new challenges such as inter-team coordination, dependencies to other existing environments or distribution of work without a defined architecture [1, 4, 5]. The latter is also the reason why large-scale agile development has been subject to criticism since it neglects detailed assistance on software architecting [2, 6]. Agile methods assume that architecture should evolve incrementally rather than being imposed by some direct structuring force (emergent architecture) [7]. However, the practice of this design is effective at team level but insufficient at large-scale. It causes excessive redesign efforts, architectural divergence, and functional redundancy increasing a system’s complexity [7, 8]. Therefore, an intentional architecture is required, which embraces architectural guidelines that specify inter-team design and implementation synchronization [7, 9]. The effective evolution of a system’s architecture requires the right balance of emergent and intentional architecture and a close collaboration between architects and agile teams [7, 9, 10].

Literature describing the collaboration between architects and agile teams in large-scale agile development is still scarce. This paper aims to fill this gap by providing a case study of a German consumer electronics retailer’s large-scale agile development program. Based on this objective, our research question is:

  • How does the collaboration take place between architects and agile teams in a large-scale agile development program?

The remainder of this paper is structured as follows. In Sect. 2, we provide an overview of foundations and related works. In Sect. 3, we present the research approach of this paper. Section 4 describes the case study on the collaboration between architects and agile teams in the large-scale agile development program. We discuss our lessons learned in Sect. 5 before concluding the paper with a summary of our results and remarks on future research in Sect. 6.

2 Background and Related Work

In the following, the Scaled Agile Framework and Spotify Model are introduced, as the observed program has adopted these two scaling frameworks. Thereafter, the concept of communication networks is presented, which is essential for interpreting the results of the social network analysis in Sect. 4.

2.1 Scaled Agile Framework

The Scaled Agile Framework (SAFe), a widely used scaling framework [11], was first published by Dean Leffingwell in 2011. SAFe builds on existing lean and agile principles that are combined into a method for large-scale agile projects. It provides a soft introduction to the agile world as it specifies many structured patterns. This introduction is needed for organizations moving from traditional to agile development environment [7]. The latest SAFe 4.6 version supports four out-of-the-box configurations: Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe. As the observed program uses Essential SAFe, we will subsequently focus on this. Essential SAFe is the simplest entry point for implementing SAFe and consists of team and program levels [7]. At team level, the techniques outlined are those used in Scrum. Each team consists of five to nine members, one scrum master (SM), and one product owner (PO). All teams are part of an agile release train (ART), a team of agile teams that delivers a continuous flow of incremental releases. Each team is responsible for defining, building, and testing stories from its team backlog in a series of two-week iterations using common iteration cadences [7]. At program level, the product management (PM) serves as the content authority for the ART and is accountable for identifying program backlog priorities. The PM works with POs to optimize feature delivery and direct their work at team level. A release train engineer (RTE) facilitates program execution, escalates impediments, manages risk, and helps to drive continuous improvement [7]. The system architect has the technical responsibility for the overall architectural design of the system and aligns the ART with the common technical and architectural vision [7].

2.2 Spotify Model

In 2012, Kniberg and Ivarsson [12] published Spotify’s approach to scale agile methods over 30 teams across three cities. The Spotify Model emphasizes the importance of “aligned autonomy”, i.e. the autonomy of agile teams with simultaneous collaboration and coordination to achieve the same goals. The basic unit of development is called a Squad, which is similar to an agile team in SAFe. Squads are self-organizing and autonomous teams that have all the skills to design, develop, test, and release for production. A Tribe is designed as a collection of squads working in related areas (correspondents to an ART in SAFe). Squads within a tribe are co-located. People with similar skills in the same competency area within the same tribe form a Chapter. A Guild is a community of people that share same interests and often includes all chapters working in this area (complies with a community of practice in SAFe) [12].

Fig. 1.
figure 1

Common communication networks [15]

Full size image

2.3 Communication Networks

According to Guo and Sanchez [13], communication is understood as the creation or exchange of thoughts, ideas, and emotions between senders and receivers. Communication can be decomposed into two types: inter-team and intra-team communication. The former stands for communication between several teams, the latter for communication within a team [14]. The flow of communication connecting senders and receivers are called communication networks [15]. Figure 1 depicts five common communication networks. The wheel network is the most centralized network pattern. In this network, each member communicates with only one other person. The superintendent C receives all the information from his subordinates A, B, D, and E and sends back information, usually in the form of decisions. The chain network is the second highest in centralization. Only two people communicate with each other, and they have only one other person to communicate with. The Y network is similar to the chain network except that two members are out of the chain. In the Y network, members A and B can send information to C but they cannot receive information from anyone else. Members C and D can exchange information. Member E can exchange information with member D. The circle network stands for horizontal and decentralized communication, which offers equal communication possibilities for every member. Each can communicate with one other to his right and left. Members have identical restrictions but the circle is a less restricted condition than the wheel, chain, or Y network. The all-channel network is an extension of the circle network and connects everyone in the circle network, as it permits each member to communicate freely with all other persons [15].

2.4 Agile Architecture

Angelov et al. [16] describe the role of architects and challenges they face in Scrum such as insufficient collaboration, lack of understanding of the value of architecture, and poor communication between team architects [16]. Bachmann et al. [17] and Nord et al. [18] present four tactics to achieve agility at scale by aligning the system architecture, organization structures and product infrastructures. These include vertical and horizontal system decomposition, matrix and augmented team structures, architecture and infrastructure runway, and deployability tactics and can be used in different phases in a system’s life cycles. Uludağ et al. [10] describes how the adoption of domain-driven design supported a large-scale agile development program with three agile teams at a large insurance company. Uludağ et al. [10] report that agile teams and project managers involved in the program conceived that without any form of architectural guidance, large-scale agile development programs can hardly be successful. Dingsøyr et al. [19] investigated a large-scale development program with an extensive use of Scrum and a focus on customer involvement, inter-team coordination, and software architecture. Two key findings related to software architecture are the tension between up-front and emergent architecture and the demanding role of architects in large-scale agile development.

3 Case Study Design

A case study is a suitable research methodology for this paper, since it helps to study contemporary phenomena in a real life context [20]. We followed the guidelines described by Runeson and Höst [20].

Case Study Design: The main objective of this paper is to investigate the collaboration between architects and agile teams in large-scale agile development in terms of architecture sharing. Based on this objective, we defined one research question (see Sect. 1). The study is a an exploratory single case study, since this paper looks into an unexplored phenomenon and aims to seek new insights and generate ideas for future research [20]. The case was purposefully selected, because the studied company has successfully adopted SAFe for building complex software for the last one and a half years. The unit of analysis is the consumer electronics retailer’s large-scale agile development program.

Data Collection: We used a mixed methods approach with three levels of data collection techniques [21]. As direct methods, we observed two Program Increment (PI) Planning events [7] with low degree of interaction by the researcher and low awareness of being observed [20]. These observations provided a deep understanding of the overall structure. With the help of seven semi-structured interviews, roles and practices related to architecture were identified and documented. Quantitative data was collected by the online-survey tool Questback for building the social networks and revealing the collaboration between architects and agile teams (see Sect. 4). Therein, we asked respondents how often they exchange architectural advice and decisions with their colleagues, how often they see their colleagues, and if they have suggestions on how to improve the exchange among team members (using a Likert scale). A total of 32 out of 62 available people from eight teams took part in the survey. Three persons were removed from the analysis because no clear assignment to these persons could be made. The response rate for the remaining 29 program members from eight teams is 47% with 758 connections for architecture sharing.

Data Analysis: Interviews and observation protocols were coded using a deductive approach as proposed by Cruzes and Dybå [22]. Qualitative data collected in interviews form the theoretical foundation for interpreting social relations between architects and agile teams. After initial coding, codes were refined and consolidated by merging related ones and removing duplicates. Quantitative data was analyzed through the use of social network analysis, which comprises a set of methodological techniques that aim to describe and explore patterns in relationships that individuals and groups form with each other [23].

4 Results

4.1 Case Description

In 2016, the case organization decided to relaunch a failed CRM project using agile methods. Due to the complexity of the project, the management decided to relaunch it with the help of a scaling framework. During early stages of research, the reasons for using Essential SAFe (from now on SAFe) became more apparent and convincing to the management. One reason for choosing SAFe was that it has proven itself in large organizations and offers comprehensive documentation. The adoption was initiated with a pilot project, which was geographically distributed. At the beginning, the pilot project faced a lot of problems. Thus, all involved employees were trained upon agile methods and SAFe by external agile coaches. After a few PIs, the responsible management team perceived that SAFe did not provide sufficient guidance on the coordination of their agile teams. Thus, the organization decided to combine SAFe with the Spotify Model. Within the transformation process, program members were divided into tribes, chapters, squads, and guilds. Figure 2 shows the current organizational structure of the observed program. Figure 2 also shows all 62 members forming a tribe. This tribe consists of a “scaled” team (Team A), which does not play a hierarchical superior, but a more coordinating role without personnel management, and four squads (Team B, Team C, Team D, and Team E). Team F, Team G, and Team H, which are not shown in Fig. 2 constitute representatives of three suppliers that provide external support for their third-party systems. The tribe is divided horizontally into nine chapters for: (1) the chief product owner (CPO) and POs, (2) RTE and SMs, (3) IT project managers (IT-PMs), (4) quality analysts and test managers (QAs & TMs), (5) data analysts (DAs), (6) solution architects (SAs)Footnote 1, (7) business process architects (BPAs), (8) product reliability engineers (PRE), and (9) developers (Devs). Each SA is assigned to a squad and takes care of the overall system architecture with its subsystems and interfaces. The team concentrates on the cross-system data flows and processes related to the integration of the architecture. These data flows and processes are used to define minimum interface requirements that all teams must meet. In contrast to SAs, who represent technical architects, BPAs are functional architects that are also dedicated to squads. The responsibilities of BPAs are not really known yet, as their role has been added to the program just recently. However, both architect roles should play a dual role within their squads by making architectural decisions and guiding them to fulfill the required architectural standards. Due to ongoing transformation, guilds have not yet been established but will be organized soon. In the following two sections, the inter- and intra-team exchange of architecture-related information of the observed program will be presented.

Fig. 2.
figure 2

Organizational structure of the observed large-scale agile development program

Full size image
Fig. 3.
figure 3

Social network of eight teams including salient roles that are intensively involved in inter- and intra-team architecture-sharing

Full size image

4.2 Inter-Team Architecture Sharing

Figure 3 provides an overview of how architecture-related information is shared across all teams. An interesting finding here is that the scaled team is located in the center of the graph. This indicates continuous communication and coordination between the scaled team and the four squads on architectural topics. Figure 3 also shows a close collaboration between Team B and Team E and between Team B and Team D, which is due to architectural dependencies between the systems on which they work. Figure 3 also provides an overview of roles that are intensively involved (large nodes) in architecture sharing. First, it shows that the CPO of Team A (CPO\(_\mathrm{A}\)) is the most outstanding node in the inter- and intra-team exchange of architecture-related information. Second, SAs also form relatively large nodes compared to other roles. This observation confirms the importance of SAs for the exchange of inter- and intra-team architectural information. Figure 3 also shows that the TM\(_\mathrm{A}\) also plays an important role in architecture sharing. Table 1 presents top 10 stakeholders involved in inter-team sharing based on the normalized degree centralityFootnote 2 measure. Table 1 shows that the CPO\(_\mathrm{A}\) has a normalized degree centrality value of 1,0, which indicates that he/she is sharing information with all stakeholders involved in the observed program. The SA\(_\mathrm{E}\) and SA\(_\mathrm{D}\) have normalized degree centrality values of 0,92 and 0,90 indicating high involvement in inter-team sharing.

Table 1. Top 10 stakeholders involved in inter-team architecture sharing based on normalized degree centrality
Full size table

The PI planning event of SAFe is a face-to-face event [7] that aims to align all agile teams within the ART to share the common mission and vision by creating iteration plans and team objectives for the upcoming PI. It is conducted every two and a half months and offers a platform for the exchange of general and architectural information across teams, since all members of the ART are present in one location. Figure 4(a) shows that SAs and BPAs have a very strong sharing with other teams during the PI planning. Figure 4(d) reveals a chain communication between the \(\mathrm{SA}_{B}\), SA\(_\mathrm{C}\), SA\(_\mathrm{D}\), and SA\(_\mathrm{E}\) on a daily basis. In particular, the chain is composed as follows: SA\(_\mathrm{E}\) exchanges information with SA\(_\mathrm{B}\), who exchanges information with SA\(_\mathrm{D}\), who shares information with SA\(_\mathrm{C}\). This communication pattern characterizes a centralized communication between SAs. The chain communication pattern can also be observed with SA\(_\mathrm{B}\), SA\(_\mathrm{D}\), and SA\(_\mathrm{E}\). Figure 4(e) shows that SA\(_\mathrm{B}\), SA\(_\mathrm{D}\), and SA\(_\mathrm{E}\) constantlyFootnote 3 exchange information and that the SA\(_\mathrm{C}\) is no longer involved in an exchange with other SAs. Figure 4 shows that SAs form a decentralized all-channel communication pattern. This means that each SA speaks with all other SAs. The overall comparison also shows that the three external SA of Team B are less participating in the inter-team exchange than the rest of internal SAs involved in the program. Other roles such as SM, TM, PO, and CPO are also heavily involved in exchange of information within the PI planning. The shorter the observed time intervals become, the more dominant the SA becomes with regards to the inter-team sharing.

Fig. 4.
figure 4

Social networks focusing on SAs and BPAs with regards to the frequency of inter- and intra-team architecture sharing

Full size image
Fig. 5.
figure 5

Social network of the four squads focusing on SAs and BPAs involved in intra-team architecture-sharing

Full size image

4.3 Intra-Team Architecture Sharing

The exchange of architectural information in Team B shows a central wheel communication pattern between SAs, since external SAs are guided by the internal SA, who represents the intra-team lead architect (see Fig. 5(a)). Figure 5(a) also shows that SAs form the core of the team. Moreover, Fig. 5(a) shows that BPA\(_\mathrm{B}\) only exchanges information with another role. A decentralized all-channel communication pattern can be observed in Team C (see Fig. 5(b)). This means that other non-architectural roles exchange information without necessarily involving SA\(_\mathrm{C}\). Nevertheless, SA\(_\mathrm{C}\) plays the most central role, since the SA frequently communicates with all team members. Compared to BPA\(_\mathrm{B}\), BPA\(_\mathrm{C}\) plays a more central role, as he/she shows a close collaboration and communication with his/her squad (see Fig. 5(a) and (b)). The comparison of the two figures also shows that

Table 2. Normalized degree centralities of architects in intra-team architecture sharing
Full size table
Fig. 6.
figure 6

Social network of Team B focusing on SAs and BPAs with regards to the frequency of intra-team architecture sharing

Full size image

SA\(_\mathrm{C}\) and BPA\(_\mathrm{C}\) exchange information more frequently than SA\(_\mathrm{B}\) and BPA\(_\mathrm{B}\). Figure 5(b) shows a decentralized all-channel communication pattern between architects and other team members of Team D. Similar to BPA\(_\mathrm{C}\), BPA\(_\mathrm{D}\) often exchanges architecture information with team members. Table 2 shows the normalized degree centrality values of SAs and BPAs involved in intra-team architecture sharing. 75% of the SAs possess a normalized degree centrality value of 1,0 indicating that they share information with all squad members. Comparing SAs with BPAs, Table 2 shows that SAs have a stronger exchange of information with their squad members than BPAs (except Team E).

Fig. 7.
figure 7

Social network of Team C focusing on SAs and BPAs with regards to the frequency of intra-team architecture sharing

Full size image
Fig. 8.
figure 8

Social network of Team D focusing on SAs and BPAs with regards to the frequency of intra-team architecture sharing

Full size image
Fig. 9.
figure 9

Social network of Team E focusing on SAs and BPAs with regards to the frequency of intra-team architecture sharing

Full size image

Figure 6 shows how Team B’s intra-team sharing changes at four distinct time intervals. For instance, Fig. 6(a) shows that BPA\(_\mathrm{B}\) only exchanges information with one Dev\(_\mathrm{B}\) once per iteration. Figure 6(b) shows that the exchange of information between SAs and non-architectural roles mostly takes place two to three times per iteration, while the sharing between SAs takes place constantly (see Fig. 6(d)). Similar to Figs. 6, 7 shows Team C’s intra-team architecture sharing. The exchange in the team usually takes place two to three times per iteration (see Fig. 7(c)). Sharing between architects and non-architectural roles takes place on a daily basis (see Fig. 7(d)). In contrast to Team B, Fig. 7(e) shows that SA\(_\mathrm{C}\) and BPA\(_\mathrm{C}\) constantly communicate together. Figure 8(a) shows that the exchange between architects and non-architectural roles as well as among architects mainly takes place on a daily basis. SA\(_\mathrm{D}\) and BPA\(_\mathrm{D}\) constantly exchange architectural information (see Fig. 8(b)). Figure 8(b) also shows that other members such as DA\(_\mathrm{D}\), QA & TM\(_\mathrm{D}\), PRE\(_\mathrm{D}\), and PO\(_\mathrm{D}\) constantly exchange architectural information. The intra-team exchange of Team E takes place mainly on a daily basis (see Fig. 9(a)). SA\(_\mathrm{E}\) and BPA\(_\mathrm{E}\) communicate on a daily basis (see Fig. 9(b)). Architecture sharing between architects and non-architectural roles takes place on a daily basis. Figure 9(b) shows that two groups are formed during the constant exchange of information. The first group includes SA\(_\mathrm{E}\), SM\(_\mathrm{E}\), Dev\(_\mathrm{E}\), and PO\(_\mathrm{E}\), while the second group constitutes Dev\(_\mathrm{E}\), BPA\(_\mathrm{E}\), and PRE\(_\mathrm{E}\). Table 3 provides a summary of the social network analysis with identified communication patterns and frequencies.

5 Discussion

5.1 Key Findings

Both architectural roles, i.e. SAs and BPAs, and other roles, e.g. TMs, SMs, and POs, are involved in inter- and intra-team architecture sharing. In particular, the CPO plays one of the most salient roles. An all-channel communication network can be observed in each squad. SAs enable a decentralized exchange so that other team members can exchange architecture-relevant information without necessarily involving SAs. This observation coincides with the values and principles of agile software development. Both SAs and BPAs prefer face-to-face communication with their team members and do not exchange information by including bridging roles. Each squad is accompanied by at least one SA and BPA. Both architects play a dual role in their squads. On the one hand, they make architectural decisions and iteratively create architecture models. On the other hand, they provide guidance and support their squad in meeting architectural standards. With this setup, the observed program aims to increase development speed by balancing emergent and intentional architecture. In all social networks, SAs form central nodes in inter- and intra-team sharing.

Table 3. Summary of the social network analysis
Full size table

5.2 Threats to Validity

We discuss potential threats to validity along with an assessment scheme as recommended by Runeson and Höst [20].

Construct Validity: This aspect reflects to what extent operational measures that are studied really represent what the researcher has in mind [20]. Two countermeasures were taken for construct validity. First, interview protocols were coded by the author of this paper and reviewed by a second researcher. Second, a key informant of the organization has reviewed the analyses of this paper.

Internal Validity is irrelevant, as this study was neither explanatory nor causal.

External Validity: This aspect of validity concerns to what extent the findings can be generalized, and to what extent the findings are of interest to other persons outside the case under investigation [20]. This paper focuses on analytical generalization [20] by providing a detailed description of the case. It provides empirical insights that allow for a profound understanding on the collaboration between architects and agile teams. The shown findings should be viewed as valuable insights for other organizations that adopted Essential SAFe.

Reliability: This validity is concerned with to what extent the data and the analysis are dependent on the specific researcher [20]. To mitigate this threat, two countermeasures were taken. First, the case study has been designed so that the large number of interviewees and multiple interviewers allowed data and observer triangulation. Second, a case study database was created, which includes case study documents such as audio recordings protocols, and field notes of observations.

6 Conclusion and Future Work

In this paper, we described the collaboration between architects and agile teams in a large-scale agile development program of a German consumer electronics retailer. Due to the complexity and extent of the CRM product, each squad is guided and supported by at least one SA and BPA. Each SA is responsible for the architecture of a subsystem and ensures that the respective squad complies with defined architectural requirements. The observed program also introduced the new role of the BPA that is responsible for developing the functional architecture of the subsystem. To understand the role of SAs and BPAs and their collaboration with squads, we investigated social networks of one scaled team and four squads. We learned that intra-team architecture sharing is usually facilitated by SAs. Comparing the social networks with common communication networks, we discovered that SAs and BPAs prefer direct communication. For the most part, architects share information on a daily basis with their teams. The intra-team sharing between architects and their teams is characterized by an all-channel communication network.

As future work, we will continue to study the large-scale agile development program of the German consumer electronics retailer. First, we will research how the current state of architecture sharing is perceived by the stakeholders and how it could be improved by the use of various coordination mechanisms such as ad hoc meetings, co-location or communities of practices. Second, as the squads in the large-scale agile development program become more mature and evolve towards feature teams, we will investigate the architectural decision-making process of squads. We hope to gain a better understanding of the collaboration between architects and squads regarding the distribution of their responsibilities for architectural issues.