Abstract
While agile represents a crucial element of digital transformation, there is limited empirical evidence on how agile is actually implemented. This article presents a longitudinal case study of the agile implementation journey of a large product manufacturer over two years. It shows how the firm was able to achieve a large-scale agile implementation through a mix of top-down and bottom-up approaches. This process entailed continuous adaptations of agile to the firm’s circumstances and needs, including ongoing articulations and re-articulations of agile to incorporate local ideas and address emerging challenges. This article also presents a framework for guiding managers undertaking an organization-wide agile implementation.
When agile is used as an engine for spurring digital transformation, it takes on a different role than just being a project management methodology. It becomes a cultural change agent. Agile—with principles of experimentation, risk taking, speed, and responsiveness to change—stands in stark contrast to strict processes, rules, traditional structures, and project management practices that are typical of large organizations. As companies seek to implement agile approaches, these approaches clash with organizations’ existing traditions. In fact, most well-established product manufacturers are better designed for efficiency than for agility. 3
This article investigates how agile is implemented in the context of digital transformation and what challenges this implementation entails. 4 So far, there are contraposing perspectives on how agile should be implemented, and one of the questions to consider is whether organizations should apply a top-down or a bottom-up approach. Some studies argue that organizations must combine both approaches for a better agile transformation. 5 This entails applying formal rules and procedures to provide a common direction for agile implementation (top-down), while at the same time allowing freedom in how agile is implemented at the team level (bottom-up). However, the idea is paradoxical, and we still know very little about how this may be done in practice. 6
We examine “up close” how a world-leading product manufacturer embarked on its digital transformation via the implementation of agile methodologies. We conducted a longitudinal study where we followed the implementation, use, and consequences of agile for two years. We show how the firm was able to achieve a large-scale agile implementation through a mix of top-down and bottom-up approaches. This process entailed continuous adaptations of agile to the firm’s circumstances and needs, including ongoing articulations and re-articulations of agile to incorporate numerous local ideas and to address emerging challenges.
We present a framework for managers planning to undertake an organization-wide agile implementation. The framework indicates the importance for managers of viewing an organization-wide agile implementation as an ongoing process of adaptation, undertaking a stepwise transformation, enabling effective intra- and inter-team processes, and managing the interplay between agile and digital transformation. Organizations should refrain from implementing agile methodologies as is. Rather, an approach that is experimental and adaptive provides the organizational members with the needed time to adapt to change and a greater sense of ownership, thereby obtaining a more organic and sustainable implementation of agile over time.
An Integrated Framework of Perspectives on Agile
Agile development is a high-speed approach that involves iterative processes and user involvement. 7 While agile methodologies were introduced in software development around 2000, agile has become an organization-wide movement where firms are striving for excellence in business agility as they seek to adapt to the fast-changing business environment. While there seems to be a general consensus that agile is a means to achieve more adaptable and flexible organizations, there is a lack of understanding of what agile means and how firms transform for agility. 8 This confusion is the result of a disconnect between two dominant perspectives within agile: the agile-as-methodology view (AMV) and the business agility view (BAV). The two views have developed separately without interaction or consideration.
Agile-as-Methodology View
The focus of AMV has been to understand how agile methodologies are implemented to manage projects. Agile methodologies are by nature paradoxical: on the one hand, they break away from previous methodologies characterized by rigidity and planned approaches and instead advocate adaptation, flexibility, and change. 9 On the other hand, they dictate strict and fixed rules, procedures, and artifacts for how to manage a certain activity. Many organizations adopt agile with an ad hoc mix of methodologies; 10 however, Scrum is the most commonly known approach. Scrum is a project management framework, typically applied in system development that emphasizes teamwork, accountability, and iterative progress toward a well-defined goal. Scrum does not have a traditional project manager but instead includes roles such as Product Owner (a liaison between the development team and its customers and responsible for ensuring that expectations are communicated and agreed upon), Scrum Master (a project facilitator with leadership skills, who ensures that the team follows the Scrum best practices), and the Development Team (a team that works together to create and test incremental releases). The AMV literature has delved into how organizations have translated standardized approaches to agile into organization-specific approaches that take into consideration firms’ circumstances. Examples of such adaptations are the appointment of an innovation manager to engage with agile team members, 11 adaptations of characteristics of the team in distributed development, 12 the development of contextual ambidexterity, 13 or the reduction of the number of daily stand-up meetings and team reports. 14 Similarly, some literature has focused on how agile may be combined with existing product development methodologies (such as stage-gate) and form new hybrid models to reach more rapid development. 15
While Scrum is predominantly a team-centered methodology, SAFe and other new methodologies have emerged to address the issues of alignment and scalability across teams. 16 SAFe addresses these issues not just by scaling up some of the existing agile practices, but also by introducing new practices and concepts—for example, agile release train, levels, and value stream. 17 SAFe seeks to adapt agile principles to the context of large-scale developments. In this sense, it is another example of adaptation to firms’ circumstances. Since digital transformation implies intensified coordination and scaling of solutions, SAFe has become a popular approach in organizations on a digital journey. Nevertheless, research has also highlighted the challenges with this methodology—for example, that it is bureaucratic and complex. 18
Business Agility View
More recently, another stream of literature has addressed the use of agile principles to create organization-wide (digital) transformation. 19 Here agile is discussed as a method for transforming entire organizations. This literature examines why and how agile can accelerate and facilitate digital change and has investigated issues related to, for example, leadership behaviors appropriate for the agile organization, the creation of a digital mindset, 20 the attainment of alignment between business and IT strategy, 21 and the discovery of new suitable organizational routines. 22 It is assumed that agile represents a specific approach based on specific principles, which should be implemented “as-is.” 23 From this perspective, agile principles are universal, and organizations must adapt to fit them.
Thus, the two views differ. The AMV sees the implementation of agile as a process of translation and adaptation to the given organizational circumstances. The BAV tends to ignore such contextual adaptation. In BAV, agile is assumed to be a silver bullet for accelerated change, and the implementation of agile is, therefore, a matter of adapting the organization to agile prescriptions.
A Translation Theory Perspective on Business Agility
This difference between the two perspectives is problematic because executives following the recommendations of the BAV are likely to view an agile transformation process as a planned endeavor, with one right approach. Any adaptation of agile principles that emerge from experiences gained in the process will be considered as “rookie mistakes,” an organization’s incompetence in implementing agile, and ultimately a sign of failure to manage the transformation. Because agile principles are fundamentally different from organizations’ traditional practices and mindsets, an agile transformation is an extremely complex endeavor that is unlikely to follow a predetermined path. Instead, we argue that such transformation will inevitably be bumpy, that contextual factors have to be taken into consideration, and that adaptations to agile rules have to be made. In this study, we bridge the two perspectives and argue that organization-level transformation initiatives cannot be separated from how agile methodologies are implemented at the team and project levels.
Translation theory is useful to understand agile implementation in relation to organizational transformation. This theory is based on the notion that general management ideas change as they “travel” from one context to another. 24 When implementing agile, the articulation of methodologies goes through a translation process (via narratives and practices) to be re-articulated to fit into a given organizational context. 25 That is, agile methodologies become unpacked and transformed into organization-specific “versions” as a variety of translators (actors) across levels of the organization continuously enact and re-enact agile, and integrate emerging local ideas in the methodology in order to adapt it to their specific needs. Therefore, translation theory does not recognize the independent existence of universal ideas as distinct from local ideas. 26 Rather, it regards the implementation of a global idea (such as an agile methodology) as a process of interconnecting local ideas to a global idea. 27 In this article, we apply a translation theory lens to understand how agile is implemented as an engine for digital transformation.
Agile Implementation in the Context of Digital Transformation
We conducted a longitudinal case study where we followed the implementation of agile Scrum as part of the firm’s digital transformation journey. The firm is a major product manufacturer and a world leader in the water utility industry operating in 56 countries (labeled Atlas for confidentiality reasons). It employs globally more than 20,000 employees and has a long tradition of innovation and development of advanced engineering and technological hardware. Atlas is structured as a matrix organization, with market knowledge and customer insights on one axis, and the longer-term business development activities on the other. The global organization consists of a mix of sales and production companies, and business development and business support functions.
Atlas started its digital transformation journey in 2017 to move from being a traditional product manufacturer to becoming a digital service provider. The digital transformation related to the overall business strategy was approved by the board of directors in 2015, where digitalization was highlighted as a focus area for future company growth. This was due to the intense competition faced by Atlas in the water industry and customers’ increasing expectations. The objective was thus to have a significant share of future turnover coming from digital offerings. This entailed a focus on developing smart connected water pumps that embed software and a variety of sensors and provide new digital services to customers, such as real-time monitoring and maintenance, performance optimization, and remote control. The aim was also to develop over time stand-alone digital solutions, such as data analytics services that collect and analyze data from various pumps from different vendors. A Head of Digital Transformation (HDT) was appointed to drive the digital journey of Atlas. He was followed in 2019 by the appointment of a CTO and CMO to support the transformation.
A key part of this transformation entailed the implementation of agile methodologies. The implementation of Scrum responded to Atlas’ objective to develop new digital product/service offerings through greater experimentation based on early and continuous customer involvement. Moreover, Atlas aimed to encourage a “fail and learn” entrepreneurial culture, accelerate development cycles, and develop customer-centric thinking to ensure a better match with customers’ needs. Another important objective was to create a digital and agile mindset and extend the use of agile ways of working across the whole organization, thus driving a large-scale agile transformation of Atlas over time.
The implementation of agile started in a separate digital unit, headed by the HDT. The unit was created in early 2017 to explore and develop digital solutions and boost the digital transformation. The digital unit was set up to be highly autonomous and entrepreneurial, like an incubator. Atlas employees were seconded to the unit from different functions in the core organization. The unit needed their different capabilities, but this approach was also a way to break down the silos characterizing Atlas. The teams in the unit were formed partly on the basis of volunteering and partly on the appointment of specific profiles to meet the necessary competence needs. Once the teams were formed, each team would have a fixed number of members, who would only work on one project to enable focus and commitment. The team would work on the project until a solution was ready for market launch. Most teams had a mix of system architects, software developers, data scientists, UX/UI designers, and representatives from the relevant business lines. They were initially responsible for delivering minimum viable products (MVP) in collaboration with selected customers in three months, testing these MVPs with the customers, further developing them, and finally scaling for launch in a broader market.
We conducted 65 semi-structured interviews with employees at the team, middle management, and top management levels, working either in the separate digital unit or in the core organization. Moreover, we conducted 270 hours of non-participant observation of the work done by agile teams in the digital unit. We particularly focused on two teams in the digital unit, Alpha and Beta. The two teams started their project more or less simultaneously, and we could therefore follow and compare their process. In both teams, the team members reported to their line manager in the main organization and were evaluated by both their line manager and the project manager. Team members’ KPIs were based on the achievement of department goals (how much they contributed to the further development of their department) and project goals (for instance, achieving established targets and deliverables on time, and execution of extraordinary project-related tasks). The two teams are presented in Figure 1.
Alpha and Beta teams.
Approach 1: Implementing Scrum through a Laissez-Faire Approach
The implementation of agile was initially deliberately designed as a combination of top-down and bottom-up approaches. It was mandated by the HDT that the teams in the digital unit had to use the principles, roles, and procedures of Scrum, such as Scrum boards, stand-up meetings, sprints, product owners, Scrum masters, and interdisciplinary self-organizing teams. 28 However, Atlas also appointed a project manager (from IT or Business Development) for each team in order to reassure a link between the core organization and the digital unit. The project manager’s role was to manage work inside the team but also to coordinate with relevant projects and functions in the core organization. This PM role, which is normally not part of the Scrum framework, was introduced to adapt the framework to the needs of Atlas.
At the same time, agile implementation was also bottom-up because the teams were given high levels of freedom to decide how they wanted to enact Scrum in their own team. This was to better fit Scrum to the needs and requirements of the specific digital teams. The teams were given a brief introduction to the Scrum framework by two coaches but were otherwise left to find the best way to apply it. We observed that this led to variation among teams in terms of, for example, duration of sprints, frequency of stand-up meetings, or occasional suspension of sprint reviews and retrospectives.
Consequences of Implementing Scrum through a Laissez-Faire Approach
Despite all the good intentions, this approach turned out to be challenging as it led to the emergence of both intra-team and inter-team problems.
Intra-team: Lack of understanding of agile
The culture in Atlas’ core organization was solidly grounded in its engineering roots. Many team members were used to working according to a stage-gate or waterfall approach and emphasizing planning, control, and safety measures. Agile and high levels of autonomy meant that most team members had to approach work in a radically different manner, but it was unclear to them what it actually meant to work agile:
We should work agile, but we do not have a template or guide. If you go to Business Development (department), you have a seven-point stage-gate model, described in 100 papers. It is clearly described. And here we go back to more or less starting from scratch, with not much documentation. (Interview with system consultant in Alpha)
To many team members, this was stressful and frustrating. They struggled to find the best way to organize work:
It has been difficult, because I do not think that the management of Alpha—the product owner and somehow also our project manager—understand how we should run agile. The way they are communicating is more like a waterfall model. There has been a lot of discussion about deliveries and “we will by the end deliver, blablabla . . .” Yeah, but we are talking agile, so of course we have a fixed point with some kind of delivery, but we cannot commit to anything we do not know yet. (Interview with system developer in Alpha)
The project manager of Alpha came from Business Development and was used to working with the waterfall model. In the beginning, Alpha tried to follow the Scrum framework, but because the principles were not clear to them, they were not seen as value-adding and were often skipped or downgraded. For example, the project manager decided to skip the daily stand-ups. Instead of five times a week, stand-ups were held twice a week.
In contrast, the project manager of Beta was well-versed in Scrum and wanted to run the project applying all the prescriptions of the framework. However, she encountered resistance or indifference from her team members and therefore she did not succeed in going “full Scrum.” For example, to get the needed data science competences, 12 software consultants from a foreign software house were insourced to her team. Despite her attempts at following Scrum principles, the consultants did not engage in the team’s Scrum activities. They often skipped stand-up meetings, and during retrospective meetings, they never uttered a word. With one-third of Beta not participating in Scrum, she thought the methodology could not work:
They received Scrum courses, PR courses, and FR courses. We tried to talk to them about retrospectives, being honest and transparent, trusting each other, and being open about the errors they’re making so you can fail fast and learn from the mistakes. We are doing this agile transformation with only externals, and it seems headless: when you do an agile transformation, at least you want to bring up or educate the people to become agile and think creatively and put off time to actually be innovative and creative and work as a team. But when you have external consultants, some of them are more connected to their firm than to the firm they’re sourced into. (Interview with the project manager of Beta)
However, the team needed the competencies and was therefore forced to continue its collaboration with the consultants.
Inter-team: Lack of coordination, knowledge-sharing, and alignment
High levels of autonomy created the unintended consequence that the teams went in different directions and developed different approaches to Scrum. This created knowledge-sharing, coordination, and alignment challenges across the teams. The development of digital offerings entailed a need for the teams to coordinate and align their work. The solutions of the different teams had to be integrated into a common IoT platform, and it was therefore also important that the teams were aligned with the IoT platform team. However, the lack of formal rules for how work should be coordinated across teams made alignment arbitrary.
You have the teams and they have to interact with the platform to some extent. The dialogue we are having all the time is: What responsibility lies on the platform? What lies on the teams? There are always these barriers to understanding who does what. (Interview with business development lead of Alpha)
Team members were focused on their specific project and were more concerned about succeeding in their own MVPs than coordinating with other teams within the digital unit and in the core organization. We observed that knowledge and key learnings were not systematically shared or discussed across the teams. The PMs of Alpha and Beta admitted that they did not meet with the other teams. This led to the emergence of different understandings of central concepts in agile. For instance, during a meeting in the digital unit, a product owner highlighted how the different teams developed different interpretations of what an MVP meant and that this was problematic in terms of defining deliverables.
Team members also complained about aligning with teams in the core organization due to the different working practices:
Sometimes we are dependent on people who are not in the digital unit, and who might not work agile. It sometimes clashes when we have another focus and timeframe, compared to how the normal processes are working. (Interview with system consultant, Alpha)
We began to observe the emergence of different bottom-up initiatives—for example, communities of practice around certain topics (e.g., Big Data) and workshops or learning days to facilitate knowledge-sharing and alignment. However, such initiatives remained isolated instances. Formalized procedures for knowledge-sharing and alignment across teams were lacking. This was deliberate because the management wanted to create an informal, autonomous, and startup-like environment where knowledge-sharing should occur spontaneously. However, we observed that the teams did not mingle and that spontaneous interactions were very limited.
Some team members also mentioned the lack of formal leadership in ensuring coordination between teams and in helping them develop a more holistic mindset:
Who has the overview of what is being delivered in the different projects? Nobody has it, but, in my mind, the HDT has to take care of that collaboration, making sure that the different teams are not delivering the same functionalities in three different ways. (Interview with digital business development manager)
The issues of coordination and alignment grew bigger over time and the senior management of Atlas decided that agile had to be implemented in a more structured and formalized manner.
Approach 2: Increased Top-Down Control through SAFe
Atlas decided to create greater transparency across teams in the digital unit. During a management meeting in the unit, a Project Management Office (PMO) consultant pointed out the issue of transparency:
Something that is very important for the HDT is to enable transparency. When we have each team that has its own backlog, its own way of working: How will you ensure the other teams can see what you are doing and how you are doing it? (Fieldnotes)
Beyond the concerns of transparency, management also wanted greater control over how agile methodologies were applied. This was important as Atlas planned to implement agile across the whole organization.
This [laissez-faire] way made sense in the beginning where it really was a startup. We handled everything with just two coaches. But more things are happening and we need to standardize. This is really a moving target, a dynamic set-up. Right now, we are moving towards a large degree of integration into the core organization as well. (Interview with a manager in the unit)
Atlas decided to take a more controlled top-down approach and increase the formalization of agile implementation by applying the SAFe framework. This approach aimed to provide a clearer direction and formal guidelines to the teams for how to work agile and address the issues of alignment, coordination, and knowledge-sharing across teams. At first, SAFe was implemented as a pilot in the digital unit and IT department, but it was the plan that SAFe should be rolled out more broadly in the rest of the organization. This approach included coaches, training programs for Scrum masters, project managers, and product owners, and the establishment of new formal roles to facilitate inter-team alignment (as laid out in the agile release train) and to develop a shared understanding of agile across teams:
The reason we actually implemented SAFe was that we saw a need to have a common language in how we work, what we call the different things . . . to ensure that we actually understand what a backlog is, what a sprint is, what a Scrum master is, and so on. (Interview with a director of the digital unit)
Atlas also wanted to document the knowledge and learnings developed by the different teams, making tacit knowledge more explicit—for example, through so-called “big room plannings.” It was however also emphasized that, while SAFe was applied, the teams still had the autonomy to decide how to organize their work and how to adapt SAFe to their specific needs:
You have the same governance structure, but how you structure the team setup is totally up to you guys . . . We created this football field, but how you are playing there is totally up to you. (Product owner of Beta, Fieldnotes from an inter-team meeting)
At the same time as the implementation of SAFe, teams from the Business Development and IT departments (for example, the IoT platform team, a Connectivity team, and an Analytics team) were relocated to the digital unit to achieve greater alignment and closer collaboration. It was also decided that employees could now work in more than one digital team. This adaptation was also introduced to intensify knowledge-sharing and alignment across teams. Simultaneously, Atlas acknowledged the challenges of applying agile in relation to hardware development and therefore designed tailor-made process models to accommodate different development needs. Two such models were hybrid versions of Scrum and Stage-Gate approaches.
Consequences of Implementing SAFe (Increased Top-Down Control)
The implementation of SAFe had different consequences for teams, and the changes were received with mixed feelings.
Alignment of interpretations and organic adjustments to the teams’ way of working
SAFe solved many of the problems seen in the laissez-faire approach. The fact that Scrum masters, project managers, and product owners received comprehensive training meant that they could slowly develop a shared understanding of agile and build up new ways of working. For example, a scrum master explained: “At least now we agree on the definition of MVP: that it is something we release on the market.” SAFe also made it easier for the teams to integrate hardware developments, because they were allowed to use hybrid models that included stage-gate elements.
However, SAFe also created negative reactions. Employees with a pre-existing understanding and appreciation of Scrum felt that SAFe reduced their autonomy, going against the principles of agile by being very bureaucratic:
What I have seen in SAFe is that we do agile, but we take away the self-controlling part of it. And then it’s just a new way of bureaucracy, in my mind. (Fieldnotes, employee during a team meeting)
Many said they were confused and lacked an overview and that SAFe was overly complex.
Lack of coordination across teams
Although SAFe is designed to provide a more holistic governance across teams, team members and managers continued to criticize the lack of transparency and coordination after its implementation. The digital teams complained that the IoT platform team was developing the new IoT platform without consulting or coordinating with them, and that the specific needs of the teams therefore were not taken into consideration. When there were “Big room planning sessions,” certain people were invited, but did not participate:
When we have alignment meetings, it is usually just us from technical development. Those now wanting to have even larger complexity in the support systems, were simply unaware of what was already agreed on. Now they argue that we cannot sell, we cannot get into the market, the market does not support this kind of architecture, etc. So there is a really bad alignment . . . we are simply not prioritizing to get a common understanding. (Interview with development engineer in the platform team)
Moreover, some developers complained that managers and business representatives made important decisions without consulting them:
SAFe with all that complexity, all those meetings, and all that mumbo jumbo: I don’t know how so many managers are doing nothing else but talk to other managers about requirements and stuff. And it never hits the developers. (Interview with a developer in Beta)
During sprint reviews, Alpha and Beta members often complained that the platform team could not deliver. In particular, Alpha experienced long delays and constantly had to wait for platform features before they could proceed:
In the platform, we have the analytics engine that is not ready. If that engine stops or if the platform team has problems, then we have to stop as well. (Interview with Alpha developer)
Atlas was focusing on building the platform first, rather than enabling a swift development of smaller MVPs to be pushed out to customers first. As Alpha became increasingly impatient, they decided to hire an external platform provider to move forward with the development without the Atlas platform:
Alpha is out of that track due to the platform delays. We need to have commercial traction and go out there and test. So, it was a mutual decision, since the platform team cannot provide us with the right resources. It was a “stop-and-go” development all the time. We couldn’t really live with that. (Interview with Alpha Business partner)
To keep up momentum with the test customers, Alpha moved on while ignoring, at least to some extent, the coordination prescriptions of SAFe.
Approach 3: Reacting to SAFe Effects through Bottom-Up Initiatives
As Alpha started its collaboration with the external platform provider, its participation in inter-team coordination decreased. In the digital unit more broadly, the lack of coordination between the business and technical representatives as well as with the platform team created problems and led to misalignments. Many blamed it on the complexity of SAFe.
In response to these problems, some teams introduced new bottom-up initiatives to enhance coordination and knowledge-sharing, and this led to local adaptations of SAFe. For example, new roles that were not part of the official SAFe framework were created, such as “Data Pipeline Owner” or “Big Data Engineer.” These new roles were necessary to handle tasks related to data analytics, such as processing large amounts of data collected from the new digital solutions and transforming them into useful insights:
SAFe does not at all cover data and analytics . . . That’s why we created new roles. For example, the big data engineer or the data pipeline owner was not in Beta a year ago, and now there is one. (Interview with a line manager in the digital unit)
Another local initiative was the introduction of a “Data Pipeline Playbook” that described how the data analytics process had to be handled by the digital teams and the key tasks and responsibilities characterizing these new roles. Finally, other examples were the arrangement of a new type of coordination meetings between teams to share learnings and discuss issues related to sales and service and the adjustment of the format of refinement meetings in some teams (such as Beta).
Approach 4: Top-Down Adaptation and Re-Articulation of Agile
Some bottom-up initiatives were noticed by managers and PMOs. As some of these initiatives solved the challenges of coordination and of the SAFe framework in general, Atlas decided to extend these new practices and roles more broadly to facilitate the use of SAFe across the organization. Even some of the more controversial bottom-up initiatives—for example, Alpha going against Atlas’ policy by using an external platform—led to reflections in the management team. Alpha’s approach led to a discussion of whether Atlas’ proprietary platform was the right strategy or whether outsourcing the platform should be considered. Although Atlas decided to continue with the proprietary platform, they decided to allow teams to use external platforms temporarily when developing MVPs with pilot customers.
Atlas also reflected on the transformational issues related to its vast use of external consultants who resisted working agile (e.g., in Beta), and eventually the firm decided to terminate its collaboration with the external consultancy. Instead, they decided to focus either on existing Atlas employees or the recruitment of new data scientists with Scrum or SAFe experience.
The above examples show how Atlas adapted and re-articulated SAFe to integrate emerging bottom-up initiatives to achieve a more sustainable use of agile over time.
Analyzing Atlas’ Agile Journey through the Lens of Translation Theory
Looking at the agile journey of Atlas from the outside, it may appear as messy, flawed, and unreflected. However, from a Translation theory perspective, 29 we see an organization that embarked on an agile transformation journey through a continuous process of articulation, translation, and re-articulation of agile. During this process, organizational members could slowly get used to and make sense of a different way of working. Translation theory indicates how ongoing processes of translation are activated whenever a global idea (agile methodology) enters an organizational setting, 30 where actors discuss, interpret, and modify the idea. The transformation happens via narratives and practices where elements of an existing methodology mingle with new emerging local ideas to adapt agile to the local context and needs.
Figure 2 provides an overview of the different approaches that characterized the agile journey of Atlas, where agile was continuously articulated and re-articulated by organizational members. During this journey, the organization tried to navigate the paradoxical issue of how to allow for autonomous local adaptations of agile (bottom-up), while retaining control of the agile implementation (top-down). Control refers to the use of formal rules, processes, and procedures to guide teams in how they should apply agile. In contrast, autonomy entails the freedom to choose how agile work is organized and executed within a project. These two dimensions are depicted on the two axes of the figure.
Agile implementation.
In the initial phases (Approach 1), Scrum was mandated, but the teams had high levels of autonomy. This led to multiple re-articulations of the agile methodology as the teams tried to make sense of it and figure out how to apply it. However, different sensemaking outcomes led to intra- and inter-team challenges. As a consequence, Atlas increased control (Approach 2) by implementing SAFe. This was seen as a necessary means to achieve the needed alignment across teams and units. SAFe represented a top-down adaptation of the agile methodology to better meet the organizational needs at that moment in time. However, issues of transparency and coordination across teams remained after the implementation of SAFe and the teams tried to cope with these issues by coming up with localized bottom-up adaptations of the formal SAFe framework (Approach 3). Atlas assessed these bottom-up initiatives and in some cases decided to embrace them, re-articulating an “Atlas-version” of SAFe which incorporated its firm-specific needs (Approach 4). Translation theory describes transformation as an ongoing process, and it is likely that after new re-articulations of agile, teams will again react to them, adapting them to their context and needs, leading to another round of assessment by Atlas.
By considering top-down articulations and bottom-up initiatives of re-articulation, we see how reactions and local initiatives at the team level contributed to the agile transformation more globally. By being flexible and open to bottom-up adaptations, Atlas succeeded in integrating agile in a more sustainable and meaningful manner. In Table 1, we provide examples from our findings of the continuous translation of the agile methodology during Atlas’ agile journey.
Agile Implementation as an Ongoing Process of Top-Down and Bottom-Up Translations.
Implications
The case of Atlas provides key insights for managers planning to undertake an agile implementation journey, as summarized in Table 2. The initial Approach 1 had the effect of preventing potential resistance by letting the teams have the autonomy to try out agile. In this sense, Approach 1 worked as a prelude to agile implementation, which may be important in cases with stark contrasts between agile principles and the pre-existing culture in the organization. Approaches 2, 3, and 4 can be seen as an appropriate method for implementing organization-wide agile transformation. Many organizations on an agile transformation journey stick to implementing a framework (e.g., Scrum and SAFe) exactly “as is” (as implied in the Business Agility View). Instead, firms may benefit from viewing the transformation journey as a process of translation of a predefined agile framework where general principles are implemented but with an experimental and adaptive approach. In this way, agile frameworks are only the starting point from which firms, through iterations, will find an approach appropriate to them.
Key Insights for Managers.
Developing a Framework for an Organization-Wide Agile Implementation
How can managers embark on an organization-wide agile journey in digital transformation contexts? Based on the insights from this study, we developed a framework that highlights key areas to be considered and related lessons (see Figure 3).
Framework.
Embrace agile as an ongoing process of adaptation
Atlas’s approach to agile implementation was both deliberately and indeliberately experimental and adaptive. This approach turned out to be successful because it enabled Atlas to infuse agile across the organization in a more meaningful manner. Atlas’s approach was different from traditional change processes applied by many organizations, such as Kotter’s change model 31 where careful initial planning and stepwise control are seen as a must for large-scale transformations. In the case of agile implementation to facilitate digital transformation, a Kotteresque well-planned top-down approach is unlikely to work. Agile transformation is not a well-defined journey from A to B, with a clear starting point and end point. Rather it is a continuous process, in which organizations must constantly adapt as the world around them changes and the organization learns. A large-scale agile transformation requires an approach that is inherently agile—that is, experimental, iterative, adaptive, and scalable. An agile transformation should be allowed to emerge more organically over time as the organization experiments with local ideas and integrates them into the agile framework. Managers should thus embrace agile as a process of ongoing adaptation. This entails allowing for continuous articulations and re-articulations of the methodology to occur over time across levels of the organization, based on emerging needs and challenges faced. Thus, instead of considering agile transformation as a change management project involving a one-to-one implementation of an existing framework, a framework like SAFe should be used as a starting point on which to build a dynamic agile framework appropriate to the specific organization. This process takes time because it entails not only changing the existing concepts, beliefs, and normative principles of an organization but also changing the concepts, beliefs, and principles of the very framework that will drive the transformation. As such, it is not merely a task of implementing a new and better work methodology (e.g., Scrum) or framework (e.g., SAFe). It is a matter of breaking with old traditions, while iteratively and experimentally building up new ones with the participation of everybody and without knowing exactly what the new should be. However, this approach is not without risks. If the re-articulations of the agile methodology move too far away from the principles on which the agile philosophy is built, there is a risk that the benefits of agile may not take effect. In other words, when firms allow teams to find their own approach to agile, they should be careful not to let agile become so diluted that agility is completely eradicated. Managing control versus autonomy is a fine balance.
Undertake a stepwise transformation
Embarking on an organization-wide agile transformation is a major undertaking, especially for organizations with a legacy business. Instead of implementing agile across the entire organization at once, managers should consider focusing on changing one step at a time, as this would enable them to learn from experiences gained. Managers should first focus on implementing agile at the team level. This “piloting” approach (see Figure 3) would enable them to assess what works and what does not work in the way teams enact agile and to adapt and re-articulate the methodology accordingly. This would not only enable them to understand which practices are appropriate but also understand and address potential resistance points in the transformation process.
Agile can then be scaled up to larger parts of the organization. The SAFe framework can serve such a purpose by providing a common direction and a shared understanding. However, as our findings highlight, managers should take into consideration the context in which SAFe will be applied and make adaptations to fit with such context. This requires managers to monitor and constantly assess emerging challenges, disregard unfitting approaches, and focus on detecting positive local adaptations of the framework that can be extended to the rest of the organization. This approach thus requires managers to have an iterative mindset, to continuously incorporate learnings in the implementation process, and adapt the methodology on the way.
Facilitate intra- and inter-team processes
As organizations embark on an agile journey, navigating the paradoxical issue of autonomy versus control becomes imperative. Providing high levels of autonomy can reduce the shock of implementing a radically new way of working, thereby mitigating larger-level resistance to change. However, managers need to be aware that autonomy can lead to frustrations and divergent interpretations of agile (intra-team issues) as well as issues of coordination and alignment across teams and units (inter-team issues). To diminish these effects, training and coaching may be provided as this may facilitate building a shared understanding of agile. This common understanding may enable better alignment across teams and units. We further suggest that organizations limit the use of external consultants. Agile projects work as arenas and engines of cultural change and should therefore include core members of the organization, not temporary visitors. This is important to anchor an agile mindset across the organization.
Moreover, although a holistic governance framework such as SAFe is designed to mitigate inter-team coordination and knowledge exchange issues, managers still need to be aware that the framework may not address every issue their organization encounters in their agile transformation. In such cases, managers should articulate new practices or roles to be integrated into the framework to better fit it into the local context.
Manage the interplay between agile and digital transformation
A successful agile implementation journey is also based on the ability of organizations to recognize that agile and digital transformations are closely interlinked. Managers need to think about how to manage interdependencies across projects. This is due to the complex nature of digital projects, entailing a wider variety of elements and features that need to be managed as a cohesive whole. 32 Issues of alignment across teams and units can also emerge if such interdependencies are not properly managed. Managers should ensure that proper infrastructures and systems are in place to enable teams to rapidly test and deliver solutions to customers. More specifically, a key learning from Atlas’ journey relates to the development of an IoT platform for the integration of multiple digital solutions. The case indicates that it may be necessary to allow for alternative technologies in the early stages. For instance, agile teams can use off-the-shelf IoT platforms for fast development of MVPs to keep up the momentum and avoid delays. However, managers should also make sure that teams think about how the developed digital solutions should later be integrated into the proprietary platform.
Managing the interplay between agile and digital transformation also entails recognizing that adaptations to agile are needed to fit the complex nature of digital projects. For instance, Atlas recognized that adaptations of Scrum were needed when dealing with digital projects entailing both software and hardware components. Thus, allowing for the use of hybrid models is important to better manage such interdependencies. Managers should also allow for the adaptation of roles and the creation of new roles. For instance, new roles for data-sharing practices among agile teams become essential when dealing with digital projects.
Checkpoints for Facilitating Agile Implementation
Based on this framework, we developed a number of specific checkpoints for managers to consider (see Table 3). Analyzing answers to these checkpoints can help managers assess challenges emerging during their agile implementation journey and to think about potential initiatives to address them. This is important to create the best conditions for agile implementation.
Checkpoints for Managers.
Conclusion
This study of a large product manufacturer provides insights into how an organization-wide agile implementation was achieved through both top-down and bottom-up approaches. This occurred via a lengthy iterative process of adaptation taking place at all levels of the organization, where team members—through emergent and sometimes controversial adaptations—helped re-articulate and thereby facilitate the implementation. These bottom-up adaptations established a more appropriate balance between standardized agile frameworks and firm-specific conditions that cannot be disregarded. The study provides an example of how implementation of standardized agile methodologies can lead to “undesirable” outcomes, but that these outcomes bear great value for the organization in developing a more firm-grounded transformation.
Footnotes
Notes
Author Biographies
Michela Beretta is an Associate Professor in innovation management at the Department of Management at Aarhus University (email:
Pernille Smith is an Associate Professor of innovation management at the Department of Management at Aarhus University (email: