Abstract
Transforming into agile ways of working in large organizations can be performed in different ways. Many organizations choose a defined large-scale agile software development framework but how the transformation is carried out could be based on different sorts of logics. This paper investigates institutional logics at play in large-scale agile transformations. By studying two case organizations, the paper aims at improving our understanding of large-scale transformations by viewing software development as an institution. The findings displays diverse impacts due to two differing institutional logics when transforming into large-scale agile software development by implementing the Scaled Agile Framework. One contribution of this paper is to show the possibilities of using two institutional logics, Agile toolbox logic and Agile rulebook logic, for analyzing impacts of agile transformations.
You have full access to this open access chapter, Download conference paper PDF
Similar content being viewed by others
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].
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).
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].
References
Laanti, M., Kettunen, P.: SAFe adoptions in Finland: a survey research. In: Hoda, R. (ed.) XP 2019. LNBIP, vol. 364, pp. 81–87. Springer, Cham (2019). https://doi.org/10.1007/978-3-030-30126-2_10
VersionOne. 14th annual “State of Agile Development” survey. http://www.versionone.com. Accessed 05 May 2021
Barroca, L., Dingsøyr, T., Mikalsen, M.: Agile transformation: a summary and research agenda from the first international workshop. In: Hoda, R. (ed.) XP 2019. LNBIP, vol. 364, pp. 3–9. Springer, Cham (2019). https://doi.org/10.1007/978-3-030-30126-2_1
Moe, N.B., Holmström Olsson, H., Dingsøyr, T.: Trends in large-scale agile development: a summary of the 4th workshop at XP2016. In: XP 2016 Workshops: Scientific Workshop Proceedings of XP2016 (Article 1). ACM (2016)
Denning, S.: Strategic agility, using agile teams to explore opportunities for market-creating innovation. Strategy Leadersh. 45(3), 3–9 (2017)
North, D.: Institutions, Institutional Change and Economic Performance. Cambridge University Press, Cambridge (1990)
Conboy, K., Carroll, N.: Implementing large-scale agile frameworks: challenges and recommendations. IEEE Softw. 36(2), 44–50 (2019)
Šmite, D., Moe, N.B., Ågerfalk, P.J. (eds.): Agility across time and space: implementing agile methods in global software projects. Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-12442-6
Thornton, P.H., Ocasio, W.: Institutional logics. In: Greenwood, R., Oliver, C., Sahlin, K., Suddaby, R.: The Sage Handbook of Organizational Institutionalism, pp. 99–128. SAGE Publications, Thousand Oaks (2008)
Friedland, R., Alford, R.R.: Bringing society back in: symbols, practices and institutional contradictions. In: Powell, W.W., DiMaggio, P. (eds.) The New Institutionalism in Organizational Analysis, pp. 232–263. University of Chicago Press, Chicago (1991)
Thornton, P.H., Ocasio, W., Lounsbury, M.: The Institutional Logics Perspective: A New Approach to Culture, Structure, and Process. Oxford University Press, Oxford (2012)
Rowlands, B.: Institutional aspects of systems development. In: Mills, A., Huff, S. (eds.) Proceedings of the 19th Australasian Conference on Information Systems, ACIS 2008, pp. 55–65. University of Canterbury (2008)
Doležel, M.: Possibilities of applying institutional theory in the study of hybrid software development concepts and practices. In: Kuhrmann, M., et al. (eds.) PROFES 2018. LNCS, vol. 11271, pp. 441–448. Springer, Cham (2018). https://doi.org/10.1007/978-3-030-03673-7_35
Berente, N., Hansen, S.W., Rosenkranz, C.: Rule formation and change in information systems development: how institutional logics shape ISD practices and processes. In: Bui, T.X., Sprague Jr., R.H. (eds.) Proceedings of the 48th Annual Hawaii International Conference on System Sciences, pp. 5104–5113. IEEE (2015)
Gustavsson, T.: Inter-team coordination in large-scale agile software development projects, Doctoral dissertation, Karlstad University, Karlstad (2020)
Schwaber, K., Beedle, M.: Agile Software Development with Scrum. Prentice Hall, Upper Saddle River (2002)
McBreen, P.: Questioning Extreme Programming. Addison-Wesley, Boston (2003)
Fitzgerald, B., Hartnett, G., Conboy, K.: Customising agile methods to software practices at Intel Shannon. Eur. J. Inf. Syst. 15(2), 200–213 (2006)
Yin, R.K.: Case Study Research and Applications: Design and Methods, 6th edn. SAGE Publications, California (2017)
Miles, M.B., Huberman, A.M., Saldaña, J.: Qualitative Data Analysis: A Methods Sourcebook, 3rd edn. SAGE Publications, California (2014)
Scaled Agile Inc.: Scaled Agile Framework 5.0. http://www.scaledagileframework.org. Accessed 06 June 2021
Paasivaara, M., Behm, B., Lassenius, C., Hallikainen, M.: Large-scale agile transformation at Ericsson: a case study. Empir. Softw. Eng. 23(5), 2550–2596 (2018). https://doi.org/10.1007/s10664-017-9555-8
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
Rights and permissions
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Copyright information
© 2021 The Author(s)
About this paper
Cite this paper
Gustavsson, T. (2021). Institutional Logics in Large-Scale Agile Software Development Transformations. In: Gregory, P., Kruchten, P. (eds) Agile Processes in Software Engineering and Extreme Programming – Workshops. XP 2021. Lecture Notes in Business Information Processing, vol 426. Springer, Cham. https://doi.org/10.1007/978-3-030-88583-0_2
Download citation
DOI: https://doi.org/10.1007/978-3-030-88583-0_2
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-030-88582-3
Online ISBN: 978-3-030-88583-0
eBook Packages: Computer ScienceComputer Science (R0)