Responding to change over time: A longitudinal case study on changes in coordination mechanisms in large-scale agile

Entur started working with agile methods from day one and, therefore, never underwent an agile transformation as part of their organizational scaling journey. Since the outset in 2016, the development organization has grown rapidly, from five teams in 2016 to 17 in January 2020, and the growth has continued. Figure 1 displays the team organization in 2018 when we started our fieldwork. Despite being a large-scale agile organization from the outset, Entur has chosen not to adopt any scaling framework (such as SAFe or LeSS). Instead, they use software development best practices and gain inspiration from companies such as Spotify and Google, and tailor any new approach to their specific needs. For example, they established a biweekly tech lead forum modeled from Spotify’s guilds and experimented with using OKRs (used and popularized by Google from around 2016 (Niven and Lamorte 2016)).

The development teams were cross-functional but focused on different parts of the overall deliveries, such as sales, ticketing, pricing, and web and app. Team size and composition varied slightly over time; the largest team had more than 16 members, while the smallest had about five. All teams had a team leader and a product owner, and a tech lead after this role emerged during 2019. All additional team members were developers that in principle could work on any part of their teams’ code through shared repositories and documentation. In addition, a dedicated test team worked with the different teams to ensure appropriate testing of the different parts of the system. Some teams, such as the sales and product teams worked primarily with backend, whereas web and app teams worked with front-end and UX. Because all teams were connected at some level in delivering the overall product, all teams needed to coordinate. However, some teams had more dependencies to other teams than others. For example, almost all other teams had dependencies to the team that wrote the tickets and on-board products, and the UX and web team were dependent on almost all other teams, in that they needed the output of other teams to be ready in order to deliver visual output to travelers using the Entur app. The teams were autonomous in the choice of development methods, and most teams used practices from Scrum and Kanban. As sƒat thiuch, there was a culture of testing new approaches, both within teams and at the inter-team level. At the same time, the need for inter-team coordination and some level of alignment across teams was high as they grew from five to 17 teams. The size and complexity of both the technology and the large-scale organization came with the consequence of many and complex knowledge, technology, and process dependencies. As such, coordination was an ongoing and evolving challenge. More details on the evolution and scaling of the organization and the coordination practices and mechanisms are provided in Section 4.

Observations were conducted on a regular basis, as shown by the short bars in Fig. 2. The first author conducted all observations. Additionally, the third author was present on a few occasions, for example, during the ‘change workshops’. Because we wanted a broad and detailed data material, we observed both meetings and the everyday work at the office. The observation days varied somewhat across the weekdays during the 1.5 years. Our presence varied as we wanted to observe the broad range of inter-team meetings conducted across the week. For example, we could be present one week on Monday and Thursday, the next on a Wednesday, and yet another week we could be absent. For the meeting observations, we observed meetings on all organizational levels, primarily inter-team meetings such as the product owner prioritization meeting and the tech lead forum, and team-level meetings such as team retrospectives and daily stand-up meetings. We were also able to observe client meetings and a board meeting. Because of our ongoing presence, we were able to join in on spontaneous ad hoc meetings as well as planned meetings. We used an observation protocol detailing, for example, the physical setting, people present, and tools and artifacts used. These observations left us with a rich data material with detailed descriptions of the observation setting, including, but not limited to, a focus on the coordination of development activities (see Table 1). The protocol template is included in Appendix 1.

In addition to the field observations, we conducted 37 interviews to gain a deeper understanding of the case. Some interviews were conducted on the same day. Interview days are illustrated by the long bars in Fig. 2. Interviews were held as open conversations in a semi-structured format. We used the same interview guide throughout the data collection (see Appendix 2). The interview guide was slightly modified to focus on the disciplinary area of each role (for example, product owners were asked more about clients and products, whereas architects were asked more about technical architecture). Concerning our focus on change and coordination, the questions remained the same. Example questions include: “What challenges do you see now and in the future in the development program?”, “How has your role changed over time?” and “What do you think have been the biggest developments here in relation to coordination across teams?” We interviewed 25 individuals in total. Six participants, four program managers, and two architects, were interviewed twice. One person, the agile methods specialist, was interviewed six times. These follow-up interviews, held approximately bi-monthly, were more conversational and did not follow the same interview guide as the other interviews. We included these interviews as they contributed to understanding change and coordination over time in the program. The interviews lasted 50 min on average. The first author conducted 29 interviews, the second author conducted two interviews, and the six interviews with the agile method specialist were group interviews conducted by the first, second, and third authors. The first author translated interview quotes from Norwegian to English, and all authors checked the quality of the translation.

During the fieldwork, we were given access to Entur’s internal digital communication tool, Slack, and much of the development process documentation through JIRA and Confluence. The supplemental material allowed us to follow the use of these coordination mechanisms in real-time and record particularly interesting written conversations or documentation pages and provided the ability to search in past conversations and records. For example, we were able to follow in detail the introduction of the new Slack guidelines described in Section 4.3, not only through interviews and observations but also to see the actual implementations in the Slack channels as they took place. In addition to these major sources of information, we collected company presentations, and meeting invitations and agendas sent to us via e-mail.

During these phases, we reviewed the complete data material from the perspective of change, transition, and evolution of the program and its coordination mechanisms over time. Because the data had been used previously for other studies, we already had a collection of existing coordination mechanisms used in the case. The first author re-read the interview transcripts, field notes, meeting observations, and supplementary material and made analytical notes along the way. These were shared and discussed with the rest of the author team. Specifically, the first three authors discussed the opportunity to describe change in coordination over time during the fieldwork. Following this, the first and fourth authors coined the idea to describe and analyse how coordination mechanisms evolved over time during in-person analysis workshops. Following these initial activities, we proceeded to generating initial codes. As illustrated in the left-hand side of Fig. 3, at this stage, we used broad, descriptive codes. For example, a Slack log containing the discussion of the office moving was assigned the code ‘moving offices’. The initial coding phases ended when we had assigned relevant codes to all data items.

During the third phase, we shifted from generating codes to searching for themes. Themes are defined as prevalent patterns within the data, that is, recurring instances of similar types (Braun and Clarke 2006), for example, types of changes that happen outside the organization. We searched for such patterns by grouping and re-grouping the codes from the first and second phases. We identified several lower-level change themes, including changes related to public tenders and clients, changes in the organization of the product, changes in the internal team structures, changes in meeting practices, roles, and tools and artifacts (i.e., coordination mechanisms), changes in the physical location, and much more. Shifting to the fourth phase, we examined the change themes in detail and combined themes that could be grouped under larger themes in light of the data and the definitions of change presented in Section 2 (Jarzabkowski et al. 2012; Langley et al. 2013). We ended up with three high-level change themes, namely external and internal change events and continuous change (see Table 2), as well as changes in coordination mechanisms (see Table 3). Here, we used the categories from the taxonomy of inter-team coordination mechanisms (Berntzen et al. 2022), that is, meetings, roles, and tools and artifacts, but focused this analysis on changes in the mechanisms. The middle part of Fig. 3 provides a simple representation of how we arranged codes into themes.

The final two phases of a thematic analysis tend to intertwine as findings are often put to scrutiny through writing up the final report (Braun and Clarke 2012), which was also the case in our analysis. We selected interview quotes, field note passages, and supplemental material for presentation and related the findings back to the research question. Themes were refined during the writing process as all authors wrote, read, and discussed the material. As illustrated by the right-hand side of Fig. 3, we organized the results using a visual mapping strategy (Langley 1999) (see Fig. 4), which helped us further refine the presentation of our findings. At this point in the analysis, we conducted member checks by providing Entur representatives with the draft to receive their input to ensure that the findings also held practical relevance.

Adding a new client disrupted existing ways of coordinating in that more dependencies was added, and the need for overview across the teams increased. In relation to the onboarding of Client B, new coordination mechanisms were introduced as a response to orienting to the new coordination needs, and new patterns of coordinating were formed by the introduction of new coordination mechanisms. These included a new customer manager role to complement the customer manager of Client A and two artifacts, an inter-team backlog, and an inter-team delivery plan to track which teams worked on what deliveries. The new role and artifacts can be seen in the ‘Coordination mechanisms’ lane at the bottom of Fig. 4, following the lines from the upper lane.

Another important change event occurred in March 2019, when Client A announced that they intended to rebrand, changing their name, logo, and visual appearance. This strategic rebranding was a huge change event for Client A, who had had their previous name for almost two centuries. It also directly impacted Entur, who had to adapt both the old and the new systems, as the old name was hardcoded in the legacy code throughout the old system. During a team leader stand-up meeting in late March 2019, the agile method specialist informed the team leaders of the change: “In a month, Client A’s web pages will close, and a new web page with the new brand will launch. To us, this means that everything that is visible externally needs to be renamed and visually appear as Client A’s new name. […] the teams need to implement changes in the code. For example, the names of all product IDs in the system must be updated.” [Meeting observation, March 2019]. The event is presented in the middle of the ‘external’ and ‘product’ lanes of Fig. 4. This change event illustrates how an uncontrollable external environment had implications for the teams and the system development. While no new coordination mechanisms were added, we observed how existing mechanisms were updated to accommodate the change in coordination needs and the extra work associated with the name change. For instance, we observed that new lanes were added to delivery plans and roadmaps (see Fig. 6 for an example of a physical roadmap) and that the name change was discussed regularly at inter-team stand-up meetings.

