Keywords

1 Introduction

Agile software development methods are increasingly being implemented in larger organizations [1, 2]. More research on large-scale agile ways of working is called for, especially regarding organizational transformation [3, 4]. When transforming an organization into large-scale agile ways of working, roles, routines, practices, and actions are added, changed and adapted. This means that large-scale agile transformations of organizations is more than agile software development. Transformations usually reaches far beyond software development. Often, the purpose of the change is to implement strategic agility in an organization [5]. This entails reducing frictions between autonomous agile teams on one hand and traditional top-down organizational routines with annual planning cycles on the other hand. Since large-scale agile ways of working contains symbols, roles, routines, and actions taken for granted, it could be considered an informal institution [6].

Many organizations choose a predefined large-scale agile framework such as the Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), or the Spotify Model [2]. Implementing a large-scale agile framework implies a transformation of roles and routines. Large-scale agile frameworks come with predefined structures and routines, and implementing them within an existing organizational structure is challenging [7]. In addition, large-scale frameworks often require changing the organizational structures.

There are different ways to implement roles and routines based on a framework. When an agile framework is implemented, there is a tendency to measure agile transformation by adherence to that framework [7]. By using this measurement, the framework becomes the rulebook where as much as possible should be implemented (otherwise, we are not “following the rules”). Another way of implementation is by selecting roles and routines based on the challenges in the organization [8]. In this approach, the framework is seen as a toolbox, where parts of the framework are cherry-picked for the organization. Both of these approaches are common in framework implementations, but the impacts on the organization are not much studied. Therefore, the purpose of this paper is to improve our understanding of how differing institutional logics have an impact on large-scale agile transformations.

2 New Institutional Theory

New institutional theory is a loosely coupled body of knowledge accumulated in several streams of research [9] rather than a coherent theory.

Institutional logics is a concept in sociology and organizational studies which focus on how broader belief systems shape the cognition and behavior of individuals [9]. Rather than physical realities driving human action, institutions are enacted through reproduced patterns of activities by individuals.

Friedland and Alford [10] identified several key institutions such as the nuclear family and bureaucratic state, each guided by a distinct institutional logic. A set of goals, values, and prescriptions associated with a specific institution form an institutional logic. Therefore, to be able to understand both individual and organizational behavior, it must be located in an institutional context which both regularizes behavior and, at the same time, provides an opportunity for agency and change. An institutional logic could be described in several dimensions, or elemental categories, such as with a root metaphor and sources of legitimacy, authority and identity [11].

The concept of software development as an institution is not new, as Rowlands [12] presents in his work. Doležel [13] suggested that the software development institution is driven by two disparate institutional logics: Traditional Software Engineering logic and Agile Software Development logic. Attempts have been made to investigate differing logics within agile software development as an institutional logic. Berente et al. [14] studied three agile software development projects and suggested three different institutional logics based on differing contexts.

Another development of institutional logics in agile software development are two dichotomous logics based on differing views, principles and preferences on implementing a large-scale agile method or framework [15]. These logics can be presented based on the differing dimensions, or elemental categories, as Thornton et al. [11] calls them (see Table 1). Elemental categories specifies organizing principles that shape preferences and interests [11].

Table 1. Institutional logics in large-scale agile transformations [15].
Full size table

One of these logics is called Agile rulebook logic [15]. The logic means that a proper agile method is chosen and implemented in full as described. Šmite et al. [8] calls this the all-or-nothing attitude. The method description becomes a rulebook which guides the organization in how to implement roles, practices and routines. The commitment to the method descriptions becomes the source of authority (see Table 1). The basis of strategy for tailoring according to context is therefore based on which method to choose, rather than to tailor the method itself (see Table 1).

Some advocates of this approach are the originators of Scrum, Schwaber and Beedle [16], who argued that agile methods cannot be applied by cherry picking but must be applied in their entirety to achieve the desired effect.

The other logic is called Agile toolbox logic which means that roles, routines, and practices are selected and tailored based on challenges in the organization. Šmite et al. [8] calls this the à la carte approach. The basis of strategy is to construct a situationally appropriate method out of existing method fragments or innovate based on context needs (see Table 1). The commitment to team decisions on tailoring during transformation becomes the source of authority, rather than method descriptions (see Table 1). Advocates of this logic are, e.g., McBreen [17] and Fitzgerald et al. [18] who argue that parts of the Agile methods can be cherry-picked, ignored or replaced.

3 Research Method

This case study is based on two cases, Case A and Case B, of large-scale agile software development transformations. The case study approach [19] was deemed most suitable for the purpose of the study, as a rich and in-depth understanding of the organizational transformation was sought. Case A is a pilot transformation project where two departments at a large government agency merged into one unit with new roles and routines. The aim of the pilot project was to find out best practices for transforming roles and organizational routines. The next step would then be to use the experience from this transformation to further transform the roles and routines within the whole agency. Case B is a department responsible for the product development of a significant part of a motor vehicle, both the software and the hardware. The department was organized into twenty teams and, after experiencing coordination difficulties between the teams, they decided to start an organizational transformation where new roles and routines were to be implemented.

Semi-structured interviews were the most important source of information but were supplemented with other data collected from participant observations and documents. Several data sources were used for triangulation purposes (see Table 2).

Table 2. Data sources.
Full size table

