agile digital transformation a case study of interdependencies

• eLibrary Home
• eLibrary Login
• Next Event >

Home > Conferences > ICIS > ICIS 2018 Proceedings > MANAGEMENT > 6

IS Development and Project Management

Agile Digital Transformation: A Case Study of Interdependencies

Presenter Information

Marius Mikalsen , SINTEF Follow Nils Brede Moe , SINTEF Follow Victoria Stray , University of Oslo Follow Helga Nyrud , University of Oslo Follow

Description

Current digital transformation moves information systems development into larger transformation programs with higher strategic significance and increased complexity in organization. Agile and BizDev are among the practical methods used to practice digital

Recommended Citation

Mikalsen, Marius; Moe, Nils Brede; Stray, Victoria; and Nyrud, Helga, "Agile Digital Transformation: A Case Study of Interdependencies" (2018). ICIS 2018 Proceedings . 6. https://aisel.aisnet.org/icis2018/management/Presentations/6

Since October 30, 2018

Advanced Search

• Notify me via email or RSS
• All Content

Author Corner

• eLibrary FAQ
• 978-0-9966831-7-3

Home | About | FAQ | My Account | Accessibility Statement

Privacy Copyright

•   Hjem
• Publikasjoner fra CRIStin
• Publikasjoner fra CRIStin - SINTEF AS
• Vis innførsel

Vis enkel innførsel

Agile Digital Transformation: A Case Study of Interdependencies

Tilhørende fil(er).

Denne innførselen finnes i følgende samling(er)

• Publikasjoner fra CRIStin - SINTEF AS [5583]
• SINTEF Digital [2379]

• Conferences
• New Conferences
• search search
• You are not signed in

External Links

• Google Scholar
• MikalsenMSN18
• References: 0
• Cited by: 0
• Bibliographies: 0
• [Upload PDF for personal use]

Researchr is a web site for finding, collecting, sharing, and reviewing scientific publications, for researchers by researchers.

Sign up for an account to create a profile with publication list, tag and review your related work, and share bibliographies with your co-authors.

Agile Digital Transformation: A Case Study of Interdependencies

Marius Mikalsen , Nils Brede Moe , Viktoria Stray , Helga Nyrud . Agile Digital Transformation: A Case Study of Interdependencies . In Jan Pries-Heje , Sudha Ram , Michael Rosemann , editors, Proceedings of the International Conference on Information Systems - Bridging the Internet of People, Data, and Things, ICIS 2018, San Francisco, CA, USA, December 13-16, 2018 . Association for Information Systems, 2018. [doi]

• Bibliographies

Abstract is missing.

• Web Service API

Mastering Digital Transformation: A Case Study (Part 1)

• Unlearning what we have learned so far and fundamentally changing our daily ways of working required a considerable amount of courage from everyone involved. 
• Start small . We started with small steps and then scaled up quickly. 
• Don’t play it, mean it! And be it! For the digital transformation, the focus is on applying the agile principles instead of stubbornly following a specific method.
• Using commodity infrastructures makes us faster.
• Focus on self-organizing, cross-functional product teams.
• We achieve greater effectiveness by treating offshore teams as equals.

Paradigm Shift

• From waterfall methodology to agile software development
• From project to product 
• From development and operations to DevOps
• From requirements analysis to design thinking
• From IT service management to a focus on business value 

“One Touch Retail”

Changes from the status quo, revolution at mercedes-benz.

The four catalysts of the Mercedes-Benz ITS strategy

• A radical process simplification reduces the complexity and duplication of tasks, which allows greater automation of simpler processes.
• A shift of focus away from the project and towards the product itself. The goal is to use data to reduce costs, increase revenue, and develop your intellectual property and user base.
• Using speed as a strategic advantage, e.g. to implement customer requirements promptly in your products through continuous delivery.
• The willingness to fearlessly question existing rules and processes and to learn from mistakes and feedback.
• Use of free and open-source software
• Cloud-based operation that enables DevOps
• Implementation of microservices that can be reached via APIs
• Working in dynamic swarms
• Use of Mercedes-Benz standard security providers

We consistently implement the Mercedes-Benz IT strategy in the OTR project. 

Ways of working.

• The automobile industry is currently undergoing a fundamental transformation  (refer to [13], for example). The societal, technical, and economic upheavals behind this are now so prevalent in public discourse that the need for action is clear. While the transformation represents a challenge or even a threat on the one hand, on the other it also enables change projects of this kind.
• At the start of the OTR project, we were met with great openness regarding agile methods and the aforementioned paradigm shifts. Even during the initial two-week inception phase we repeatedly heard the motto “trust the process.” This demonstrates the pledge of confidence that the project employees at Mercedes-Benz – who had previously only rarely come into contact with agile methods – made to us. 

Retrospective

Team setup and abilities.

• If teams are to work autonomously, the necessary abilities, and therefore individuals, must be available in the team. This inevitably leads to cross-functional teams. 
• The scaling up of agile product teams necessitates a reduction of dependencies between teams. Microservices can help strengthen this autonomy. 
• The introduction and operation of a microservice infrastructure requires capabilities such as the use of automated deployment pipelines (CI/CD), infrastructure automation, monitoring, etc. (see M. Fowler [16]). 
• Hypothesis-driven development is based on the possibility of making mistakes. A safe work environment is necessary for this. 
• Design thinking requires creativity, which in turn benefits from diversity.
• Implementing agile principles requires test automation because frequent deployments are impossible with manual tests. This is achieved by implementing a test pyramid  (for details on this, see Hermann Vocke [17]). 

Overview of mutually supportive abilities

Living out agility, summary and outlook.

Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.

Related Blogs

Keep up to date with our latest insights

An official website of the United States government

The .gov means it’s official. Federal government websites often end in .gov or .mil. Before sharing sensitive information, make sure you’re on a federal government site.

The site is secure. The https:// ensures that you are connecting to the official website and that any information you provide is encrypted and transmitted securely.

• Publications
• Account settings

Preview improvements coming to the PMC website in October 2024. Learn More or Try it out now .

• Advanced Search
• Journal List
• Springer Nature - PMC COVID-19 Collection

Large-Scale Agile Transformation: A Case Study of Transforming Business, Development and Operations

Nils brede moe.

SINTEF, Strindvegen 4, 7465 Trondheim, Norway

Marius Mikalsen

Today, product development organizations are adopting agile methods in units outside the software development unit, such as in sales, market, legal, operations working with the customer. This broader adoption of agile methods has been labeled large-scale agile transformation and is considered a particular type of organizational change, originating in the software development units. So far, there is little research-based advice on conducting such transformations. Aiming to contribute towards providing relevant research advice on large-scale agile transformation, we apply a research-based framework for evaluating organizational agility on a product development program in a maritime service provider organization. We found that doing a large-scale agile transformation involves many significant challenges, such as having a shared understanding of the problem, getting access to users, and getting commitment to change that needs to be done. In order to overcome such challenges, we discuss the need for a holistic and integrated approach to agile transformation involving all the units linked to software development.

Introduction

Software development teams are currently working on developing products providing new digitally enabled customer experiences - while simultaneously incubating and accelerating digital innovations - are facing increasingly complex problems to be solved. Part of the complexity is because solving such problems involves relying on several actors outside of the agile software development team [ 1 , 2 ]. One example is close cooperation with the business development unit needed in order to achieve the potential advantages of a continuous business and development process [ 3 ]. Another example is the need for fast feedback from the customer, which in agile software development is realized by the introduction of frequent software releases to the customer or market. Further, a transformation to continuous delivery needs to consider units such as operations (i.e., the customer-facing side of the organization) and sales and marketing [ 4 ]. Agile software teams cooperating with other non-agile units represent a challenge [ 8 ], as agile software teams work highly iterative in a sense and respond manner. Other units may be more plan and document-driven. The need for agile software development teams to interact with other units in the organization dynamically and responsively is why companies today aim to scale agile methods beyond software development. We understand such scaling as a large-scale agile transformation in the organization.

As agile methods scale and more units in the organization or entire organizations become agile, it is referred to as organizational agility. Overby et al. [ 5 ] define organizational agility as “the ability of firms to sense environmental change and respond appropriately,” and show the different combinations of sensing and response capabilities that organizations should have. They argue that a company that is highly effective at sensing environmental change but is slow to act or acts inappropriately cannot be considered agile. Likewise, a firm that responds appropriately will not be agile if it is unable to sense the correct opportunities to follow. In an agile organization, therefore, if operations sense a change in customer behavior, software development must change the digital customer experience must change, and so must sales and marketing must change accordingly. Worley et al. [ 6 ] argue that “agility allows an organization to respond in a more timely, effective, and sustained way than its competitors when changing circumstances require it.” Having the ability to make timely and effective and sustained change results in sustained high performance. Worley et al. (ibid.) introduce a framework to assess organizational agility based on the literature of organization design and flexible and agile organizations. The framework was validated with studies of performance data from 20 firms and interviews with executives. The framework explains routines, the features of these routines, and describes how agile organizations apply them. In order to grasp large-scale agile transformation, we will apply the framework. We chose that particular framework because it is based on organization studies theory and on findings from empirical studies (the framework is detailed in Table  1 in Sect.  2 ). However, as of yet, few other researchers have tested the framework. Motivated by the need for understanding how agile software development teams can interact with other units, how to do a large-scale agile transformation, and the need for research on frameworks for a large-scale agile transformation we ask the following research question:

Table 1.

The conceptual framework for evaluating organizational agility developed by Worley, Williams, and Lawler [ 6 ]

How is a Large-Scale Agile Transformation Done in Practice?

In this paper, we examine large-scale agile transformation in the context of software product development. We understand an agile transformation as broadening the use of agile methods in an organization, that is, involving sales, marketing, development, and operations. The remainder of the paper is organized as follows: In Sect.  2 , we present relevant literature on large-scale agile transformation and the agile organization framework we use for understanding such transformation. In Sect.  3 , we describe our research method in detail. In Sect.  4 , we present results from a case study using the framework. We discuss our findings in Sect.  5 . Section  6 concludes and presents key findings from the study.

In this section, we present existing research on large-scale agile transformation, identify a gap in the research, and suggest a framework for understanding such transformations.

The Challenges of Large-Scale Agile Transformation

Accelerating rates of technological change, shifting customer behavior, and changing business models and markets necessitate software development that is customer-centric, iterative, continuous, and experimental [ 1 ]. Organizations apply agile methods to these digital transformations in order to allow themselves to create, react to, embrace, and learn from change while enhancing customer value [ 7 ]. While agile methods have traditionally been practiced within software development teams, there is now a need for using agile methods for interaction between software teams and other non-development organizational units, such as markets, sales, and operations. In practice, this requires a close and continuous linkage between business units (market, sales, and operations) and software development units. The process of continuously assessing and improving this link is described as BizDev [ 3 ].

Dikert et al. [ 8 ] report that interaction with non-development units using agile methods is the second most challenging aspect of large-scale agile transformations. Challenges include adjusting to an incremental delivery pace, adjusting to product launch activities, and organizational reward models that do not encourage cross-unit collaboration. Working with agile methods across different units, therefore, involves handling an increasing number of actors, interface towards existing systems, and unexpected interdependencies [ 9 ]. For organizations with hierarchical and centralized decision-making structures, agile methods cause friction between management that work in traditional ways and agile units [ 10 , 11 ].

Transforming Business, Development and Operations

From the above reported practical challenges with a broadening of the agile method towards including business and operation units, there is a need for a theoretical framework that is capable of explaining what is needed to scale agile to the wider organization. To that end, we have chosen to apply a research-based framework for assessing organizational agility [ 6 ]. The framework shows that Agile organizations ought to have a set of strategies, structures, and systems that drive them towards higher performance and business agility. Four routines of agility are key:

• Strategizing: How top management teams establish an aspirational purpose, develop a widely shared strategy, and manage the climate and commitment to execution
• Perceiving: The process of broadly, deeply, and continuously monitoring the environment to sense changes and rapidly communicate these perceptions to decision-makers who interpret and formulate appropriate responses.
• Testing: How the organization sets up, runs and learns from experiments.
• Implementing: How the organization maintains its ability and capacity to implement changes, both incremental and discontinuous, as well as its ability to verify the contribution of execution to performance.

The above routines for strategizing, perceiving, testing, and implementing have 14 dimensions, outlined in Table  1 below.

Changing existing organizations is challenging. In some cases, it might be easier to create new adaptable organizations rather than to change an existing organization to be adaptable. However, all organizations have some agile features [ 12 ]. An alternative to creating a new organization, therefore, is to start an agile transformation in a part of the existing organizations that already have agile features, which software development units typically do have. The focus in the transformations should be on which features to address to increase agility and how to do it. A part of the organization can, for example, be everyone involved in the development of a product from team management, operation, software development, business, sales, legal, and marketing. In terms of how to do it, as different units are drawn together, it is important to allow for divergent views and opinions to be discussed to allow for transformation to occur. In the concept of “groan zone” [ 13 ], it is recognized that everyone has their frame of reference.

Moreover, when people misunderstand one another (which is likely when they all represent different units), they become more confused and impatient. Often, people do not want to be in the groan zone, because it is uncomfortable, but a facilitator can help. The facilitator’s main objective in the Groan Zone is to help the group develop a shared framework of understanding.

Research Design and Method

In this paper, we report findings from a company that conducted a large-scale agile transformation in one of their product development areas (as suggested above [ 12 ]), transforming sales and marketing, software development and operations at the same time. Their product development area is our unit of study and allows us to study how multiple disciplines from multiple organizational units interact when creating a software-based product. Our study is a holistic case study [ 14 ]. According to Yin, case studies are the preferred research strategy when a “question is being asked about a contemporary set of events over which the investigator has little or no control” (ibid, p. 9). we followed the five-step process proposed by Yin: 1) Case study design 2) Preparation for data collection. 3) Collecting evidence: execution of data collection on the studied case. 4) Analysis of collected data and 5) Reporting.

We collected data through observations of the collaboration over time in meetings and workshops, through interviews, by studying documentation and by participating in the planning of the agile transformation. The Company (name suppressed for anonymity) is a multinational provider of services the energy, process, and maritime industries, and was chosen because it participated in a research program on large-scale agile software development. The organization had developed a digital solution for booking ship surveys through a web portal. The process in which the digital solution replaced was manually and very costly. Further, booking surveys were sub-optimized, resulting in ships doing surveys in harbors that were not cost-effective and that did not allow all work to be done at once. The potential cost savings from using the digital solution was estimated to be over 10 million Euro per year. The challenge, as we entered the case, was that not cost savings were not sufficient.

Data Collection and Analysis

Our data collection (Table  2 ) started in August 2018, when the company needed to rethink the whole product development process in order to reach the estimated earnings of the digital solution. The company recognized that a critical issue was that the missing interaction between software development, sales, marketing, and operations. The missing interaction and the need for improving the product led to a transformation initiative. The researchers participated in all planning meetings of the initiative, lead two of the workshops and had status and synchronization meetings with representatives from the company, and conducted several interviews with key stakeholders. Besides, four large international customers were visited and interviewed. These customer interviews covered the following topics: Describing the customer business process and model, understanding the survey ordering process, reflecting on the usability of the new technology introduced. All activities were documented by taking notes, meeting minutes, and pictures of materials produced in the workshops. Also, we got access to product documentation, contracts, data on user activity on the digital portal, and plans. We ended the data collection in September 2019. The results from the transformation were presented back to the practitioners involved regularly in feedback meetings. More details about the case, the product, and the large-scale agile transformation is found in the results.

Table 2.

Data sources

We used a variety of strategies to analyze the material [ 15 ]. First, we described the project and context in a narrative to achieve an understanding of what was going on in the large-scale agile transformation project. Then, we described aspects of the transformation by using a framework for assessing organizational agility [ 6 ] and analyzing the different routines proposed by the framework (as introduced in Table  1 ). Further, we analyzed the data by mapping it to the continuous processes described by Fitzgerald et al. [ 3 ] (i.e., continuous planning, development, and operations) to understand which processes were disconnected. We hypothesized that the disconnected processes were a core reason for why the company did not realize the potential of the solution. Then we categorized the data according to the organizational agility framework [ 6 ]. In the analysis, we emphasized how the need for change was interpreted by different participants in the transformation.

We first describe how the need for an agile transformation was detected (diagnosing phase), then we describe the outcome of the main activities in the transformation workshops and the work done after each workshop. Based on the results, we identified an understanding of how elements of a large-scale agile transformation are dealt with in practice.

The new product was initiated in 2016, and the goal was to create a system for ship owners to book services for their ships through a portal instead of using the previous manual process. Booking through the portal makes it possible to suggest what combination of services to offer, and when the service should be conducted on a specific ship in a specific port. A system based on machine learning could potentially reduce the cost of surveyor traveling, reduce the total number of services needed, the need to offer services in expensive ports, and reduce the time a vessel needs to be in a port. Both the customers and the company could gain significant savings by replacing the manual booking process. The product development of the booking portal, which also included machine learning, went through several phases, from exploration, ideation to implementation. The work started in April 2016 by an analysis of the market, customer needs, and a concept study. A version of the product was tested in June 2017, and the product was launched in October 2017. Figure  1 shows the innovation journey as described by the company. All managers in the company got training in the innovation method. The planned functionality was implemented and launched, but the product did not meet its expectations. While the software development team implemented all the requested functionality, still only 30% of the customers followed the recommendation by the digital booking process.

The innovation journey from 2016–2017.

Further, the customers, in general, did not accept the recommendations provided by the planning part of the booking system. Recommendations were related to what services a ship should have, in which port the job should be done in, and when the service should happen. Further, there were many customer complaints regarding invoices. It became clear that there was confusion among some customers regarding the service ordered and the service provided by the company. Because most customers did not use the new booking process and, in general, did not accept the recommendations provided by the system, the cost savings were assessed to be very limited in August 2018.

A diagnosing workshop was initiated involving experts from software development and business and customer insight. The diagnosing workshop concluded that the lack of change in user behavior (such as lack of use) could not be explained by the design of the portal and challenges with the user interface alone. The workshop concluded on the following explanations on why the environed results were not achieved:

• The company lacked important information on how the customers actually conducted the former manual booking process.
• The overall company strategy was not aligned with the product strategy. While the new booking system required the company to offer services in limited ports, the company did not achieve a reduction in the number of ports where they had to offer services. Parts of the company still had wanted services to be provided in these ports, even if it was not cost-effective for the company as a whole.
• Internal processes were not coordinated to help the customer in changing his behaviour (e.g., contracts, support, customer contacts).

A transformation was initiated to make all involved units in the company work together to change how they offered the digital service and then change customer behavior. The maritime sector is an old and traditional sector, which makes changes in business processes in the sector slow. Further, this transformation would enable the company to sense the customer needs better, and then respond to the needs as they change. The agile transformation needed to include the following, different organizational units: software development, legal, market, sales, business, and operations. The software development department had been working in an agile way since 2008 and was experienced in using agile, while the other units were still working in a non-agile way. It was agreed to conduct several workshops involving key stakeholders from all the different units. The question was how to conduct workshops to accelerate a transformation that would enable a large part of the company to sense and respond?

Different stakeholders from very different units in the company would necessarily represent different cultures, practices, and ideas. The workshop then needed to facilitate a period of divergent thinking before they could enter the “groan zone”. After a group of diverging ideas brainstormed a list, they found it challenging to discuss the ideas. Everyone had their frame of reference coming from the different units. Moreover, as people misunderstood each other, they become more confused and impatient. The researchers acted as facilitators in the workshops and helped guide the group through the groan zone.

Unfiltered Access to Customer Insight and Aligning Strategies

The first workshop had representatives from key internal stakeholders, such as customer insight, software development, and data analysis (analyzing the customer data), business, sales, and marketing. The highly cross-functional group had the authority to change the future direction of the technical solution and company internal processes. Each stakeholder was responsible for changes in their unit. The focus shifted from: “how do we provide a better user interface to change customer behavior,” to “what changes do we need to implement in our organization to be able to change customer behavior.” It became evident that to deliver an improved service in fewer ports, the company had to reduce the number of other ports in which the service was delivered. However, then some service stations around the world had to be closed down, and this needed top management support. Such significant changes created internal resistance, as a part of the organization would then need to reduce its service offerings and, as a consequence, would earn less money. Through workshops and meetings, the cross-functional group concluded:

• How certain parts of the sales unit operated where hindering part of the product development organization from meeting directly with the customer, which hindered a more in-depth customer insight. To better understand who uses the new system and those who do not use it, there was a need for direct contact between the software development department and the customers. Several of the previous decisions related to product development were made on wrong assumptions.
• For the company to adjust internally (e.g., stopping offering services in some ports), it was essential that cost and performance are measured on the company level and not per organizational unit. Since costs traditionally were measured per unit, each unit that will reduce their income will resist changes. There was a need to work closely with the world regions that needed to change their offerings of ports. New KPIs (key performance indicators) needed to be set for the whole company, not for individual units.
• Better understand the link between the new business model of the company and how the model is linked to a change in customer behavior. Involving the service planning unit in order to change future contracts was seen as a critical measure.
• Better use of statistics on user behavior in the portal. There is a need to continue analyzing patterns of various customer behavior, and to generate new Power BI Reports.
• Use Machine Learning in a new way to understand better which services to provide in which ports, and which services not to offer.

Testing, Implementing and New Improvement

Based on more unfiltered access to the customer, new parts of the organization got access to new and essential insights. The situation was further improved by organizing meetings with valuable customers and by insight from interviewing these customers. The interview guide was targeted to understand the enablers of barriers to changing customer behavior. As a result, more insights into customer behavior were generated, particularly on the internal business processes that happened before the customer used the portal i.e., the customers’ internal planning process. Insight was also gained on what was most valuable when the customer made choices in the portal. Through the insight gained through the interview it was found why the customers did not accept recommendations from the new system. The customer behavior was driven by the need of making sure the ship was always operating, and therefore a familiar port is associated with less risk for the customer. One customer commented: “ The port predictions for container vessels are of no benefit because it does not propose ports I prefer. ”

As a result, from the customer interview process, it was concluded that there was a need to understand how the booking system better could support customer preferences, and further insight was needed on how to enable the customer to order services in an unfamiliar port. Knowledge from the workshops and customer activities was fed into the survey planning centers of the company (the planning centers that were spread around the world were engaged in helping customers plan their work). Changes in how the planning centers operated based on new insight is an example of the operational units change the way they deliver the services.

After changing the software and how the company interacted with the customers, it became evident that the changes had helped to result in the company starting to improve earnings on the product and service they provided radically. However, at the same time, it was clear that the agile transformation now also needed to include more unites, and that it would be an ongoing process with no specific end state.

The company started testing new functionality, which started changing customer behavior. Further, from a more in-depth analysis of the interviews, the need to continue pushing the customers to change their behavior by developing new contracts was considered an essential next step. Involving contract responsibilities in this phase was vital, and the second workshop was conducted. However, it became clear that to get the full effect of new features in the system; there was a need to segregate customers into two segments and to identify the service levels for these segments. Creating customer segments also put forward demands for contracts that would support the segments and, at the same time, needed to enable the customer behavior change to continue. The need for what was known as “smart contracts” was agreed upon in the last workshop. However, what a smart contract looked like was not fully understood.

Further, new questions emerged: is the salesforce ready to sell new products and negotiate new contracts for new customer segments? Are the customers ready to be offered different levels of services based on different contracts (the maritime sector is an old and conservative business)? It became evident in the workshop that sales and legal unites needed to be linked closely with the product development, and that future work was needed in this area.

Evaluating of Organizational Agility Using the Agility Framework of Worley

The agility framework defined by Worley et al. guided our agile transformation. The framework includes routines for strategizing, perceiving, testing, and implementing and has 14 dimensions (Table  1 ). To describe how a large-scale agile transformation is done in practice, we then mapped our findings into the framework (Table  3 ).

Table 3.

An evaluation of organizational agility using the agility framework of Worley, et al. [ 6 ]

Large-scale agile transformation is a critical issue in responding to the digital transformations that are ongoing in many sectors [ 1 ]. Several barriers to such transformation seen from industry experience have been identified, for example, change resistance [ 8 ], and inter-team coordination challenges [ 16 ]. While conceptual solutions such as continuous development and BizDev has been suggested [ 3 ], there is a lack of research-based advice on how agile transformations are to be performed in practice. Driven by our research question – How is a large - scale agile transformation done in practice? - we have reported findings from a case study of a maritime service provider that aimed to transform service bookings digitally. In the following, we answer this research question by discussing our findings in light of a research-based framework on agile organizations [ 6 ].

We found how a typical innovation journey was followed, a product was developed and launched, but the economic gains did not meet expectations. Importantly, as a consequence, the company started investigating the reasons why the product did not meet its projected earnings. One critical insight during the diagnosing phase was that it was not the design of the digital solution per se that caused the lack of customer uptake. For the solution to have its envisioned effects, it would require a change in the internal organization to be able to change customer behavior. The company started a change in a product development environment that already had some agile features, i.e., including software development that was already using agile methods, as suggested by [ 12 ]. The change process was done in order to improve its capacity for sensing customer behavior and adapting the digital solutions. The software development and business development units needed more unfiltered access to customer behavior. This is in line with [ 5 ], who argue that both sensing and adapting is essential for organizational agility.

We analyzed the steps taken by the unit under study in light of a research-based framework on agile organizations [ 6 ]. We found how the part of the organization doing a large-scale organizational transformation addressed all four routines in the framework. The first routine, strategizing, involved struggles to get a sense of shared purpose across the organization, changing business model in terms of offering services in fewer ports, and being committed to change. The second routine, perceiving, involved being willing to experiment with new products, being able to change who gets access to customer insight and that bringing stakeholders together across different units is a critical activity in enabling change. The third routine, testing, we found that it was not changing the technical parts of the system that was the most challenging, but rather to being able to experiment with the organization and making the necessary changes. The fourth routine, implementing, we found that monetary rewards systems and involvement of expertise with decision-making authority were vital in making transformation occur. The challenges and steps taken are in line with Dikert et al. [ 8 ] findings that show how integrating non-development units can be restricted to reward models that do not encourage cross-unit collaboration.