A third change event took place in mid-2019, when “Client C” won another public tender, resulting in a change process in late 2019 similar to that of Client B’s entrance. The onboarding of Client C started in early 2020, about at the time when our data collection period ended. Concerning changes in coordination mechanisms, a new customer manager was added to support Client C. Existing inter-team backlogs and delivery plans were updated to make room for incoming requirements and deadlines from Client C, and in January 2020, a workshop was held looking back at lessons learned from onboarding Client B to further adjust practices in preparation for the third major client.

Initially, the software development at Entur was organized in a development project referred to as the Leap Project. This project was directly linked to the political reform and primarily focused on building the new software, which was done in parallel with running services on the old sales system inherited from Client A. However, because of the scope and magnitude of work associated with developing a new sales platform while running and maintaining the old system and because new clients were added, the project was expanded into an ongoing development program with no end date rather than running many different projects. However, while the Leap project officially ended by the end of 2018, traces of the project organization remained for some time as the program members oriented to new ways of coordinating, both in terms of coordination mechanisms and way of thinking. A product owner explained:”We have simplified how and how much the teams report, but all the mechanisms are still there” [I20, Product Owner]. For example, as shown in Fig. 4 and discussed in Section 4.3, the Project Manager role remained until April 2019. This example illustrates that coordination mechanisms are not only created in response to change events and that new patterns of coordinating can include the discontinuation of a mechanism.

In April 2019, a third internal change event occurred when Entur moved offices to a new building. When we began our data collection in August 2018, Entur was located on a single floor in a larger office complex. As they continued to grow, the office space became too small to support the program’s need for inter-team coordination. This was reflected in our observations during 2018. Task boards hung wherever they fitted in, and there were few open spaces for informal meetings and socializing. Stand-up and prioritization meetings took place in corridors and were constantly interrupted by people passing. The meeting rooms were too small for any inter-team meeting and too small for many of the development teams (of which the largest counted 16 members). Moreover, due to the lack of space, several of the development teams had to sit off-site, which was an obstacle to efficient inter-team communication and coordination.

The office move was a big change event that took time and effort, but it was necessary for successful unscheduled coordination and communication across teams as the program continued to scale. “Communication might get better now that all teams are in the same building. Because before, we couldn’t walk over to each other, but now we can” [I13, Team leader]. The new offices spanned two floors, connected by a large open staircase that could be used for informal seating and presentations. They had several large meeting rooms and two large open spaces that allowed for more efficient use of existing coordination mechanisms. For instance, task boards could be displayed in the open space, and inter-team meetings could now be held in well-suited areas (see Figs. 5 and 6 in Section 4.3). Despite this upgrade, the new offices were also at the risk of becoming too small as the program continued to scale. “We just keep growing. We moved to get more space. Now, new desks are constantly being added, and we no longer have a dedicated stand-up room as we need the space for workstations” [I24, Tech lead].

In the large-scale program, teams often worked on the same deliveries or on inter-dependent deliveries. Accordingly, as Entur continued to scale, there was a growing need to align the delivery process across teams. In October 2019, measures were taken to establish an inter-team delivery process with common delivery routines. This was done to improve predictability in deliveries across teams to the clients. However, to keep with an agile way of thinking, these new processes were not implemented overnight but piloted and tested in one central team before scaling further. “We try it out with a smaller group to see ‘do we see the value of doing this?’ We start off narrow, and if people think it gives value, then it is a good model for testing before we go full scale” [I19, Program Architect]. We observed the piloting phase conducted in October-December 2019. As part of this phase, several new coordination mechanisms changed. As seen in the lower right corner of Fig. 4, new coordination mechanisms included a process specialist role and shared routines for using JIRA and Confluence.

Coordination tools are coordination mechanisms that manage dependencies by supporting the development process, for example, a chat tool, while coordination artifacts are considered by-products of the development process, for example, documentation. At Entur, coordination tools and artifacts were used widely, both at the team and inter-team levels. Over time, more inter-team tools and artifacts were added to align inter-team coordination. In the past, the teams had their own backlogs and delivery plans, which the product owners reported on during their prioritization meeting. However, as the program scaled, additional mechanisms were needed. In January 2019, an inter-team backlog was added, and in March, an inter-team delivery plan was put together in response to client growth, as described in Section 4.1. In May/June 2019, Entur started experimenting with OKRs, a goal management framework that Entur used as a coordination tool. They first tested OKRs with the product owners, and as that gave promising results, it was decided to expand the use of OKRs to involve the team leaders, the architects, and the management group. The goal was that all Entur were to use OKRs by 2020. “The goal is to gain an overview and to give insights to the organization. And to be able to say, ‘this is where we’re at,’ right. And use this insight to evaluate if something works or not and act [I21, Program Architect].

