Agile Digital Transformation: A Case Study of Interdependencies

Abstract

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 transformation. These methods are characterized by autonomous and diverse teams, and experimental development with the aim of achieving faster time-to-market and customer centric digital offerings. While empirical evidence points to positive effects of such methods in smaller projects, we know less about how key aspects of agile work with increasing interdependencies resulting from larger, more complex organization. Driven by our research question-how are interdependencies addressed in agile digital transformation-we contribute by presenting findings from an empirical case study of a bank practicing agile digital transformation. Applying a theoretical lens of dynamic interactions, our findings sensitize us to the necessity of negotiations, and suggest the need for more research on of the role of divergent evaluative principles in agile digital transformation

Full text

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 1
Agile Digital Transformation: A Case Study of
Interdependencies
Short Paper
Marius Mikalsen
SINTEF
Strindveien 4, Trondheim, Norway
marius.mikalsen@sintef.no
Nils Brede Moe
SINTEF
Strindveien 4, Trondheim, Norway
nils.b.moe@sintef.no
Viktoria Stray
University of Oslo and SINTEF
Gaustadalléen 23 B, Oslo, Norway
stray@ifi.uio.no
Helga Nyrud
University of Oslo
Gaustadalléen 23 B, Oslo, Norway
helga.nyrud@gmail.com
Abstract
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 transformation. These methods are characterized by autonomous and diverse
teams, and experimental development with the aim of achieving faster time-to-market
and customer centric digital offerings. While empirical evidence points to positive
effects of such methods in smaller projects, we know less about how key aspects of agile
work with increasing interdependencies resulting from larger, more complex
organization. Driven by our research question - how are interdependencies addressed
in agile digital transformation – we contribute by presenting findings from an
empirical case study of a bank practicing agile digital transformation. Applying a
theoretical lens of dynamic interactions, our findings sensitize us to the necessity of
negotiations, and suggest the need for more research on of the role of divergent
evaluative principles in agile digital transformation.
Keywords: Agile digital transformation, Agile, information system development,
BizDev, negotiations, evaluative principles, empirical case study
Introduction
Accelerating rates of technological change and continuously shifting customer behavior and markets
necessitate information system development (ISD) that is customer centric, iterative, and experimental,
with a fast time to market. 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
(Conboy 2009). While agile methods have traditionally been practiced within ISD teams and in smaller
and low-risk projects, the current prominence of digital technology as a key enabler for organizational
change and growth is moving agile beyond ISD teams and into larger projects and programs (Dikert et al.
2016). By agile digital transformation we understand that agile methods get higher strategic significance
and necessitates that these methods be adapted to fit more complex organizational environments (Khan
et al. 2016). This complexity comes from increased interfacing between complementary roles on ISD
teams, between agile ISD teams, and between agile ISD teams and other organizational units (Dikert et al.
2016). Foundational to agile ISD methods are team autonomy (i.e., self-directedness and self-
organization) and diversity (i.e., complementary actors, roles, and competencies) (Lee and Xia 2010).

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 2
While agile methods have shown success in smaller projects, less is known about the agile digital
transformation of large ISD programs, where increased autonomy and diversity imply a significant
increase in the number of interdependencies between actors, tasks, and goals (Jiang et al. 2018).
In this work, we seek insight into how agile digital transformation with autonomous and diverse teams
works empirically to address interdependencies. Therefore, our research question is as follows: how are
interdependencies addressed in agile digital transformation? To investigate this question, we adopt a
dynamic perspective of interdependencies (Elbanna 2010), which suggests that the continuous
negotiation of boundaries within teams, and between teams and the rest of the organization, contributes
to ISD project success. This is in line with insights from studies of complex projects and larger ISD
programs, which discuss the need to address interdependencies (Jiang et al. 2018) and potential conflicts
(Jiang et al. 2014). Using the dynamic perspective, we examine a digital transformation program in a
Norwegian bank that applies agile (Lee and Xia 2010) and BizDev (Fitzgerald and Stol 2017) methods to
increase autonomy and diversity in its ISD. Our analysis illustrates negotiation of boundaries, both within
teams and between teams and the wider organization. In doing so, we aim to i) show how current digital
transformation implies more complex agile projects and programs that include the wider organization
beyond development, what we call agile digital transformation, ii) exemplify the interdependencies that
arise in agile digital transformations and the negotiations that follow, and iii) discuss the need for further
theorizing about how autonomy and diversity are negotiated in agile digital transformation.
The rest of the article is organized as follows. In the next section, we outline our perspective on agile
digital transformation and signify the need to focus on negotiations. Section 3 introduces the case, shows
how the bank is engaged in agile digital transformation, and outlines our empirical approach to studying
negotiations. Section 4 presents the findings, which exemplify interdependencies and forms of
negotiation. Finally, Section 5 discusses these findings and suggests avenues for additional research on
negotiation in agile digital transformations.
Theory: Agile Digital Transformation and Negotiation
Current digital transformation requires organizations to continuously adjust how they interact with
customers, define digital value propositions, use data, and organize operations (Jöhnk et al. 2017). The
accelerating rate of technological change and volatile markets leads to a need for faster time-to-market,
customer-centric, iterative, and experimental ISD (Bharadwaj et al. 2013; Horlach et al. 2016).
Agility is the continual readiness of an ISD method to create, embrace, and learn from change while
contributing to customer value through its collective components and relationships with its environment
(Conboy 2009). Team autonomy and diversity is reported to be key to achieving agility (Lee and Xia
2010). Autonomous—that is, self-organized, self-directed, and self-disciplined—teams are necessary for
achieving ISD agility (Highsmith 2004; Nerur and Balijepally 2007). Diversity is defined as the
heterogeneity of actors involved in ISD in terms of characteristics such as education, functional role, and
technical abilities (Williams and O’Reilly 1998). For example, including both business representatives and
software developers in the agile ISD team increases the diversity. A key principle in Agile ISD is to deliver
working software to users at regular short intervals. By frequently gaining feedback from customers, the
chance of delivering customer value increases. In practice, this requires a close and continuous linkage
between business and software development. The process of continuously assessing and improving this
link is described as BizDev (Fitzgerald and Stol 2017).
Current digital transformation requires adopting agile methods in larger projects or programs, which
involves increased interfacing with complementary organizational roles, having several teams, more inter-
team coordination, and interaction with other organizational units (Dikert et al. 2016). This represents a
challenge, as the application of agile practices to large-scale and more transformative projects is known to
be problematic and requires adaptation and tailoring to fit more complex environments (Kruchten 2013).
We need to grasp how autonomy and diversity, key foundations of agile methods, work in wider, more
formal, document- and plan-driven organizational environments. A recent review of large-scale agile
transformations demonstrated how dealing with interdependencies—that is, relating multiple teams,
working across organizational boundaries, and effectively integrating non-IT functions (such as business
development or customer service)—is a key challenge to the successful agile transformation of
organizations (Dikert et al. 2016). Interdependencies result from the relationships created by employing

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 3
multiple organizational groups in ISD (Jiang et al. 2018) and include the following: i) outcome
interdependence, which considers goals and rewards, such as how teams are rewarded, ii) means
interdependence, which addresses the necessary sharing of common resources, such as expertise, and iii)
boundary interdependence, which represents the personal relationships across groups, such as cross-
functional membership. We take our cue about how such interdependencies can be addressed from
Elbanna (2010), who demonstrated that interdependencies are not merely an undesirable consequence of
increased complexity. Instead, dynamically interacting with other entities in the organization and
bypassing boundary structures initially set up by the management contribute to ISD project success.
Dynamic interaction involves a continuous negotiation of boundaries “as different organizational actors
emerge to renegotiate the previously set boundaries” (Elbanna 2010, p. 25).
To grasp diversity and autonomy in agile digital transformation, there is therefore a need for more
empirical insight into how interdependencies are negotiated. Aiming to contribute to such an
understanding, we discuss how a further refinement of negotiations should consider how action,
particularly innovative action, is not rooted in convergence or agreement on a single principle of
justification, but by the divergence of evaluative principles (Stark 2017). Forcing convergence can be
detrimental to an organization´s capacity for creating, learning and responding to change. Such capacities
are key to agile ISD, and should remain so in agile digital transformation.
Method
Case Context: Drivers of Agile Digital Transformation
Many organizations currently need to respond to digital changes and must compete in an increasingly
digital marketplace. Banks are at the forefront of such transformations, dealing with legacy IT systems
and heavy legacy processes. Banks are also under significant compliance requirements, which challenges
their capacity to experiment freely. Yet “digitalization hits at the core of a bank—i.e., the digitalization of
money and all the related functions around money” (Sia et al. 2016). The European payment service
directive (PSD2) is requiring banks to open parts of their payment infrastructure to third-party providers,
and a more open market increases competition. Furthermore, social computing, big data, the internet of
things, and cloud computing enable financial services to move beyond the automation of services and
instead provide entirely new products and services, which in turn changes business models (Puschmann
2017). In addition to these technological changes, consumer behavior is changing. Following new
regulations for open banking, being an account aggregator and creating a superior user experience has
now become crucial.
Case Background: Agile BizDev Teams
The organization analyzed in this study is a Nordic bank, pension, and insurance organization with more
than 2,000 employees, here known as NorBank (a pseudonym). At the beginning of 2014, as we entered
the case, their IT development unit was organized in a hierarchical and modular structure. Within this
structure, there were units based upon the modules constituting their digital portfolios, such as business
relationship management, banking and insurance, and digital and mobile. In this period, NorBank was
deploying a new program that was transforming the way the IT development unit delivered digital
offerings in the bank. Instead of having technical modules as the central organizing concept, they moved
toward a delivery model consisting of five delivery streams (e.g., insurance, banking, pension). The goal of
the program was to implement a new delivery model for digital solutions. Effects the program sought
included giving development clearer frames regarding resources (i.e., hours), a more unified prioritization
of tasks, rapid delivery, stable team participation, a unified development method, and a predictable
frequency for prioritized deliverables.
During evaluations one year into the program, it became clear that a key challenge was the separation of
business development and IT development, including the organizing principle that business developers
prioritize what the IT developers should deliver without involving IT developers. Further, the business
side was complex, involving many decision-makers, many stakeholders on the business development side,
and, accordingly, many challenges to coordinating prioritization. There were also challenges related to the
fact that the development teams consisted exclusively of IT developers and testers; for example, the
specifications for digital solutions were being created by business developers who were not on the IT

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 4
team. IT development relied on Scrum, an iterative method in which the team began with a planning
meeting and subsequently met daily for two to three weeks, presenting what they have delivered at a
demo meeting after that time. When IT development started solving tasks that were put into a sprint
(iteration), they soon discovered that the tasks were different (e.g., in terms of complexity, size, or number
of dependencies on other sub-systems) than what was originally planned for by the business development
side. As a consequence, IT development did not deliver what the business side had expected at the end of
a sprint, causing business development to begin to lose trust in IT development. Further, because the
business developers were often not aligned or not available, IT development seldom got fast feedback
when they discovered that a feature or design needed to be changed, causing IT development, in turn, to
lose trust in the business side. The result of all these challenges was that the process from identifying a
feature to delivering the feature took much longer than necessary.
To solve these challenges, NorBank decided to create agile BizDev teams consisting of business
representatives from business development and IT developers, testers, and user experience (UX)
designers from IT development to achieve a continuous process of planning and execution. The new
teams also recieved increased authority to specify solutions and prioritize development tasks. The teams
were given the responsibility to achieve a growth goal/market share on the service for which they were
responsible, and they could prioritize their resources accordingly to achieve this goal. We focused our
study on these teams and their interactions with the wider organization, as we report in the findings
section.
Data Collection and Analysis
As this is an ongoing longitudinal qualitative case study, we are continuously collecting new data. All
authors are involved in the data collection, and we are using three main data sources (see Table 1). First,
we conducted eleven semi-structured interviews, focusing on how collaboration in ISD occurs in the bank
and clarifying interesting aspects we observe in practice. The second data source is observational data,
which includes participatory observations of teams in NorBank since June 2014. We observed several
meetings and conducted more engaged research by performing retrospectives with the teams, helping
them to find practical—yet theoretically informed—solutions to the challenges they faced. Additionally, we
have participated in informal talks over lunch and coffee breaks. Documents, such as plans and reports,
are our third data source.
Data source
Volume
Description
Interviews
11
We conducted semi-structured interviews with open-ended
questions. We interviewed all roles listed in Table 2. The
average length of the interview was 45 minutes. All the
interviews were audio recorded and transcribed.
Observation of meetings
24
We observed daily stand-up meetings (12), retrospective
meetings (2), planning meetings (1), weekly meetings (2),
and other meetings (7). We made notes from all the
observed meetings.
Documents
15
We collected documents such as plans, strategy reports,
progress reports, evaluations, and sketches and designs of
systems.
Table 1. Data Sources and Descriptions
An interpretive approach guides our data analysis process, putting the practitioners’ understandings of
reality at the center of our analysis (Walsham 1995). We subscribe to the principles proposed by Klein and
Myers (1999), a key principle of which is the hermeneutic circle. The hermeneutic circle helps to account
for the interdependent meaning of the parts (e.g., the participants’ understandings) and the whole that
they form (e.g., the meanings emerging from the interactions between the parts). We follow this principle
in our data analysis and sensemaking strategy by following an inductive–deductive approach. Our initial

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 5
analysis of the case material indicated many interdependencies taking many different forms; as such,
interdependencies in large-scale ISD projects (Jiang et al. 2018) and dynamic interaction (Elbanna 2010)
was identified as a sensible theoretical lens through which to interpret the empirical material (Walsham
1995). Our findings illustrate the interdependencies and negotiations occurring in NorBank, including
boundary interdependence (cross-functional memberships in BizDev teams), the negotiation of goals due
to outcome interdependence, and the negotiation of resources due to means interdependence. Using the
lens of dynamic interaction, our data indicates that negotiating interdependencies is a continuous and
ongoing process. Walsham (1995) underlines how interpretive researchers must remain open to new ideas
from the field data, and we later discuss how justification in these negotiations is a concern that merits
future research.
Findings
Cross-Functional Memberships: Creating BizDev Teams
“Change is needed to better serve our customers. We need to change the way we work to ensure that we
can serve our customers with what they want in a timely manner” (NorBank documents).
The merging of business representatives and IT developers at NorBank into teams began in February
2016. These new BizDev teams delivered software into the delivery streams. They were co-located and
consisted of the roles described in Table 2, below. One team included 13 members, and the other included
14 members. The intention behind creating more diverse, cross-functional teams was to reduce the
boundaries between business developers and IT developers, as outlined in the case background.
Table 2. An Example BizDev Team in NorBank
The teams exercised autonomy by shaping how they worked, and they chose to work according to the
Kanban method, also using some Scrum ceremonies such as the daily stand-up meeting (Stray et al.
2018). While Scrum divides work into a series of fixed-length iterations (called sprints, in which whatever
is scheduled for a sprint is the team’s top priority), Kanban aims to enable flexible planning, because
whatever is on the board is the top priority, and enables teams to focus on continuous delivery with
changing priorities. Kanban was considered a better approach because the team had difficulty estimating
the total amount of work they were able to complete in a sprint as a result of all the dependencies upon
Role
Description
Project manager
Responsible for the planning and execution of the projects on which the team’s
developers are working.
Manager
Unit leader with commercial responsibility for the team. Keeps track of the
team’s stakeholders, is responsible for the direction of the team, and has human
resources (HR) responsibilities.
Business
developer
Knows the market and users’ needs, and is responsible for proposing products or
services as solutions to problems and needs in the market.
Digital
responsible
Has expertise in the field of business and knows how to develop a business
through digital technology. Has insight into how customers use digital
technology and knowledge of different technologies.
Digital designer
Works to design the user interfaces of the products that the business developer
and digital responsible propose. Has experience with UX design.
Team lead
Responsible for the other IT developers on the team. Tries to protect developers’
time by filtering and routing external requests.
Tech lead
Responsible for having a general knowledge of the technologies used and an in-
depth knowledge of their service’s application programing interfaces (APIs).
Test lead
Responsible for testing the software that the team develops.
IT developer
Both front-end and back-end developers.

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 6
other stakeholders. Further, because of the continuous dialogue between the business developers and IT
developers within the team, priorities changed often. Before introducing the BizDev team, the business
developers were responsible for describing the end user behavior for a new feature and would then hand
the description over to the IT development team. Now, the BizDev team introduced a technique called
user story mapping, which sought to describe the user’s journey through the product by building a simple
visual model. The team frequently conducted user story mapping sessions, involving all functions of the
team.
Negotiating Outcomes Within Teams
Working in co-located BizDev teams facilitated easy access to the different competences and an arena in
which the team members could discuss tasks and solutions. Being co-located enabled valuable informal ad
hoc conversations, as indicated by a business developer commenting on where most collaboration
between business and IT developers took place:
I would say that it is mostly informal collaboration. We make decisions along the way, while we
work on our tasks, when it is needed. That is our largest arena for collaboration, I believe. If there is
something which is under development, and an issue occurs, it happens that we deal with it
informally by talking with the developers about solving it differently. (Interview, Business Developer)
Informal collaboration does not imply agreement, and negotiations did occur within the teams. First, it
quickly became evident after the BizDev teams were formed that different roles had different needs in
terms of how they perform their tasks. For example, business developers appreciated a very open work
area that allowed for discussions and offered temporary seats for guests. IT developers, in contrast,
wanted to have designated seats because their desktop computers contained specific hardware and
multiple monitors; in addition, they needed a quiet working zone and wanted to protect their time to
focus on technical programming tasks.
Second, the value of the daily stand-up meeting was questioned. Although the team shared an overarching
goal of growth in the products they delivered, different roles had different goals, and several team
members indicated that they were not fully aware of what the other team members were working on:
“Everyone in the team work with different applications, so there is not much valuable information really. I
think there’s too little discussions regarding obstacles or opportunities to receive help, it’s more like giving
a status report” (Interview, IT Developer). Instead of being a forum for working out challenges together,
the daily stand-up was considered a status meeting. While the project manager appreciated these
moments of insight into the status of the team’s tasks, IT developers reported less value from these
meetings. One consequence of cross-functional memberships is an increase in goal and task diversity,
even though the organization considers them to be one team, the team shares an overarching goal, and
they are all completing agile team practices.
Negotiating Means Crossing Team Boundaries
In addition to negotiating outcomes internally in teams, interdependencies also existed across teams.
Although team autonomy was a clearly stated goal, each team’s tasks and prioritizations had to be
negotiated with the other parts of the NorBank organization.
A project manager explained to us that it is important for the team to ground their development work
within the program management using “target specifications,” which include the specification of tasks and
results, who should work on the task, how much it is going to cost, and what technology is required from
their platform:
We are working on a target specification, describing where we want to go with our customer
solutions. We have a dedicated architect and a dedicated UX designer… we used to be a reception for
requests from the business department, while now we get to create our own target specification.
Although the overall prioritizations are done up there, we at least have a target specification.
(Interview, Project Manager)
The need to receive commitment from stakeholders for team activities is also indicated in the following
excerpt from an experience report that was part of the evaluation of the program: “Frames, financial and
resources: 1) Get this nailed and locked as quickly as you can. 2) Get clear commitment concerning

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 7
resources from relevant stakeholders. 3) There is a tendency that this will surface repeatedly in different
settings” (NorBank documents).
Negotiations also occurred with other departments. The business developers on the team had regular
meetings with the sales department, marketing department, and product department. In general, all these
departments were interested in the solutions that the teams created because the departments were
affected, either directly or indirectly, by changes to the company’s product portfolio. The meetings with
the sales department were held for a mutual exchange of information. The sales department had to
understand changes to their products, not only because the solutions were created for their customers but
also because the sales department, including customer service, would use the solutions themselves.
Moreover, the sales department informed the business developers of what they typically were talking to
the customers about in order to provide them with insight into customer issues and needs. Similarly, the
marketing department had to be aware of the new solutions developed by the team in order to launch and
promote them to customers. The project manager expressed this importance, stating that the marketing
department is their most important stakeholder:
There is a lot of contact with the marketing department, because they are the ones launching the
systems that we create. The might have very strong opinions on what the solutions should look like.
Therefore, we try to have very regularly scheduled meetings with them in order to understand each
other and build trust. There is a lot of coordination with them. (Interview, Business Developer)
Discussion and Directions for Future Work
Digitalization is currently a key driver of organizational transformation. Agile methods (Lee and Xia
2010) and BizDev teams (Fitzgerald and Stol 2017) are among the practical methods used for managing
digital transformation. While empirical evidence points to the positive effects of such methods in small
projects (Lee and Xia, 2010), we know less about how autonomy and diversity in teams work as the
methods are scaled up to meet the wider organization (Dikert et al. 2016). Driven by our research
question about how interdependencies are addressed in agile digital transformation, we have presented
findings from an ongoing case study of a Nordic bank currently in the midst of agile digital
transformation. Applying a theoretical lens of dynamic interactions (Elbanna 2010), the findings
exemplify the kind of negotiations that follow from increased interdependencies (Jiang et al. 2018) and
suggest the need for research that focuses on the role of diverse evaluation criteria within these
negotiations.
NorBank adopts both agile and BizDev methods in their transformation program. The key rationale for so
doing is to achieve greater autonomy and diversity in the organization of their ISD (Lee and Xia 2010).
Autonomy involved increasing levels of self-organizing teams, including specifying and prioritizing
development tasks, and self-directedness (Nerur and Balijepally 2007). Diversity, in NorBank’s case,
required the creation of BizDev teams working closely with other teams and units within the organization.
The combination of autonomy and diversity is considered necessary for achieving sufficient flexibility and
greater speed in the face of accelerating rates of technological, regulatory, end-user, and market changes.
However, by increasing autonomy and diversity in teams, NorBank now faces a new set of challenges
concerning the interdependencies that have been created.
While co-locating different roles in teams helped in achieving more informal collaboration, negotiations
persisted within the team. In terms of collaboration within the team, business developers considered it
meaningful to have a continuous dialogue within, while IT developers reported the need for protected
time in which to focus on complex technical tasks without interruptions. Further, despite working in one
team, different roles still worked on unique tasks, different products, and striving toward different goals.
As a consequence, some of the agile practices did not work. The daily Scrum meetings, intended as a
forum for group problem solving, instead became a forum for collecting status reports.
Such findings indicate how diversity in the BizDev teams spurred negotiations about team goals and
outcomes, which add support to IS research on ISD projects that indicates disagreement within teams
about project goals (Andres ad Zmud 2001) and about the content of tasks (Liang et al. 2012). This raises
the question on whether or not highly diverse and cross-functional teams still can be considered teams
according to the definition: “a small number of people with complementary skills who are committed to a
common purpose, set of performance goals, and approach for which they hold themselves mutually

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 8
accountable” (Katzenback and Smith 1993). When we asked NorBank BizDev team members whether the
team had a shared goal, most team members answered in the affirmative, but few could clearly articulate
the goal. Still, the team members knew who was on the team, and they held themselves mutually
accountable for the team´s performance. One possible interpretation of these findings is that diverse and
cross-functional BizDev teams constitute a negotiation space (Elbanna 2010), where heterogeneous team
members define one another in their interaction, over time reaching a better understanding for which
tasks and goals are inside and which fall outside the team boundaries.
Autonomy on the team level, although stated as a specific goal of the program, was not a granted as soon
as the BizDev teams were created. Rather, the BizDev teams at NorBank needed to negotiate means with
other teams, organizational units such as sales and marketing, and key management stakeholders. We
found that the “target specification” was used to rally support for a team’s activity towards the program
management. Setting up clear financial and resource specifications was a key concern, as this would be
questioned and evaluated. Regular meetings with both the sales and marketing departments were
necessary to ensure that the digital offerings made sense in terms of both users’ needs and company
revenue. In larger ISD programs several teams will compete for management support (Elbanna 2013).
Teams can gain support through active mobilization and alignment efforts, e.g. using material artefacts
such as the “target specification”, communication tools, and demonstrating produced digital offerings.
Knowledge about how larger and more complex agile programs can manage interdependencies to improve
coordination and promote team diversity and autonomy is currently “very limited” (Jiang et al. 2014). The
forms of negotiation within and between teams, and between teams and the wider organization that our
findings illustrate, therefore, point toward some relevant avenues for future research into the mechanisms
that facilitate and constrain negotiations in agile digital transformation. Elbanna (2010) argues that a key
aspect of negotiation is to recruit different actors who can contribute to ISD project success. Future
research can detail the empirical workings of such recruitment, be that on teams, between teams, or
between teams and other units in the organization. Teams recruiting allies and mobilizing support can be
considered as critical situations in the development process. Situations are considered critical when the
outcome of a situation is not possible to determine in advance, such as; Who in customer relations should
I pay attention to? Will the management board approve our specification? Will my team members agree
on my suggested new feature? Will the demonstration convince sales? Stark (2017) argues that in critical
situations, action is not necessarily facilitated by convergence or agreement on a single principle of
justification, but rather by a divergence of evaluative principles: “Disagreement about what´s valuable can
make for new value propositions” (ibid., p. 388). As we have shown, autonomy and diversity in more
complex ISD programs will increase interdependencies on means, goals and boundaries. ISD
organizations will therefore necessarily have, and potentially may benefit from, the friction between
evaluative principles. Interesting research themes emerge concerning when, where and by whom
evaluations are done? What are the restrictions to divergent evaluative principles? Can these evaluations
be managed? What are the ISD contexts under which the friction of different evaluative principles can
become constructive? Answering such questions should add relevant insight into how interdependencies
are addressed and can help explain how autonomy and diversity in agile digital transformation is
practically feasible.
Acknowledgements
This work was supported by the Research Council of Norway under grant 267704.
References
Andres, H. P., and Zmud, R. W. 2001. “A Contingency Approach to Software Project Coordination,”
Journal of Management Information Systems (18:3), pp. 41-71.
Bharadwaj, A., El Sawy O. A., Paviou, P. A., and Venkatraman, N. 2013. “Digital Business Strategy:
Toward a Next Generation of Insights,” MIS Quarterly (37:2), pp. 471-482.
Conboy, K. 2009. “Agility from First Principles: Reconstructing the Concept of Agility in Information
Systems Development,” Information Systems Research (20:3), pp. 329-354.

Interdependencies in Agile Digital Transformation
Thirty Ninth International Conference on Information Systems, San Francisco 2018 9
Dikert, K., Paasivaara, M., and Lassenius, C. 2016. “Challenges and Success Factors for Large-Scale Agile
Transformations: A Systematic Literature Review,” Journal of Systems and Software (119),
pp. 87-108.
Elbanna, A. 2010. “Rethinking IS Project Boundaries in Practice: A Multiple-Projects Perspective,” The
Journal of Strategic Information Systems (19:1), pp. 39-51.
Elbanna, A. 2013. “Top management support in multiple-project environments: an in-practice
view,” European Journal of Information Systems, (22:3), pp. 278-294
Fitzgerald, B., and Stol, K. J. 2017. “Continuous Software Engineering: A Roadmap and Agenda,” Journal
of Systems and Software (123), pp. 176-189.
Highsmith, J. 2004. Agile Project Management, Boston, MA: Addison-Wesley.
Horlach, B., Drews, P., and Schirmer, I. 2016. “Bimodal IT: Business-IT Alignment in the Age of Digital
Transformation,” in Multikonferenz Wirtschaftsinformatik (MKWI), pp. 1417-1428.
Jiang, J. J., Chang, J. Y., Chen, H. G., Wang, E. T., and Klein, G. 2014. “Achieving IT Program Goals with
Integrative Conflict Management,” Journal of Management Information Systems (31:1), pp. 79-106.
Jiang, J., Klein, G., and Fernandez, W. 2018. “From Project Management to Program Management: An
Invitation to Investigate Programs Where IT Plays a Significant Role,” Journal of the Association for
Information Systems (19:1), pp. 40-57.
Jöhnk, J., Röglinger, M., Thimmel, M., and Urbach, N. 2017. “How to Implement Agile IT Setups: A
Taxonomy of Design Options,” in Proceedings of the 25th European Conference on Information
Systems (ECIS), Guimarães, Portugal, pp. 1521-1535.
Katzenback, J. R., and Smith, D. K. 1993. “The Discipline of Teams,” Harvard Business Review.
Khan, M. R., Fernandez, W. D., and Jiang, J. J. 2016. “Is There Such a Thing as Agile IT Program
Management?” International Research Workshop on IT Project Management 2016.
http://aisel.aisnet.org/irwitpm2016/4
Klein, H. K., and Myers, M. D. 1999. “A Set of Principles for Conducting and Evaluating Interpretive Field
Studies in Information Systems,” MIS Quarterly (23:1), pp. 67-93.
Kruchten, P. 2013. “Contextualizing Agile Software Development,” Journal of Software: Evolution and
Process (25:4), pp. 351-361.
Lee, G., and Xia, W. 2010. “Toward Agile: An Integrated Analysis of Quantitative and Qualitative Field
Data on Software Development Agility,” MIS Quarterly (34:1), pp. 87-114.
Liang, T. P., Wu, J. C. H., Jiang, J. J., and Klein, G. 2012. “The Impact of Value Diversity on Information
System Development Projects,” International Journal of Project Management (30:6), pp. 731-739.
Nerur, S., and Balijepally, V. 2007. “Theoretical Reflections on Agile Development Methodologies,”
Communications of the ACM (50:3), pp. 79-83.
Puschmann, T. 2017. “Fintech,” Business & Information Systems Engineering, (59:1), pp. 69-76.
Sia, S. K., Soh, C., and Weill, P. 2016. “How DBS Bank Pursued a Digital Business Strategy,” MIS
Quarterly Executive (15:2).
Stark, D. 2017. “For What It’s Worth,” in Justification, Evaluation and Critique in the Study of
Organizations: Contributions from French Pragmatist Sociology, C. Cloutier, J. -P. Gond, and B.
Leca (eds.), Bingley, UK: Emerald Publishing Limited, pp. 383-397.
Stray, V., Moe, N. B., and Sjøberg, D. I. K. 2018, in press. “Daily Stand-Up Meetings: Start Breaking the
Rules,” IEEE Software.
Walsham, G. 1995. “Interpretive Case Studies in IS Research: Nature and Method,” European Journal of
Information Systems, (4:2), pp. 74-81.
Williams, Y., and O’Reilly, C. A. 1998. “Demography and Diversity in Organizations: A Review of 40 Years
of Research,” in Research in Organizational Behavior, M. Staw and L. L. Cummings (eds.),
Greenwich, CT: JAI Press, pp. 77-140.