Data were collected through observations consisted of photos and field notes. These observations were conducted by on-site visits every second or third month and lasted for two to five working days. During these visits, interviews were performed, and memoranda from meetings were studied. In total, 20 interviews were performed with key roles as well as team members who gave insights into multiple perspectives of the transformation (see Table 2).

The analysis followed a two-stage process of inductive and deductive coding of data, building upon the recommendations by Miles, Huberman, and Saldaña [20]. First, all field notes, meeting memoranda and interview transcripts were scrutinized and coded for the first time in an inductive manner. Initial codes were based on evidence of institutional logics at play. Secondly, a deductive coding of data was performed based on the six dimensions of Agile rulebook logic and Agile toolbox logic [15].

4 Findings

In this section, findings from Case A and Case B are presented. In each subsection, experiences of implementation strategies and perceived impacts of the transformation are displayed.

4.1 Case A

In Case A, five SAFe trained agile coaches helped in the transformation during the first one-and-a-half year. The Release Train Engineer [21] explained the view on implementing new methods: “[The agency] always want a uniform way of working, a standardized way in the whole organization” (A2).

Since SAFe was the baseline for all of them, the framework was, more or less, implemented by the book. One developer expressed: “The agile coaches say ‘According to SAFe…’ or the reverse ‘That’s not something that SAFe says’ as an excuse for not making decisions” (A5). Another respondent (A3) claimed that the agile coaches were competing with each other regarding who knew the details of the framework best, rather than discussing possible tailoring or if some things could be discarded.

Financially, Case A used annual budgets and one planning event occurred just before the end of the year. Unfortunately, the annual budget process was delayed and, without a definite budget, managers were not allowed to plan for more than a couple of months into the new year. Still, the decided planning horizon of four sprints was kept, since SAFe describes a planning period of four sprints [21]. This meant that several teams were unable to plan for their final one or two sprints.

Several employees at Case A expressed a negative view towards the implemented roles and practices in the agile transformation. Many expressed that too much time was spent in meetings and that the agile way of working was not tailored to the work process. Employees also expressed limitations to team autonomy since they could not choose how to work as much as they had before the transformation. They also reported stress as a drawback, especially due to added work by following the detailed practices in SAFe forced on them by the agile coaches.

Despite the negative views, respondents expressed a better overview and transparency due to joint planning sessions with other teams as well as improved coordination and cooperation possibilities.

4.2 Case B

At Case B, one manager explicitly stated in an interview that they decided to implement roles, practices and routines suggested by SAFe based on their needs: “Instead of implementing everything in SAFe, we decided to pick and choose practices that would help us” (B1). Therefore, they did not ask consultants specializing in SAFe implementations for help. Instead, they implemented roles and practices on their own.

Practices were added and tailored along the way during the transformation process. PI planning was first implemented as suggested by SAFe, but was constantly tailored to supply the best planning overview to the teams: “You get a much better understanding of the work ahead of you… all [PI] planning focuses on that, to visualize what you need to get done. You get a clear overview of what everyone is doing, and that is a huge advantage” (B4).

A few of the employees expressed that too much time was spent in meetings and that the agile way of working was not entirely tailored to the work process, but not many compared to Case A. Instead, respondents expressed how the new way of working caused an increase in motivation and stress relief for the employees. Also, the new practices of joint planning sessions, PI planning and Scrum of Scrums [21], with several teams improved their planning precision.

Respondents at Case B also expressed a better overview and transparency, as well as improved coordination and cooperation possibilities. They also expressed that, although going through a transformation, there was no real interference on teamwork.

5 Discussion and Conclusion

Paasivaara et al. [22] presented the problems of large-scale agile transformations without the use of an agile framework. However, the study presented in this thesis shows that there are also risks when frameworks are implemented. In particular, there is a risk for suppressing tailoring if the framework becomes the norm by adhering to an Agile rulebook logic. This might be the case when there is too much agile coach support when all coaches are trained in a specific framework, as could be seen at Case A. According to respondents, too much of the discussions between coaches related to whether something was correct according to how it was described in SAFe. In Case A, commitment to method descriptions became the source of authority and method knowledge became the source of identity. Limitations to team autonomy and increased stress were reported impacts, which might be due to the Agile rulebook logic prevailing in Case A.

In Case B, roles, practices and routines were implemented and tailored continuously, piece by piece, along the way. Tailoring was based on the needs of the teams, such as PI planning where overview and transparency was in focus. Attentiveness and responsiveness became the source of identity and commitment to team decisions became the source of Authority. Increase in motivation and stress relief were reported impacts, which might be due to the prevailing Agile toolbox logic in Case B.

This study shows how two dichotomous institutional logics can be used for analytical purposes in large-scale agile transformation studies. The contribution of this paper is to show the possibilities of using two institutional logics for analyzing agile transformations.

There are, however, important limitations to this study. First of all, the study is conducted on a small dataset with only two cases investigated. Further studies on more organizations are necessary to confirm findings presented in this study. Especially, the observed cause-effect relationships between the identified logics and their impacts needs further confirmation. Also, it is important to remember that this is a case study of two organization based on a certain time, place, and the current individuals attending. Categorizing an institutional logic does not mean that a case organization is always anchored in that type [11]. Adherence to logics is fluid and changes over time. The changes may be due to changes in the world, or a result of a strategic decision [11].