In addition to the introduction of new coordination tools and artifacts, existing coordination tools were adjusted as needed. The digital communication tool Slack had been used since the outset in 2016. Slack is built up of channels, which users can create and name within certain boundaries set by the software. Many of the channel names were quite similar. For example, there could be a channel called “ClientA_deliveries” and another called Client_deliveries,” and so forth. By early 2019 the number of channels and various, often similar, names for inter-team and inter-organizational channels became confusing and misleading for Entur employees. This also represented a risk of information being shared with the wrong clients. Accordingly, the need to align communication on Slack resulted in new guidelines for creating and naming Slack channels. During April and May 2019, the new Slack guidelines were introduced. The development teams were encouraged to contribute with input before and during the implementation phase. After the new guidelines were introduced, there was a period of improving the new Slack practices. This example illustrates how the need for more alignment in the coordination process initiated new Slack guidelines, resulting in changes in how the coordination mechanism Slack was used and how the change led to a need to adjust further and improve the use of the coordination mechanism.

Because this study is interpretive, conducted by humans, and involves human participants, the question of credibility can be raised (Guba 1981; Walsham 2002). We used a range of procedures to make our findings as trustworthy and credible as possible. The ethnographic approach ensured a rich and varied data material (Sharp et al. 2016). The first author conducted the main part of the data collection, which was inevitably subject to her own interpretations and understandings of the case. This is explicitly recognized in interpretive studies; however, it is essential to take measures to safeguard the credibility and trustworthiness of the reporting. To this end, we used an observation protocol and interview guides to sort and systematize our data during collection. We later carefully analyzed the data following established analytical methods (i.e., thematic analysis). Moreover, the three other researchers contributed to the triangulation of the interpretations and the reported findings through ongoing discussions during the fieldwork (authors two and three) and throughout the analytical process (all authors). In longitudinal field studies like ours, the researcher and the participants will, over time, get acquainted with one another, which will influence the research process (Walsham 2002; Crang and Cook 2007). For example, it is impossible to ensure that respondents answer interview questions in an unbiased manner. Here, relying on several data sources and many data points was essential to get as nuanced impressions as possible. Data triangulation was ensured by collecting several data sources. The ongoing and iterative discussions among the authors further contribute to the credibility of our findings. Finally, regular member checks with Entur representatives provide additional trustworthiness (Crang and Cook 2007).

The presented results stem from rich process case data (Langley 1999), where the analysis is based on researcher interpretations. We have gone to lengths preventing that we oversimplified our interpretations of the instances and processes described in this study. By following the six phases of thematic analysis (Braun and Clarke 2006, 2012), we have ensured a rigorous analytical process. However, the interpretive research approach makes it difficult for others to repeat the process to confirm our findings, which is not the goal of such approaches (Walsham 2006). Despite this limitation, it is possible to continue this line of study of change, for example, by using existing dependency (Strode 2016) and coordination mechanism (Berntzen et al. 2022) frameworks to analyze the coordination situation and use a visual mapping strategy as we did to map the developments over time. Future research should aim to reproduce and improve the method and analytical procedures in this study, not to directly replicate the findings but to test the confirmability of the research method.

A third limitation relates to the transferability of our findings. This research was conducted within a single organization, and we have focused much on the context-specificity of our case. Other large-scale agile organizations will have a different external and internal context and are, therefore, likely to have a different mix of coordination mechanisms. While we do not claim that our findings are directly transferable to other organizations, the key implications of our findings are likely transferable to other high-complexity large-scale agile settings. Although the emerging theoretical framework needs further development (Eisenhardt and Graebner 2007; Stol and Fitzgerald 2015), the practical insights from our study provide an empirically based approach to analyzing coordination and change that can aid practitioners in managing dependencies in large-scale agile over time. Even though our case organization did not use any of the large-scale agile frameworks, we believe the findings apply also in companies that have implemented SAFe or any of the other frameworks, because Entur can be considered a ‘critical case’ for coordination in large-scale agile software development. According to Flyvbjerg (2006, p. 230), the generalization characteristic of critical cases can be summed up as “If it is valid for this case, it is valid for all (or many) cases.” In its negative form, the generalization would be, “If it is not valid for this case, then it is not valid for any (or only few) cases.” As such, our findings are theoretically generalizable (Crang and Cook 2007) because other large-scale organizations using agile methods are likely to experience similar coordination challenges and use similar agile practices (Edison et al. 2022).