Our findings indicate that some of the frictions agile methods can cause [ 7 ], such as when the new portal started changing the business model of the sales apparatus. Such frictions indicates that large-scale agile transformation needs new decision structures, which means that a company needs to move from a hierarchical decision structure, and isolated decision structures for each department or unit, to a decision structure across the operational and strategic level of individual units.

Finally, we found that an agile transformation is an ongoing process and that the output of an agile transformation is more continuous processes covering several units, many of which are outside software development. A critical insight is that continuous processes require continues learning and continuous experimentation [ 3 ]. Our mapping of findings from the case to the agility framework presented in Table  3 signifies the need for continuity.

Limitation and Future Research

The main limitations of our study are the single-case design and the possibility of bias in data collection and analysis. The fact that we used a single-case holistic design makes us more vulnerable to bias and eliminates the possibility of direct replication or the analysis of contrasting situations. Therefore, the general criticisms about single-case studies, such as uniqueness and special access to key informants, may also apply to our study. However, our rationale for choosing the company as our case was that it represents a critical case for explaining the challenges of conducting a large-scale agile transformation in practice. Our mode of generalization is analytical, i.e., we used a previously developed framework as a template with which we compared the empirical results of the case study, which is similar to Yin’s [ 14 ] concept of Level Two inference.

Another possible limitation is that we based much of our data collection and analysis on semi-structured interviews [ 17 ]. The use of multiple data sources made it possible to find evidence for episodes and phenomena from more than one data source; we also observed, talked to, and interviewed the project members over a period of 13 months, which made it possible to study the phenomena from different viewpoints as they emerged and changed.

The results of this study point out several directions for future research. Firstly, our study highlights several challenges that must be met when conducting a large-scale agile transformation. Accordingly, further work should focus on identifying and addressing other problems that may arise when conducting an agile transformation. Secondly, the framework should be used for studying more mature organizations or departments in order to get a better understanding of the main challenges in such transformations. The observed transformation was the first in the company using the framework. When studying the company doing the next transformation on another product, this should be studied since the case then will be more mature, and other issues from using the framework will emerge.

We have conducted a 13-month study of professionals in a large-scale agile transformation. Our case study of conducting an agile transformation highlights several significant challenges that need to be overcome for a transformation to be successful. This work reports a case study of how a transformation can be done in practice, and also apply a framework for understanding and conducting such an agile transformation. This work is an essential step in its own right since there is much confusion around terms related to agile transformations, similar to early research on the agile transformation of teams [ 18 ]. The need for a framework for agile transformation outside of the software development unit is evident when one considers the emergence of phenomena such as Enterprise Agile, Beyond Budgeting, DevOps, Lean Startups, and many other concepts from business agility in general. These are all indicative of the need for a holistic and integrated approach across all the units linked to software development.

Acknowledgement

This research is funded by the Digital Class project and the Research council of Norway through grant 309631, and 2.0 which is partly supported by the Research council of Norway through grant 236759.

Contributor Information

Viktoria Stray, Email: on.oiu.ifi@yarts .

Rashina Hoda, Email: [email protected] .

Maria Paasivaara, Email: kd.uti@aapm .

Philippe Kruchten, Email: ac.cbu.ece@kbp .

Nils Brede Moe, Email: [email protected] .

Marius Mikalsen, Email: [email protected] .

International Conference on Research and Practical Issues of Enterprise Information Systems

CONFENIS 2019: Research and Practical Issues of Enterprise Information Systems pp 74–84 Cite as

A Systematic Analysis and Synthesis of Case Study Based Agile Scaling Research in the Context of Digital Transformations

• Everist Limaj 12 &
• Edward W. N. Bernroider 12  
• Conference paper
• First Online: 13 December 2019

714 Accesses

1 Citations

Part of the book series: Lecture Notes in Business Information Processing ((LNBIP,volume 375))

Over the past decade, agile scaling concepts in organizations have gained considerable momentum and renewed attention especially from business practice . While agility has its roots in software development, the concept of agile at scale aims at more generally applying agile practices in organizations across different industries. Academic research is serving this development in different disciplines, most notably the management and information systems fields. This short paper takes stock of the last 12 years of scholarly research by developing a systematic content analysis of 26 case studies dealing with agile scaling concepts in the context of digital transformation. In the attempt to narrow the gap between research and practice, we focus on case studies as a strategic research methodology providing rich insights of complex real-life processes such as agile scaling. The findings synthesize the current state of knowledge in this regard and offer new research avenues contributing to the present agile scaling discourse.

• Systematic literature review
• Agile scaling
• Digital transformation

You have full access to this open access chapter,  Download conference paper PDF

1 Introduction

Since the publication of the Agile manifesto [ 1 ], many so-called agile transformations of organizations have been implemented worldwide [ 2 ]. Most commonly, these change initiatives are driven by the need of organizations to keep up with the trends of the digitalization era (i.e. in-depth understanding of customer requirements, rapid creation of novel digital services, ongoing process renewal, and updates of business models) [ 3 ]. Usually utilized in software development teams, agile at scale is being adopted in other industries at different management and operational levels shaping new organizational forms [ 4 ]. Agile at scale can be understood as a process of diffusing the initial adoption of agile principles and methods to more organizational structures [ 5 ]. The increasing application of agile concepts at the organizational level has also resulted in a growing amount of agile scaling case studies provided by scholarly research. Yet, to date, (as we highlight in the next section) research lacks a compelling (i.e. rigorous) assessment of this emergent literature.

This article seeks to fulfil this gap by conducting a thorough examination of the accumulated agile scaling body of research in relation to case studies, which provide “ an in - depth exploration from multiple perspectives of the complexity and uniqueness of a particular project, policy, institution, program or system in real life” [ 6 , p. 21]. We purposefully chose to restrict our selection to case studies only, as we intend to develop practice-based scientific knowledge to narrow the gap between theory and practice in the agile domain [ 7 ]. Accordingly, based on guidance from Webster and Watson [ 8 ], we selected 26 case studies from the agile scaling literature and analyzed them by means of a concept-centric review. The resulting concept matrix contributes to the agile scaling discourse in providing a synthesis of extant research and motivating new research avenues. The remainder of this article proceeds with an examination of previous literature reviews conducted in the agile scaling area. Next, we describe the methods used for data collection and analysis before presenting the result of our systematic literature review. The article concludes by discussing insights for promising directions of future research.

2 Past Literature Reviews on Agile Transformation

For our examination of prior research conducting literature reviews in relation to agile scaling, we identified 9 peer-reviewed publications listed in Table  1 , which shows their publication years, review scopes and types of review. Notably, only three industry specific reviews are included (one related to healthcare, two to software industry), while six studies are comprehensive in scope reviewing agile literature across industries. Besides, only two articles actually use methodologically rigorous literature review guidelines (i.e. systematic reviews), while the others give scarce information on selection criteria and methods of analysis. The most commonly investigated topic is concerned with agile challenges [papers No. 2, 3, 6, 7, 9 in Table  1 ]. Other common topics include agile strategies [papers No. 1 and 4], agile capabilities [papers No. 1, 4, 5], agile success factors [papers No. 3 and 6], agile benefits [papers No. 7, 9], and agile research streams [paper No. 8].

Most commonly identified agile challenges seem not new to organizational change research (e.g. resistance to change, difficulties to plan, changing the culture and lack of investments [ 2 , 16 ]). More recent issues include controversies with the agile framework, struggle to manage agile methodologies, and difficulties to measure agile value, coordinate multiple teams and integrate non-agile functions. Yet, with few exceptions [ 2 , 10 ], previous reviews scarcely formulate emergent research topics associated to agile challenges in practice.

With regard to the topics of agile strategies and capabilities, Tolf and Nyström [ 9 ] highlight proactive, reactive and embracive strategies as well as five core capabilities (inter-organizational links, market sensitivity, self-organizing employees, elastic organic structures, and timely delivery) needed for healthcare organizations to cope with external uncertainty. Besides, Appelbaum et al., in two publications argue that organizational agile transitions require change at all levels (e.g. strategy, processes, and people) while hinting that there is little information on how to develop agile capabilities.

Considerable research has been devoted to point out agile success factors (e.g. management support, customized agile approach, piloting, training, agile coach, communication and transparency, mindset and alignment, team autonomy, culture of continuous learning, and community of practice [ 2 , 13 ]) and agile benefits (e.g. increase in quality, transparency, collaboration, productivity and alignment [ 16 , 17 ]. However, one concern is that most of these success factors and benefits are identified from experience reports that have a tendency to emphasize positive views [ 2 ].

With regard to research streams, the review of Sońta-Drączkowska [ 15 ] proposes five themes, agile in software development, agile in project management, agile organization, hybrid approaches and agile in innovations. The authors recognize that agile concepts are dispersed in a wide range of domains, hence more studies are needed especially to link agile projects with the organizational level [ 15 ].

To summarize, while previous literature reviews have provided helpful insights (especially identifying agile challenges and success factors), there still seems to be gap in prior review work providing an overview on how scholars have covered scaling agile in case studies in relation to how scaling agile is defined, understood and applied.

3 Data Collection

Our data collection follows a rigorous process guided by previous research on conducting systematic literature reviews [ 8 , 18 , 19 ]. We focused article selection on case studies that provide information on agile scaling in a digital transformation context, and, thus address the cross section between management and IS research. To guarantee objectivity in the selection procedure, we developed a research protocol describing the search strategy including the databases used for the search, and inclusion and exclusion criteria (Table  2 ).

Our initial search in databases using filters described in the research protocol resulted in the extraction of 1,073 articles. We controlled for other potential relevant publications that where not found directly from the database search by conducting a backward and forward reference search adding 117 articles potentially in scope. Next, we read the title and abstract of all identified items to remove duplications and studies that are outside the research scope. Further, we read the full text of the remaining articles (157 in total) to evaluate if they met the full criteria described in the research protocol, which resulted in 111 selected items. Of those, 26 articles using a case study methodology were used for our content analysis. Figure  1 illustrates the selection process of the case study articles used for the systematic literature review and outlines the timeframe of their publication. The later shows that from 2016 there has been more effort from research to document agile case studies.

Illustration of the systematic review process and timeframe of the selected case studies

The analysis is based on guidance from Webster and Watson [ 8 ] and consists in synthetizing the selected literature based on a concept-centric morphological box that we developed following the procedure recommended by Mayring [ 22 ]. Correspondingly, we differentiate between three clusters linked with nine main categories as illustrated in Table  3 and describe in the following.

The first cluster, ‘classification of case studies’ aims to portray general aspects of the selected articles and includes the following deductive categories: publication type, literature domain, objective of the study, study design and study focus. With regard to the category ‘publication type’, we differentiate between ‘journal’ and ‘conference’ publication. As noted in the research protocol (see Table  2 ), other publication types have been excluded from the selection. The category ‘literature domain’ indicates the scientific field of each article. The category ‘object of the study’ points out the analytical frame of the case and the various positions that can be taken on the object of the study, differentiating between ‘theory-testing’, ‘theory-seeking’, and ‘storytelling’ [ 23 ]. The category ‘study design’ identifies the temporal structure of how change is studied [ 24 ]. Typically, research studies take either a ‘snapshot perspective’ examining “ a target event in a present moment in time ,” or a ‘process perspective’ examining “ the evolution of an event over time” [ 25 ]. The last category of the first cluster points out that researchers studying an agile transformation process typically focus on one (or a combination) of strategic aspects of change (e.g. culture, leadership, dynamic capabilities), organizational aspects of change (e.g. models of organizing individuals and teams), and/or operational aspects of change (e.g. software development and requirements management) [ 26 ].

The second cluster, ‘comprehension of agile transformation’, focuses on understanding how agile is viewed and investigated from researchers and is composed of the following deductive categories: definition of agile and main topic of the study. The category ‘definition of agile’ aims to grasp how the concept of agile is specified (or not). Extant research typically considers agile either as a method (or an approach) (i.e. stipulating a method-notion) or acknowledge agile as a capability (i.e. stipulating a capability-notion). The category ‘main topic of the study’ is to highlight information about dominant agile themes that have been investigated in prior studies. The third cluster, ‘application of agile transformation’ depicts current application of agile transformation initiatives including two categories: industry type, and organizational size. ‘Industry type’ organizes case studies based on the sector groupings. ‘Organizational size’ distinguishes the case organizations considered in the examined study as either small and medium sized enterprises (SMEs) or large corporations.

The concept matrix of agile transformation resulting from the analysis of the selected literature is presented in Table  4 . The classification of case studies based on their ‘publication type’ reveals a somewhat proportional division between journal (54%) and conference publication (46%). Distinctively, the ‘literature domain’ category shows that agile studies are largely rooted in the Information System field (81%) with a few contributions in the research areas of Strategic Management (8%), Production Management (4%), and Computer Science (4%). Within the ‘object of the study’ category, authors mainly seek for theory - seeking (46%) and storytelling (46%). Much less, only 8% seek for theory - testing [ 27 , 28 ]. With regard to the ‘study design’, most authors follow a process perspective (77%) to structure their investigation, while a snapshot perspective (23%) has been used less [ 29 , 30 , 31 , 32 , 33 , 34 ]. Lastly, the ‘study focus’ category reveals that 19% of the articles consider (fully or partly) all three aspects of the agile transformation (i.e. strategic, organizational, and operational ) [ 32 , 35 , 36 , 37 , 38 ]. Further, 12% have a combined focus on organizational and operational aspects [ 39 , 40 , 41 ], while slightly more articles (19%) have considered strategic and organizational aspects together [ 5 , 16 , 26 , 42 , 43 ]. Lastly, 8% of the articles focus on strategic aspects only [ 31 , 44 ], whilst 15% focus on organizational aspects only [ 33 , 34 , 45 , 46 ].

The analysis highlighting the comprehension of agile transformation in terms of the category ‘definition of agile’ reveals an assertive tendency (42%) to conceptualize (or refer to) agile as a method (or likewise, as an approach). Specific definitions related to this group of articles explain agile as an approach adopted to “ regularly produce high quality software in a cost effective and timely manner via a value driven life-cycle ” [ 41 , p. 4], and agile transformation as the “ switch from a different development approach or work organization concept to agile methods ” [ 5 , p. 3]. On the other hand, 15% of the articles conceptualize agile as a capability . Studies of this kind refer to agility broadly as the ability to move quickly and in a simple way [ 47 ], or somehow more detailed as the capacity to apply agile methods to digital transformations in order to create, react to, embrace, and learn from change while enhancing customer value [ 38 ]. Looking at the ‘main topic’ category, seven archetypes are evident. The dominant topic studied has been agile success factors (46%) followed by agile challenges (31%). In many cases, these two topics have been investigated together [ 26 , 31 , 35 , 41 , 43 , 48 , 49 ]. Further, the topics of agile metrics , agile scaling models , and agile change performance have been equally studied (19%). The least investigated topics have been agile conceptualization and agile roles/teams (12% each).

With regard to analyzing the application of agile transformation in terms of the category ‘industry branch’ six groupings were made. The prevailing setting were the case studies have been conducted is in the telecommunications (31%) branch [ 27 , 28 , 31 , 32 , 44 , 45 , 49 , 50 ]. The second group of cases are dispersed equally in the software industry and financial services (12% each). Some attention has been given to studying agile transformation in education , and mass media (8% each), while only one case could be identified in retail [ 5 ]. In terms of the category ‘organizational size’, there is a clear dominance of articles assessing the transformation in large organizations (92%), whilst the remaining 8% of them explore agile change in SMEs [ 30 , 46 ].

6 Discussion

We discuss our findings in light of recent agile practitioners’ concerns as pointed out by Gregory and Barroca [ 36 ]. Our aim was to identify topics that deserve more attention from research. Accordingly, we spot the three priority areas ‘Governance of Agile Scaling’, ‘Dealing with Legacy Systems’, and ‘Capabilities for the Agile Way’, and elaborate them before pointing out some methodological limitations.

Firstly, extant work has not yet established compelling governance and oversight mechanisms needed to handle agile scaling. This issue is nowadays evermore imperative as agile transformation seems to follow atypical change patterns [ 5 ] and requires a shift from the traditional leadership styles [ 10 , 36 ]. The literature addressing strategic aspects of the transformation, which map to our category ‘study focus’ highlight the importance of defining the necessary goals of the transformation, which require oversight and a customized process model [ 35 , 37 ] as well as developing new roles and requirements for renewed management practices [ 31 , 32 , 42 ]. The governance role is imperative in envisioning, formulating and communicating change facets but recent evidence shows a lot of hurdles in this respect [ 26 ]. Hence, researchers should devote particular attention to develop opportune governance mechanisms that can benefit leaders to guide and control agile transformation initiatives.

Secondly, a critical challenging area with sparse information relates to dealing with legacy systems during the agile transition. Failure to establish a clear approach to handle legacy systems often results in organizations trying to work in an agile way in a non-agile environment (i.e. with traditional organizational structures) [ 36 ]. Surprisingly, when analyzing the ‘Agile main topics’ investigated in previous studies, the legacy system issues seem to be largely overlooked. We call for future work to explore adequate strategies that enable a smooth transition and continuous integration of legacy systems into the agile world.

Thirdly, there is little investigation on the capabilities needed to succeed in the agile way of working. Extant research propounds the view that renewed skills and a quick learning environment are compulsory to absorb agile practices and new organizational forms [ 36 ]. Inevitably, new organizational capabilities at various levels (e.g. ordinary or dynamic) are required at different stages of the agile change. Yet, our findings indicate very little practice-grounded research studies that increase our understanding about this set of new capabilities that benefit agile scaling and subsequently add value to the organization. What is more, apart from a few exceptions [ 26 , 51 ] identified in the intersection between the ‘capability-notion’ and the related ‘conceptualization’ studies in the concept matrix, there seems to be also a lack of theoretical contributions grasping the capability construct in the agile transformation context. Therefore, more research is needed utilizing various lenses (i.e. practical or/and theoretical) to grasp distinct, emergent capabilities vital for the agile journey and to suggest appropriate ways to develop them.

Although our search process included 9 scientific databases, the analysis is limited to 26 selected articles that were found using a case-study methodology. We did not conduct an exhaustive author search, which could have potentially resulted in more selected publications. In attempt to examine highly qualified research findings, we restricted our selection to peer-reviewed papers only. However, nearly half of the selected articles were published in conference proceedings (considered less mature than journal publications). For future investigations within this research stream, more IS journal papers using different methodologies can be considered.

Beck, K., et al.: Manifesto for agile software development (2001). http://www.agilemanifesto . Accessed 31 Oct 2019

Dikert, K., Paasivaara, M., Lassenius, C.: Challenges and success factors for large-scale agile transformations: a systematic literature review. J. Syst. Softw. 119 , 87–108 (2016)

Article   Google Scholar  

Bharadwaj, A., et al.: Digital Business Strategy: Toward a Next Generation of Insights. MIS Q. 37 (2), 471–482 (2013)

Denning, S.: How to make the whole organization “Agile”. Strat. Leadersh. 44 (4), 10–17 (2016)

Fuchs, C., Hess, T.: Becoming agile in the digital transformation: the process of a large-scale agile transformation. In: Thirty Ninth International Conference on Information Systems, San Francisco (2018)

Google Scholar  

Simons, H.: Case Study Research in Practice. SAGE, London (2009)

Book   Google Scholar  

Yin, R.K.: Case Study Research. Sage, Thousand Oaks (2003)

Webster, J., Watson, R.T.: Analyzing the past to prepare for the future: writing a literature review. MIS Q. 26 (2), xiii–xxiii (2002)

Tolf, S., et al.: Agile, a guiding principle for health care improvement? Int. J. Health Care Qual. Assur. 28 (5), 468–493 (2015)

Gregory, P., Barroca, L., Taylor, K., Salah, D., Sharp, H.: Agile challenges in practice: a thematic analysis. In: Lassenius, C., Dingsøyr, T., Paasivaara, M. (eds.) XP 2015. LNBIP, vol. 212, pp. 64–80. Springer, Cham (2015). https://doi.org/10.1007/978-3-319-18612-2_6

Chapter   Google Scholar  

Appelbaum, S.H., et al.: The challenges of organizational agility (part 1). Ind. Commer. Train. 49 (1), 6–14 (2017)

Appelbaum, S.H., et al.: The challenges of organizational agility: part 2. Ind. Commer. Train. 49 (2), 69–74 (2017)

Paterek, P.: Agile transformation in project organization: knowledge management aspects and challenges. In: 18th European Conference on Knowledge Management ECKM2017. International University of Catalonia, Barcelona, Spain (2017)

Abdalhamid, S., Mishra, A.: Adopting of agile methods in software development organizations: systematic mapping. TEM J. 6 (4), 817–825 (2017)

Sońta-Drączkowska, E.: From agile project management to agile organization? – a literature review. Przedsiębiorczość i Zarządzanie 6 (1), 231–242 (2018)

Putta, A., Paasivaara, M., Lassenius, C.: Benefits and challenges of adopting the scaled agile framework (safe): preliminary results from a multivocal literature review. In: Kuhrmann, M., et al. (eds.) PROFES 2018. LNCS, vol. 11271, pp. 334–351. Springer, Cham (2018). https://doi.org/10.1007/978-3-030-03673-7_24

Putta, A.: Scaling agile software development to large and globally distributed large-scale organizations. In: Proceedings of the 13th International Conference on Global Software Engineering, ICGSE 2018, Gothenburg, Sweden (2018)

Tranfield, D., Denyer, D., Smart, P.: Towards a methodology for developing evidence-informed management knowledge by means of systematic review. Br. J. Manag. 14 (3), 207–222 (2003)

Okoli, C., Schabram, K.: A guide to conducting a systematic literature review of information systems research. Sprouts: Work. Pap. Inf. Syst. 10 (26), 1–49 (2010)

Alexander, A., Walker, H., Naim, M.: Decision theory in sustainable supply chain management: a literature review. Supply Chain Manag. 19 (5/6), 504–522 (2014)

Levy, Y., Ellis, T.: A systems approach to conduct an effective literature review in support information systems research. Informing Sci. J. 9 , 181–212 (2006)

Mayring, P.: Qualitative content analysis: theoretical foundation, basic procedures and software solution, Klagenfurt, AT, 143 p. (2014). https://nbn-resolving.org/urn:nbn:de:0168-ssoar-395173

Thomas, G.: A typology for the case study in social science following a review of definition, discourse, and structure. Qual. Inq. 17 (6), 511–521 (2011)

Goldstein, H.: Longitudinal studies and the measurement of change. J. R. Stat. Soc. 18 (2), 93–117 (1968)

Sandelowski, M.: Time and qualitative research. Res. Nurs. Health 22 , 79–87 (1999)

Karvonen, T., Sharp, H., Barroca, L.: Enterprise agility: why is transformation so hard? In: Garbajosa, J., Wang, X., Aguiar, A. (eds.) XP 2018. LNBIP, vol. 314, pp. 131–145. Springer, Cham (2018). https://doi.org/10.1007/978-3-319-91602-6_9

Korhonen, K.: Exploring defect data, quality and engagement during agile transformation at a large multisite organization. In: Sillitti, A., Martin, A., Wang, X., Whitworth, E. (eds.) XP 2010. LNBIP, vol. 48, pp. 88–102. Springer, Heidelberg (2010). https://doi.org/10.1007/978-3-642-13054-0_7

Korhonen, K.: Evaluating the impact of an agile transformation: a longitudinal case study in a distributed context. Softw. Qual. J. 21 (4), 599–624 (2013)

Fry, C., Greene, S.: Large scale agile transformation in an on-demand world. IEEE, Washington, DC (2007)

Capodieci, A., Mainetti, L., Manco, L.: A case study to enable and monitor real IT companies migrating from waterfall to agile. In: Murgante, B., et al. (eds.) ICCSA 2014. LNCS, vol. 8583, pp. 119–134. Springer, Cham (2014). https://doi.org/10.1007/978-3-319-09156-3_9

Chen, R.R., Ravichandar, R., Proctor, D.: Managing the transition to the new agile business and product development model: Lessons from Cisco Systems. Bus. Horiz. 59 (6), 635–644 (2016)

Heikkila, V.T., et al.: Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson. Empir. Softw. Eng. 22 (6), 2892–2936 (2017)

Laanti, M., Delta, N.: Agile transformation model for large software development organizations. In: Proceedings of the XP2017 Scientific Workshops 2017, XP 2017, Cologne, Germany. ACM, New York (2017)

Turetken, O., Stojanov, I., Trienekens, J.J.M.: Assessing the adoption level of scaled agile development: a maturity model for Scaled Agile Framework. Spec. Issue: Recent Adv. Agile Softw. Prod. Dev. 29 (6), 1–18 (2017)

Pikkarainen, M., et al.: Strengths and barriers behind the successful agile deployment—insights from the three software intensive companies in Finland. Empir. Softw. Eng. 17 (6), 675–702 (2012)

Gregory, P., et al.: The challenges that challenge: engaging with agile practitioners’ concerns. Inf. Softw. Technol. 77 , 92–104 (2016)

Jovanović, M., Mesquida, A.-L., Mas, A., Lalić, B.: Towards the development of a sequential framework for agile adoption. In: Mas, A., Mesquida, A., O’Connor, R.V., Rout, T., Dorling, A. (eds.) SPICE 2017. CCIS, vol. 770, pp. 30–42. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-67383-7_3

Mikalsen, M., et al.: Agile digital transformation: a case study of interdependencies. In: Thirty Ninth International Conference on Information Systems, San Francisco (2018)

Cloke, G.: GET YOUR AGILE FREAK ON! Agile adoption at Yahoo! Music. In: Agile 2007. Computer Society, Washington, DC (2007)

Hodgkins, P., Hohmann, L.: Agile program management: lessons learned from the VeriSign managed security services team. In: Agile 2007. IEEE, Washington, DC (2007)

Hobbs, B., Petit, Y.: Agile methods on large projects in large organizations. Proj. Manag. J. 48 (3), 3–19 (2017)

Jovanović, M., et al.: Transition of organizational roles in Agile transformation process: a grounded theory approach. J. Syst. Softw. 133 , 174–194 (2017)

Kalenda, M., Hyna, P., Rossi, B.: Scaling agile in large organizations: practices, challenges, and success factors. Softw. Evol. Process 30 (10), 1–24 (2018)

Doz, Y., Kosonen, M.: The dynamics of strategic agility: Nokia’s rollercoaster experience. Calif. Manag. Rev. 50 (3), 95–118 (2008)

Paasivaara, M., Lassenius, C.: Communities of practice in a large distributed agile software development organization - Case Ericsson. Inf. Softw. Technol. 56 (12), 1556–1577 (2014)

Razzak, M.A., Noll, J., Richardson, I., Canna, C.N., Beecham, S.: Transition from plan driven to SAFe ® : periodic team self-assessment. In: Felderer, M., Méndez Fernández, D., Turhan, B., Kalinowski, M., Sarro, F., Winkler, D. (eds.) PROFES 2017. LNCS, vol. 10611, pp. 573–585. Springer, Cham (2017). https://doi.org/10.1007/978-3-319-69926-4_47

Ganguly, A., Nilchiani, R., School, J.F.: Evaluating agility in corporate enterprises. Int. J. Prod. Econ. 118 (2), 410–423 (2009)

O’Connor, C.P.: Anatomy and physiology of an agile transition. In: Agile Conference. IEEE, Salt Lake City, UT (2011)

Paasivaara, M., et al.: Large-scale agile transformation at Ericsson: a case study. Empir. Softw. Eng. 23 (5), 2550–2596 (2018)

Hallikainen, M.: Experiences on Agile seating, facilities and solutions. In: IEEE Sixth International Conference on Global Software Engineering (2011)

Doz, Y.L., Kosonen, M.: Embedding strategic agility: a leadership agenda for accelerating business model renewal. Long Range Plan. 43 (2–3), 370–382 (2010)

Download references

Author information

Authors and affiliations.

Institute for Information Management and Control, Vienna University of Economics and Business (WU), Vienna, Austria

Everist Limaj & Edward W. N. Bernroider

You can also search for this author in PubMed   Google Scholar

Corresponding author

Correspondence to Everist Limaj .

Editor information

Editors and affiliations.

University of Economics, Prague, Czech Republic

Petr Doucek

TU Wien, Vienna, Austria

Szechenyi University, Gyor, Hungary

Maria Raffai

Antonin Pavlicek

Katrin Detter

Rights and permissions

Reprints and permissions

Copyright information

© 2019 IFIP International Federation for Information Processing

About this paper

Cite this paper.

Limaj, E., Bernroider, E.W.N. (2019). A Systematic Analysis and Synthesis of Case Study Based Agile Scaling Research in the Context of Digital Transformations. In: Doucek, P., Basl, J., Tjoa, A., Raffai, M., Pavlicek, A., Detter, K. (eds) Research and Practical Issues of Enterprise Information Systems. CONFENIS 2019. Lecture Notes in Business Information Processing, vol 375. Springer, Cham. https://doi.org/10.1007/978-3-030-37632-1_7

Download citation

DOI : https://doi.org/10.1007/978-3-030-37632-1_7

Published : 13 December 2019

Publisher Name : Springer, Cham

Print ISBN : 978-3-030-37631-4

Online ISBN : 978-3-030-37632-1

eBook Packages : Computer Science Computer Science (R0)

Share this paper

Anyone you share the following link with will be able to read this content:

Sorry, a shareable link is not currently available for this article.

Provided by the Springer Nature SharedIt content-sharing initiative

• Publish with us

Policies and ethics

Societies and partnerships

• Find a journal
• Track your research

ING’s agile transformation

Established businesses around the world and across a range of sectors are striving to emulate the speed, dynamism, and customer centricity of digital players. In the summer of 2015, the Dutch banking group ING embarked on such a journey, shifting its traditional organization to an “agile” model inspired by companies such as Google, Netflix, and Spotify. Comprising about 350 nine-person “squads” in 13 so-called tribes, the new approach at ING has already improved time to market, boosted employee engagement, and increased productivity. In this interview with McKinsey’s Deepak Mahadevan, ING Netherlands chief information officer Peter Jacobs and Bart Schlatmann, who, until recently, was the chief operating officer of ING Netherlands, explain why the bank needed to change, how it manages without the old reporting lines, and how it measures the impact of its efforts.

The Quarterly : What prompted ING to introduce this new way of working?

Bart Schlatmann biography

Born October 18, 1969, in Bloemendaal, Netherlands

Holds a master’s degree in economic science from Erasmus University Rotterdam

(1995–2017)

ING Netherlands

Chief operating officer

Board member of Bruna, Dutch Payments Association, and WestlandUtrecht Bank

Member of the supervisory board of Interhyp Germany

Bart Schlatmann: We have been on a transformation journey for around ten years now, but there can be no let up. Transformation is not just moving an organization from A to B, because once you hit B, you need to move to C, and when you arrive at C, you probably have to start thinking about D.

In our case, when we introduced an agile way of working in June 2015, there was no particular financial imperative, since the company was performing well, and interest rates were still at a decent level. Customer behavior, however, was rapidly changing in response to new digital distribution channels, and customer expectations were being shaped by digital leaders in other industries, not just banking. We needed to stop thinking traditionally about product marketing and start understanding customer journeys in this new omnichannel environment . It’s imperative for us to provide a seamless and consistently high-quality service so that customers can start their journey through one channel and continue it through another—for example, going to a branch in person for investment advice and then calling or going online to make an actual investment. An agile way of working was the necessary means to deliver that strategy.

The Quarterly : How do you define agility?

Bart Schlatmann: Agility is about flexibility and the ability of an organization to rapidly adapt and steer itself in a new direction. It’s about minimizing handovers and bureaucracy, and empowering people. The aim is to build stronger, more rounded professionals out of all our people. Being agile is not just about changing the IT department or any other function on its own. The key has been adhering to the “end-to-end principle” and working in multidisciplinary teams, or squads, that comprise a mix of marketing specialists, product and commercial specialists, user-experience designers, data analysts, and IT engineers—all focused on solving the client’s needs and united by a common definition of success. This model [see exhibit] was inspired by what we saw at various technology companies, which we then adapted to our own business.

The Quarterly : What were the most important elements of the transformation?

Peter Jacobs biography

Born May 8, 1975, in Heerlen, Netherlands

Holds a PhD in systems engineering from Delft University of Technology

(2013–present)

Chief information officer

Director application management

McKinsey & Company

Associate partner and consultant

(2015–present)

Member of the supervisory board of Equens, a European payment processor

(2015, 2014)

Appeared in the Goudhaantjes top 100, a list of Dutch management talent under 45

Peter Jacobs: Looking back, I think there were four big pillars. Number one was the agile way of working itself. Today, our IT and commercial colleagues sit together in the same buildings, divided into squads, constantly testing what they might offer our customers, in an environment where there are no managers controlling the handovers and slowing down collaboration.

Number two is having the appropriate organizational structure and clarity around the new roles and governance. As long as you continue to have different departments, steering committees, project managers, and project directors, you will continue to have silos—and that hinders agility.

The third big component is our approach to DevOps 1 1. The integration of product development with IT operations. and continuous delivery in IT. Our aspiration is to go live with new software releases on a much more frequent basis—every two weeks rather than having five to six “big launches” a year as we did in the past. The integration of product development and IT operations has enabled us to develop innovative new product features and position ourselves as the number-one mobile bank in the Netherlands.

Finally, there is our new people model. In the old organization, a manager’s status and salary were based on the size of the projects he or she was responsible for and on the number of employees on his or her team. In an agile performance-management model , there are no projects as such; what matters is how people deal with knowledge. A big part of the transformation has been about ensuring there is a good mix between different layers of knowledge and expertise.

The Quarterly : What was the scope of this transformation? Where did you start, and how long did it take?

Bart Schlatmann: Our initial focus was on the 3,500 staff members at group headquarters. We started with these teams—comprising previous departments such as marketing, product management, channel management, and IT development—because we believed we had to start at the core and that this would set a good example for the rest of the organization.

We originally left out the support functions—such as HR, finance, and risk—the branches, the call centers, operations, and IT infrastructure when shifting to tribes and squads. But it doesn’t mean they are not agile; they adopt agility in a different way. For example, we introduced self-steering teams in operations and call centers based on what we saw working at the shoe-retailer Zappos. These teams take more responsibility than they used to and have less oversight from management than previously. Meanwhile, we have been encouraging the sales force and branch network to embrace agility through daily team stand-ups and other tactics. Functions such as legal, finance, and operational risk are not part of a squad per se, as they need to be independent, but a squad can call on them to help out and give objective advice.

It took about eight or nine months from the moment we had written the strategy and vision, in late 2014, to the point where the new organization and way of working had been implemented across the entire headquarters. It started with painting the vision and getting inspiration from different tech leaders. We spent two months and five board off-sites developing the target organization with its new “nervous system.” In parallel, we set up five or six pilot squads and used the lessons to adapt the setup, working environment, and overall design. After that, we were able to concentrate on implementation—selecting and getting the right people on board and revamping the offices, for example.

The Quarterly : Was agility within IT a prerequisite for broader organizational change?

Peter Jacobs: Agility within IT is not a prerequisite for a broader transformation, but it certainly helps. At ING, we introduced a more agile way of working within IT a few years ago, but it was not organization-wide agility as we understand it today, because it did not involve the business. You can certainly start in IT and gradually move to the business side, the advantage of this being that the IT teams can test and develop the concept before the company rolls it out more widely. But I think you could equally start with one value stream, let’s say mortgages, and roll it out simultaneously in the business and in IT. Either model can work.

What you can’t do—and that is what I see many people do in other companies—is start to cherry pick from the different building blocks. For example, some people formally embrace the agile way of working but do not let go of their existing organizational structure and governance. That defeats the whole purpose and only creates more frustration.

The Quarterly : How important was it to try to change the ING culture as part of this transformation?

Bart Schlatmann: Culture is perhaps the most important element of this sort of change effort. It is not something, though, that can be addressed in a program on its own. We have spent an enormous amount of energy and leadership time trying to role model the sort of behavior—ownership, empowerment, customer centricity—that is appropriate in an agile culture. Culture needs to be reflected and rooted in anything and everything that we undertake as an organization and as individuals.

For instance, one important initiative has been a new three-week onboarding program, also inspired by Zappos, that involves every employee spending at least one full week at the new Customer Loyalty Team operations call center taking customer calls. As they move around the key areas of the bank, new employees quickly establish their own informal networks and gain a deeper understanding of the business.

We have also adopted the peer-to-peer hiring approach used by Google. For example, my colleagues on the board selected the 14 people who report to me. All I have is a right of veto if they choose someone I really can’t cope with. After thousands of hires made by teams using this approach at every level in the organization, I have never heard of a single veto being exercised—a sure sign that the system is working well. It’s interesting to note, too, that teams are now better diversified by gender, character, and skill set than they were previously. We definitely have a more balanced organization.

A lot is also down to the new way we communicate and to the new office configuration: we invested in tearing down walls in buildings to create more open spaces and to allow more informal interaction between employees. We have a very small number of formal meetings; most are informal. The whole atmosphere of the organization is much more that of a tech campus than an old-style traditional bank where people were locked away behind closed doors.

The Quarterly : Was a traditional IT culture an impediment to the transformation?

Peter Jacobs: In IT, one of the big changes was to bring back an engineering culture, so there’s now the sense that it’s good to be an engineer and to make code. Somehow over the years, success in IT had become a question of being a good manager and orchestrating others to write code. When we visited a Google IO conference in California, we were utterly amazed by what we saw and heard: young people talking animatedly about technology and excitedly discussing the possibilities of Android, Google Maps, and the like. They were proud of their engineering skills and achievements. We asked ourselves, “Why don’t we have this kind of engineering culture at ING? Why is it that large enterprises in Holland and Western Europe typically just coordinate IT rather than being truly inspired by it?” We consciously encouraged people to go back to writing code—I did it myself—and have made it clear that engineering skills and IT craftsmanship are what drive a successful career at ING.

The Quarterly : Can you say more about the companies that inspired you?

Peter Jacobs: We came to the realization that, ultimately, we are a technology company operating in the financial-services business. So we asked ourselves where we could learn about being a best-in-class technology company. The answer was not other banks, but real tech firms.

If you ask talented young people to name their dream company from an employment perspective, they’ll almost always cite the likes of Facebook, Google, Netflix, Spotify, and Uber. The interesting thing is that none of these companies operate in the same industry or share a common purpose. One is a media company, another is search-engine based, and another one is in the transport business. What they all have in common is a particular way of working and a distinctive people culture. They work in small teams that are united in a common purpose, follow an agile “manifesto,” interact closely with customers, and are constantly able to reshape what they are working on.

Spotify, for example, was an inspiration on how to get people to collaborate and work across silos—silos still being a huge obstacle in most traditional companies. We went to visit them in Sweden a few times so as to better understand their model, and what started as a one-way exchange has now become a two-way exchange. They now come to us to discuss their growth challenges and, with it, topics like recruitment and remuneration.

The Quarterly : Without traditional reporting lines, what’s the glue that holds the organization together?

Bart Schlatmann: Our new way of working starts with the squad. One of the first things each squad has to do is write down the purpose of what it is working on. The second thing is to agree on a way of measuring the impact it has on clients. It also decides on how to manage its daily activities.

Squads are part of tribes, which have additional mechanisms such as scrums, portfolio wall planning, and daily stand-ups to ensure that product owners are aligned and that there is a real sense of belonging. Another important feature is the QBR [quarterly business review], an idea we borrowed from Google and Netflix. During this exercise, each tribe writes down what it achieved over the last quarter and its biggest learning, celebrating both successes and failures and articulating what it aims to achieve over the next quarter—and, in that context, which other tribe or squad it will need to link up with. The QBR documents are available openly for all tribes: we stimulate them to offer input and feedback, and this is shared transparently across the bank. So far, we have done four QBRs and, while we are improving, we still have to make them work better.

In the beginning, I think the regulators were at times worried that agile meant freedom and chaos; that’s absolutely not the case. Everything we do is managed on a daily basis and transparent on walls around our offices.

The Quarterly : Can traditional companies with legacy IT systems really embrace the sort of agile transformation ING has been through?

Peter Jacobs: I believe that any way of working is independent of what technology you apply. I see no reason why an agile way of working would be affected by the age of your technology or the size of your organization. Google and ING show that this has nothing to do with size, or even the state of your technology. Leadership and determination are the keys to making it happen.

The Quarterly : Are some people better suited to agile operating approaches than others?

Bart Schlatmann: Selecting the right people is crucial. I still remember January of 2015 when we announced that all employees at headquarters were put on “mobility,” effectively meaning they were without a job. We requested everyone to reapply for a position in the new organization. This selection process was intense, with a higher weighting for culture and mind-sets than knowledge or experience. We chose each of the 2,500 employees in our organization as it is today—and nearly 40 percent are in a different position to the job they were in previously. Of course, we lost a lot of people who had good knowledge but lacked the right mind-set; but knowledge can be easily regained if people have the intrinsic capability.

Peter Jacobs: We noticed that age was not such an important differentiator. In fact, many whom you may have expected to be the “old guards” adapted even more quickly and more readily than the younger generation. It’s important to keep an open mind.

The Quarterly : How would you quantify the impact of what has been done in the past 15 months?

Bart Schlatmann: Our objectives were to be quicker to market, increase employee engagement, reduce impediments and handovers, and, most important, improve client experience. We are progressing well on each of these. In addition, we are doing software releases on a two- to three-week basis rather than five to six times a year, and our customer-satisfaction and employee-engagement scores are up multiple points. We are also working with INSEAD, the international business school, to measure some of these metrics as a neutral outsider.

The Quarterly : Do you see any risks in this agile model?

Peter Jacobs: I see two main risks. First, agility in our case has been extremely focused on getting software to production and on making sure that people respond to the new version of what they get. If you are not careful, all innovations end up being incremental. You therefore have to organize yourself for a more disruptive type of innovation—and you can’t always expect it to come out of an individual team.

Second, our agile way of working gives product owners a lot of autonomy to collect feedback from end users and improve the product with each new release. There is a risk that people will go in different directions if you don’t align squads, say, every quarter or six months. You have to organize in such a way that teams are aligned and mindful of the company’s strategic priorities.

The Quarterly : What advice would you give leaders of other companies contemplating a similar approach?

Bart Schlatmann: Any organization can become agile, but agility is not a purpose in itself; it’s the means to a broader purpose . The first question you have to ask yourself is, “Why agile? What’s the broader purpose?” Make sure there is a clear and compelling reason that everyone recognizes, because you have to go all in—backed up by the entire leadership team—to make such a transformation a success. The second question is, “What are you willing to give up?” It requires sacrifices and a willingness to give up fundamental parts of your current way of working—starting with the leaders. We gave up traditional hierarchy, formal meetings, overengineering, detailed planning, and excessive “input steering” in exchange for empowered teams, informal networks, and “output steering.” You need to look beyond your own industry and allow yourself to make mistakes and learn. The prize will be an organization ready to face any challenge.

Peter Jacobs is the chief information officer of ING Netherlands; Bart Schlatmann , who left ING in January 2017 after 22 years with the group, is the former chief operating officer of ING Netherlands. This interview was conducted in October 2016 by Deepak Mahadevan, a partner in McKinsey’s Brussels office .

Explore a career with us

Related articles.

Fintechs can help incumbents, not just disrupt them

Agility: It rhymes with stability

Why agility pays

Finished Papers

Amount to be Paid

How will you prove that the drafts are original and unique?

The essay writers who will write an essay for me have been in this domain for years and know the consequences that you will face if the draft is found to have plagiarism. Thus, they take notes and then put the information in their own words for the draft. To be double sure about this entire thing, your final draft is being analyzed through anti-plagiarism software, Turnitin. If any sign of plagiarism is detected, immediately the changes will be made. You can get the Turnitin report from the writer on request along with the final deliverable.

Adam Dobrinich

Johan Wideroos