Balancing Autonomy and Control: An Adaptive Approach for Security

Governance in Large-Scale Agile Development

Sascha N

agele, Nathalie Schenk, Nico Fechtner and Florian Matthes

School of Computation, Information and Technology, Technical University of Munich, Germany

Keywords:

Large-Scale Agile Development, Security, Governance, Compliance.

Abstract:

Companies are increasingly adopting agile methods at scale, revealing a challenge in balancing team au-

tonomy and organizational control. To address this challenge, we propose an adaptive approach for security

governance in large-scale agile software development, based on design science research and expert interviews.

In total, we carried out 28 interviews with 18 experts from 15 companies. Our resulting approach includes

a generic organizational setup of security-related roles, a team autonomy assessment model, and an adaptive

collaboration model. The model assigns activities to roles and determines their frequency based on team au-

tonomy, balancing the autonomy-control tension while ensuring compliance. Although framework-agnostic,

we applied our approach to existing scaling agile frameworks to demonstrate its applicability. Our evaluation

indicates that the approach addresses a signiﬁcant problem area and provides valuable guidance for incorpo-

rating security into scaled agile environments. While the primary focus is on security governance, our insights

may be transferable to other cross-cutting concerns.

1 INTRODUCTION

Driven by the success of agile software development

(ASD) methodologies, the application of agile ap-

proaches at scale has seen a marked increase (Uluda

et al., 2022). Scaling such development efforts is

complex, particularly when there are stringent quality

requirements to be met (Kalenda et al., 2018). This

complexity raises the issue of balancing team auton-

omy and decentralized decision-making against the

necessity for organizational control and alignment in

large-scale agile development (LSAD) (N

agele et al.,

2022).

Concurrently, security, a paramount information

systems and software quality requirement, is growing

in signiﬁcance due to increasing threats and resulting

regulatory requirements (Tayaksi et al., 2022; Moy

et al., 2021). This trend intensiﬁes the tension be-

tween autonomy and control, elevating security gov-

ernance and compliance to a critical concern in LSAD

(Moy

on et al., 2021).

Existing research indicates that established scal-

ing agile frameworks neither adequately incorporate

security activities nor provide sufﬁcient guidance on

security and security compliance (Edison et al., 2021;

agele et al., 2023). For instance, D

annart et al.

(2019) observe that security is frequently treated as an

isolated concern, and there is a deﬁciency in “know-

ing where to conduct which security activity in a large

scale agile process” (p. 531). Moy

on et al. (2021)

suggest that adapting scaling frameworks, e.g., by in-

troducing additional roles, may be beneﬁcial. In ad-

dition, based on a systematic literature review and ex-

pert interview study, N

agele, Schenk, and Matthes

(2023) propose employing inﬂuencing factors such

as product risk and team maturity to tailor gover-

nance and control mechanisms, thereby alleviating

the identiﬁed tension and enabling increased auton-

omy and responsibility for more proﬁcient teams. De-

spite these advances, guidance on how to establish

a suitable balance between autonomy and control is

lacking.

To ﬁll this research gap, we propose an adap-

tive approach that aims to enable agile team auton-

omy while maintaining effective development control

without imposing unnecessary burdens. Our primary

goal is to establish a balance between agility and (se-

curity) governance, resulting in a clear secure soft-

ware development process that is systematic, trans-

parent, and auditable, while ensuring compatibility

with agile environments at scale. We aim to achieve

this integration by emphasizing collaboration, contin-

uous improvement, and team autonomy.

Our research question (RQ) is: How can secu-

Nägele, S., Schenk, N., Fechtner, N. and Matthes, F.

Balancing Autonomy and Control: An Adaptive Approach for Security Governance in Large-Scale Agile Development.

DOI: 10.5220/0012605000003690

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 26th International Conference on Enterprise Information Systems (ICEIS 2024) - Volume 2, pages 17-28

ISBN: 978-989-758-692-7; ISSN: 2184-4992

rity governance be integrated into LSAD while ensur-

ing adaptability to achieve a suitable equilibrium be-

tween autonomy and control?

In the pursuit of answering our RQ, we developed

an adaptive approach using design science research

(DSR) and expert interviews.

The approach systematically adapts autonomy by

considering key inﬂuencing factors such as product

risk and the capability of agile development teams,

granting higher autonomy to more mature teams. It

also proposes an organizational setup to foster secu-

rity collaboration in agile environments at scale.

The paper is structured as follows. Section 2 cov-

ers background and related work. Section 3 explains

our research method. Section 4 introduces our adap-

tive approach for security governance in LSAD, eval-

uated in Section 5. Sections 6 and 7 discuss our ﬁnd-

ings and conclude our research.

2 BACKGROUND AND RELATED

WORK

The following section summarizes the most important

deﬁnitions as well as the existing challenges and so-

lutions that are relevant to our RQ.

2.1 Security Governance and

Compliance

When using the term governance, we mainly refer

to the domain of information security governance,

which encompasses the organizational structure and

processes to ensure information security. Information

security aims to safeguard “the integrity of informa-

tion, continuity of services and protection of infor-

mation assets” assets” (Williams, 2001, p. 64). The

closely related term security compliance can be de-

ﬁned as “the state of conformance with [...] imposed

functional security requirements and of providing ev-

idence (assurance) thereof” thereof” (Julisch, 2008,

p. 72). The origin of these requirements could be

either internal or external (such as required by regula-

tory bodies, industry standards, or clients).

2.2 Challenges of Security in ASD

To fulﬁll these internal and external requirements,

organizations frequently resort to non-agile security

development life cycles, incorporating linear gover-

nance and compliance processes within ASD method-

ologies (Rindell et al., 2018).

This dichotomy presents signiﬁcant challenges, as

widely acknowledged in the current literature. For

instance, a systematic mapping study by Moyon et

al. (2020) reveals that ensuring security compli-

ance often poses challenges for organizations employ-

ing ASD methods, as the required effort grows with

shorter development and delivery cycle times. Ac-

tivities such as integrating security experts and as-

sessors or documenting security compliance evidence

can present major hurdles.

Furthermore, Bartsch (2011) identiﬁed three main

types of challenges for integrating security in agile de-

velopment, based on literature: challenges related to

process aspects, communication and interaction, and

trust in individuals and teams.

Trust is closely related to the concept of au-

tonomous teams in ASD. When speaking of team

autonomy, we refer to “self-organizing teams” or

“self-managing teams”, as they are synonymously de-

scribed and deﬁned by researchers in the area of au-

tonomous agile teams (Stray et al., 2018).

2.3 Challenges of Security in LSAD

The tension between agility and security is ampliﬁed

when trying to scale agile processes while maintain-

ing security compliance without compromising ﬂexi-

bility and speed (Moy

on et al., 2021). In regards to

scaling agile processes, Dikert et al. (2016) reviewed

multiple deﬁnitions of LSAD and propose to deﬁne

large-scale agile development as a “software organi-

zation with 50 or more people or at least six teams”

(Dikert et al., 2016, p. 88).

While the majority of the literature focuses on

the general friction between agile methodologies and

security, a few authors already investigated security

challenges particularly in LSAD.

agele, Schenk, and Matthes (2023) identiﬁed 15

challenges based on a systematic literature review and

interview study, partly based on van der Heijden et

al. (2018) who previously identiﬁed security chal-

lenges speciﬁc to LSAD environments. One of the

key challenges is the prevalent goal of agile teams to

pursue team autonomy, while a certain level of control

is often still required, especially in regulated environ-

ments (N

agele et al., 2023).

Additionally, Edison et al. (2021) identiﬁed sev-

eral security-related challenges when implementing

scaling agile frameworks in practice, such as deﬁcient

security awareness and the absence of proactive secu-

rity activities.

We address the identiﬁed challenges in the design

of our solution artifact as described in Section 4.1.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

2.4 Solution Approaches

In addition to addressing known challenges, we draw

from existing solution approaches and success factors

already described in the existing literature.

agele, Schenk, and Matthes (2023) propose ﬁve

factors to balance team autonomy and organizational

control through security governance based on a sys-

tematic literature review and interview study. New-

ton et al. (2019) propose propose twelve critical suc-

cess factors and related practices to integrate infor-

mation security within ASD. These include achiev-

ing security awareness, security training, early se-

curity testing, dedicated security activities, and a

straightforward release process considering security.

Typical examples of security activities suitable for

LSAD environments are threat modeling, security

self-assessments, code reviews, or penetration tests

agele et al., 2022).

Bartsch (2011) asserts that integrating security

and agility could be achieved by promoting a uniﬁed

understanding of roles and effectively assimilating as-

surance and documentation activities into the agile

process. Bell et al. (2017) conclude that it is possible

to develop secure software with agile approaches if,

on the one hand, agile teams integrate security activ-

ities and are responsible for developing secure soft-

ware and, on the other hand, receive enough guidance

from security experts. It may be helpful for teams to

get involved with security if one team member (a des-

ignated security expert or a developer) takes over a

security role within the team (Bell et al., 2017).

2.5 Similar Approaches

In the course of our research, two publications

emerged with partly similar approaches to balance au-

tonomy and control, demonstrating the interest and

relevance of the topic.

Petit and Marnewick (2019) propose a release

governance approach that is adaptive with regard to

their deﬁnition of a team’s autonomy.

Poth et al. (2020) also also introduce the con-

cept of team maturity and propose that higher matu-

rity should lead to more autonomy.

Our approach aims to offer a more thorough, ﬂex-

ible, and seamlessly integrable solution to the chal-

lenges outlined in existing literature. Another key

distinguishing feature is our focus on LSAD and se-

curity. In addition, we strive for an approach that

is rigorous and systematic enough to be applied and

successfully audited even in highly regulated environ-

ments, while also leveraging the beneﬁts of agile, au-

tonomous teams.

3 RESEARCH METHOD

Our research primarily followed a DSR approach

which facilitates the creation and evaluation of ar-

tifacts that address an “unsolved problem or [...] a

known problem in a more effective or efﬁcient man-

ner” (Hevner et al., 2004, p.81). Peffers et al. (2007)

extended this concept by proposing a concrete DSR

process which we use as a blueprint for our research.

We aimed to ensure rigor by building our arti-

facts on the results of existing literature reviews, e.g.,

agele, Schenk, and Matthes (2023), and additional

literature, serving as our knowledge base.

Concurrently, we strove for relevance and prac-

tical applicability of our artifacts by employing an

interview study, mainly based on Rubin and Rubin

(2011) as well as Salda

na (2016), in line with the ex-

pert evaluation proposed by Peffers et al. (2012).

In the initial phase of our DSR, we engaged in un-

structured interviews and informal discussions with

industry partners. Additionally, we drew insights

from existing literature as well as our own prior re-

search for problem identiﬁcation and motivation, as

detailed in Sections 1 (Introduction) and 2 (Back-

ground and related work) of this paper.

As the second DSR step, based on the identiﬁed

problem, we derived the objectives of a solution, de-

ﬁned in Section 4.1. We proceeded to design and de-

velop the ﬁrst iteration of our solution artifacts.

To validate our problem statement, the goals of

our solution and the ﬁrst iteration of our artifacts, we

merged the fourth and ﬁfth DSR steps, demonstration

and evaluation, by presenting our results to expert in-

terviewees in a ﬁrst round of interviews and directly

collecting feedback. This enabled us to iteratively

reﬁne our prototypes, incorporating crucial feedback

and producing updated artifact versions.

Subsequently, we conducted a second interview

round for the ﬁnal evaluation. The ﬁnal solution ar-

tifacts are presented in Section 4, with the evaluation

results detailed in Section 5. Our key ﬁndings and

their implications are discussed in Section 6. The

communication of our ﬁndings through this paper

constitutes the ﬁnal phase of our DSR process.

In total, we carried out 28 interviews with 18 ex-

perts from 15 companies across ﬁve industries: ﬁ-

nance, retail and e-commerce, consulting, entertain-

ment, and automotive. 10 of the experts were inter-

viewed twice and 8 experts were interviewed once, as

it was not possible to interview all the experts twice

due to time and capacity constraints. The average in-

terview duration was 52 minutes, excluding initial in-

troductions, instructions, and a ﬁnal wrap-up.

We aimed for a diverse participant pool, encom-

Balancing Autonomy and Control: An Adaptive Approach for Security Governance in Large-Scale Agile Development

passing ASD roles as well as security governance and

audit-related positions. Speciﬁc roles that were in-

cluded are Product Owner, Scrum Master, Agile De-

velopers, Security Engineer, Security Architect, So-

lution Architect, Business Analyst, Security Consul-

tant, (IT) Management Consultants, Information Se-

curity Lead, Security Ofﬁcer, Security Manager, and

(Security) Auditors. During selection, we prioritized

experts with more extensive self-reported experience

at the intersection of LSAD and security.

With the interviewees’ consent, interviews were

recorded and transcribed to ensure accuracy. We ad-

hered to a cyclic approach as endorsed by Salda˜

(2016), initially coding the data in the ﬁrst cycle and

ﬁltering it more precisely in the second cycle to con-

centrate on the most pertinent aspects. To streamline

coding, we employed the software MAXQDA, which

facilitates efﬁcient data processing and storage.

4 ADAPTIVE APPROACH FOR

SECURITY GOVERNANCE IN

LSAD

In this section, we present the resulting artifacts of

our research. Those are (i) a generic organizational

structure of security-related roles and (ii) a team au-

tonomy assessment model, both integrated within (iii)

an adaptive collaboration model, completed by (iv) a

projection of the model onto the most relevant scaling

agile frameworks. Figure 1 shows an overview of the

results and the structure of this section.

Artifact 2:

Team

autonomy

assessment

model

(Section 4.3)

Artifact 1:

Generic

organizational

structure of

security-related

roles

(Section 4.2)

Artifact 3: Adaptive collaboration model (Section 4.4)

integration

Supplementary: Integration into existing scaling agile frameworks (Section 4.5)

Adaptive approach for security governance and compliance in LSAD

analyze applicability in scaling agile

Figure 1: Overview of resulting artifacts.

Together, the resulting models form an approach

for security governance in LSAD that integrates

security-related roles and activities, and adapts to de-

velopment team capability, as well as organizational

and product requirements, thereby balancing auton-

omy and required control.

4.1 Goals of the Resulting Artifacts

We derived the following six objectives from the re-

search gap and current challenges:

1. Achieve a clear deﬁnition of roles and security

activities without being too prescriptive, aiming

to address the missing guidance on how to con-

duct security activities in LSAD (van der Heijden

et al., 2018; Moy

on et al., 2021) and tackle collab-

oration challenges with non-development func-

tions (Kalenda et al., 2018).

2. Attain security compliance without overly rigid

governance by balancing the autonomy and con-

trol tension, avoiding controls when not required,

and reducing overhead and bottlenecks.

3. Enable integration in scaling agile frameworks

to increase applicability in practice, since cur-

rent frameworks lack guidance on security and the

control autonomy tension (N

agele et al., 2023).

4. Increase the security awareness and expertise

of agile teams to address the previously reported

lack thereof (Moy

on et al., 2021).

5. Promote a responsibility shift towards agile

teams to enable security governance procedures

to be more “agile-friendly” and empower au-

tonomous teams while ensuring compliance.

6. Facilitate targeted allocation of security re-

sources to tackle the general shortage of security

practitioners (Moy

on et al., 2021).

4.2 Organizational Structure

Figure 2 illustrates the proposed organizational LSAD

setup. The structure is guided by the lines of defense

(LoD) model, a generic assurance approach adaptable

to both security and agile contexts (Wright, 2014).

The primary alteration we introduce is the “ﬁrst-

and-a-half LoD”, represented by security engineers

(SEs). They function in a dual role, actively assisting

agile teams in the ﬁrst LoD while serving as the sec-

ond LoD by reviewing other teams. To avoid conﬂicts

of interest or self-examination, SEs should only as-

sess teams and products not directly within their sup-

portive purview. The designation as engineers em-

phasizes their software and security engineering ex-

pertise, enabling them to support several teams in per-

forming security activities and increasing automation.

Following Wright’s proposal, agile teams form the

ﬁrst LoD (Wright, 2014) and are generically com-

posed of a product owner (PO) and developers. For

simplicity, we have excluded the scrum master from

our model, but their involvement is not precluded.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

Figure 2: Generic organizational structure of security-related roles.

Moreover, we introduce the security champion

(SC), a role envisioned not as a new entity but as a

developer within the agile team possessing an addi-

tional commitment to security. The SC serves as the

team’s primary security contact point, both within the

team and for external stakeholders. The roles of SEs

and SCs are not entirely novel, as researchers such as

agele et al. (2022) have already delineated common

responsibilities of these roles from literature and ob-

servations in practice.

The second LoD establishes policies and stan-

dards, and conﬁrms that the ﬁrst LoD delivers accept-

able work in compliance with these guidelines. In our

model, the second LoD also has an enabling role, pro-

viding security tools, automated CI/CD pipelines, and

training. Unlike the ﬁrst and ﬁrst-and-a-half LoDs,

the second LoD does not directly participate in the in-

dividual teams’ development activities.

The third LoD is charged with providing an inde-

pendent assessment of the work performed by the ﬁrst

and second LoDs. Internal audits, being independent

of the development process and typically conducted at

random or set intervals, do not necessitate regular in-

teraction with other LoDs in the context of our model.

4.3 Team Autonomy Assessment Model

To balance the required control and granted auton-

omy, we propose to systematically assess a team au-

tonomy score based on three inﬂuencing factors: pro-

tection need, team security maturity, and standardiza-

tion level.

4.3.1 Protection Need

The protection need is essential given the distinct risk

proﬁles of software products. These necessitate vary-

ing types and scopes of security measures, as well as

differing levels of rigor in the validation and veriﬁ-

cation processes, ultimately impacting the degree of

team autonomy that can be granted.

The protection need may encompass the individ-

ual product risk and additional factors, including the

organization’s risk appetite and regulatory require-

ments. We propose that the protection need assess-

ment is conducted by the PO, who bears product re-

sponsibility, in collaboration with an SE represent-

ing the second LoD. The SE contributes special-

ized knowledge to evaluate security dimensions ac-

curately, whereas the PO ensures the consideration of

the business perspective.

Our model introduces four protection need levels,

omitting a middle option to preclude selection with-

out thorough deliberation. Organizations may employ

common risk analysis and predeﬁned damage scenar-

ios to ascertain the appropriate protection need level

for a developed product. The more severe the impact

of these scenarios, the higher the corresponding pro-

tection need level. Examples include non-compliance

with laws or regulations, operational incapacitation,

and ﬁnancial harm. The conﬁguration of damage sce-

narios and their impact severity per protection need

level is highly organization-speciﬁc. Thus, we refrain

from a more detailed deﬁnition within the model.

4.3.2 Team Security Maturity

The team security maturity reﬂects a team’s capabil-

ity to develop secure and regulatory-compliant soft-

ware. We incorporate this factor based on the intu-

itive supposition that higher maturity levels warrant

greater autonomy, as supported in the literature (Poth

et al., 2020; Petit and Marnewick, 2019).

The comprehensive design of a maturity model

to assess such a capability can be found in one

of our previously published studies (N

agele et al.,

Balancing Autonomy and Control: An Adaptive Approach for Security Governance in Large-Scale Agile Development

Team Autonomy

Protection Need

very high | high | normal | low

Team Security Maturity

no | partly | largely | fully

Standardization Level

no | partly | largely | fully

-2 -1 +1 +2 -2 -1 +1 +2

𝑷𝒓𝒐𝒕𝒆𝒄𝒕𝒊𝒐𝒏)𝑵𝒆𝒆𝒅 + 𝑻𝒆𝒂𝒎)𝑺𝒆𝒄𝒖𝒓𝒊𝒕𝒚)𝑴𝒂𝒕𝒖𝒓𝒊𝒕𝒚 + 𝑺𝒕𝒂𝒏𝒅𝒂𝒓𝒅𝒊𝒛𝒂𝒕𝒊𝒐𝒏)𝑳𝒆𝒗𝒆𝒍

-2 -1 +1 +2

-6 -5 -4 -3 -2 -1 0 1 2 3 4 5 6

low medium high

Figure 3: Team autonomy assessment calculation including exemplary thresholds.

2024). In summary, we advocate for the amalga-

mation of methods such as self-assessments, evalua-

tions by external stakeholders, and the employment of

(semi-)automated metrics to estimate a team’s proﬁ-

ciency in pertinent security dimensions. Regular up-

dates to the assessment are advised, with smaller in-

crements to minimize overhead.

4.3.3 Standardization Level

The third determinant of team autonomy is the stan-

dardization level, which emerged as a prominent fac-

tor in our expert interviews.

Our proposed standardization framework com-

prises three pillars: (i) utilization of standardized

components within the software product, (ii) the un-

derlying infrastructure and tooling for development,

deployment, and delivery, and (iii) security-related

activities.

Reusable components may address cross-team se-

curity requirements, such as authentication, autho-

rization, or secret management. Standardized in-

frastructure facilitates pre-tested and conﬁgured en-

vironments for teams, exempliﬁed by customizable

pipelines for building, testing, and deploying software

iterations on trusted platforms. Employing common

standards for these pipelines, such as the same static

and dynamic security testing tools with organization-

optimized rulesets, enhances comparability, quality,

and knowledge sharing.

Standardizing security activities through clear

guidance on practices like security code reviews or

threat modeling enables greater autonomy. The SE’s

role is crucial in assessing and guiding teams.

Although standardization may be evaluated as part

of the team maturity assessment, its signiﬁcance war-

rants separate consideration.

4.3.4 Team Autonomy Score

To integrate all three factors into a team autonomy

score, our interview ﬁndings suggest a preference for

a straightforward calculation method to enhance prac-

tical applicability. Each factor is assigned one of four

proﬁciency levels determined through prior assess-

ments, with absolute values representing very nega-

tive (-2), negative (-1), positive (+1), or very posi-

tive (+2) inﬂuences on team autonomy. The team au-

tonomy score is obtained by summing these values,

with thresholds demarcating low (< −1), medium

(> −1 and ≤ 1), and high (> 1) autonomy.

Figure 3 depicts the logic, scale, and thresholds.

This scale enables compensation for unfavorable con-

ditions; for instance, a high protection need, typically

necessitating higher control, can be counterbalanced

by high team security maturity and extensive stan-

dardized component usage, resulting in high auton-

omy.

This compensation logic aligns with our overar-

ching goal of fostering high team autonomy, remov-

ing bottlenecks, and streamlining processes long-term

while motivating teams to improve. Without compen-

sation, a high protection need level would automati-

cally yield low autonomy, reducing incentives for se-

curity training and maturity improvement. Organiza-

tions can tailor the calculation logic to their require-

ments and context.

4.4 Adaptive Collaboration Model

Our adaptive collaboration model integrates

development-related security activities and assigns

them to roles deﬁned in the generic organizational

setup. It is adaptive by adjusting role assignments

and task frequencies based on team autonomy.

Figure 4 depicts the generic structure of the

model, featuring key components such as security ac-

tivities (grouped by phases), security-related roles,

and the frequency of activity execution. The model

illustrates the impact of team autonomy on the as-

signment of roles and the frequency of security activ-

ities, represented through color-coded markers. The

requirement for a team to undertake a marked activ-

ity is contingent on its respective level of autonomy.

Unmarked activities for a speciﬁc level of autonomy

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

Execution of activity

Design

...

Imple-

men-

tation

...

Release

...

VerificationRequirements

1st LoD

Product

Owner

Developer

Security

Champion

1,5 LoD

Security

Engineer

condition

Frequency

Every sprint

Every n-th sprint

Triggered by certain condition

Sprint-independent, performed

regularly according to selected

interval

Autonomy Assignment

High autonomy

Medium autonomy

Low autonomy

Activity Types

Activitiy

Activtiy Bucket

(Minimum # of activities to choose from

Bucket)

Activity Bucket

Activitiy 1...n

(Minimum # of activities to choose from

Bucket)

Activity Bucket

Activitiy 1...n

Activity Bucket

Execution of activity

Support for activity

Accountable, not necessarily directly involved

Figure 4: Generic structure of the collaboration model.

are optional and can be disregarded, provided that the

team has an adequate autonomy level. However, these

assignments should be customized to the speciﬁc or-

ganization. Generally, we propose that higher auton-

omy correlates with reduced collaboration with SEs,

lower reliance on the SC, and a minimized mandatory

frequency of security activities.

To structure and categorize the activities, we de-

rived a common denominator from secure develop-

ment life cycles in the literature (Boldt et al., 2017;

Microsoft, 2012). The model differentiates between

active execution, accountability without imposed di-

rect involvement, and supporting an activity (see Fig-

ure 4).

It further distinguishes between concrete activi-

ties and activity buckets, a concept adapted from Mi-

crosoft (2012) that enables grouping similar activities.

Buckets allow teams to systematically distribute nec-

essary activities over time without having to perform

them for every deployment or sprint. Organizations

can determine the number of bucket activities to be

performed per sprint and establish a cycle to ensure

all practices within a bucket are eventually executed.

Concrete examples of security activities are threat

modeling, penetration testing, security code and ar-

chitecture reviews or audits, and implementing im-

provements according to the ﬁndings of static (SAST)

and dynamic (DAST) application security testing

tools. The selection of speciﬁc activities is outside the

scope of the model. However, one of our previously

published studies provides more in-depth guidance on

selecting appropriate security activities in LSAD en-

vironments (N

agele et al., 2023).

The model also accommodates custom execution

frequencies for individual activities. While some ac-

tivities might be required every sprint or every n-th

sprint, others are only required if a certain trigger is

reached, such as a deployment to production. Ad-

ditionally, certain activities might not be tethered to

sprint timelines but rather to designated timespans,

e.g., dictated by regulatory requirements.

While the security activities are sequentially cate-

gorized, the model should not be interpreted as a lin-

ear process. Instead, it serves as an activity catalog,

guiding role involvement in necessary security activ-

ities. It is essential that team members identify the

current category of work to determine the required se-

curity measures for that development stage.

4.5 Integration with Scaling Agile

Frameworks

This section summarizes the compatibility of our

approach with six of the most used scaling ag-

ile frameworks in practice (Uluda

g et al., 2022):

The Scaled Agile Framework (SAFe), Scrum@Scale,

Large-Scale Scrum (LeSS), Spotify model, Disci-

plined Agile (DA) and Nexus.

Overall, our analysis did not discover any irrecon-

cilable conﬂicts that might prevent the adoption of our

model, though certain frameworks necessitate speciﬁc

considerations.

One potential conﬂict that might require a soft-

ening of framework guidelines is incorporating spe-

cialist roles in agile teams. Whereas DA and SAFe

are more in line with our recommendation to intro-

duce SCs by describing a specialized role in every

team (Ambler and Lines, 2020) or at least the oppor-

tunity to include specialists (Knaster and Lefﬁngwell,

2020), other frameworks do not discuss such roles.

In our perspective, these additional roles offer sig-

niﬁcant value, provided organizations avoid revert-

ing to outdated patterns of specialized roles that do

Balancing Autonomy and Control: An Adaptive Approach for Security Governance in Large-Scale Agile Development

not contribute to development. In our model, the SC

is an integral team member, contributing equally to

value creation but with an additional ’hat’ for security.

However, the SC role may be a transitional mecha-

nism until the team achieves sufﬁcient security matu-

rity, at which point it may be redundant. LeSS op-

poses the introduction of additional roles, advocating

instead for ’travelers’ – specialists who temporarily

join a team to facilitate knowledge transfer before ro-

tating to another (Larman and Vodde, 2016). Organi-

zations using LeSS could deploy SCs as travelers to

maintain compatibility.

Security

Engineer

Security

Champion

Added

Components

Figure 5: Spotify model exemplary integration.

Introducing team-external roles supporting agile

teams is more common and prevalent in all examined

frameworks, except for the Spotify model. However,

with its concept of chapters and guilds, the Spotify

model aligns well with our model, as depicted in Fig-

ure 5.

In Nexus, the SE can be included in the integration

team, as shown in Figure 6.

The most considerable ambiguity arises concern-

ing the proposed integration of the second LoD.

Scrum@Scale includes similar central functions, such

as legal and compliance. Other frameworks do not ex-

plicitly feature such centralized teams, necessitating

a more tailored transfer. Nonetheless, in our model,

the second LoD serves as a valuable auxiliary func-

tion rather than a core component and could be sub-

stituted by other mechanisms. Consequently, we do

not perceive this as a signiﬁcant impediment to the

integration of our model.

Security

Engineer

Security

Champion

Added

Components

Figure 6: Nexus exemplary integration.

5 EVALUATION

This section summarizes the results of the expert eval-

uation of our research artifacts. In general, the results

are in favor of our approach. Nevertheless, the evalu-

ation also brought interesting controversial aspects to

light.

5.1 Organizational Setup Evaluation

In general, all experts considered the proposed orga-

nizational setup, including the LoDs, to be clear, ra-

tional, and integrable into established systems in their

organizations. However, one expert raised concerns

about the suitability for smaller organizations due to

the additional roles.

The concept of SCs was generally favored, with

one exception. Experts suggested role assignment

should be afﬁnity-based, not knowledge-based, and

proposed SCs act as a central contact for agile devel-

opers as well as the second LoD and auditors. Con-

sequently, we expanded the SC’s role to include this

suggestion. A disputed point was the necessity of an

SC or SE in every team. Some experts advocated for

a mechanism to assess this necessity, whereas oth-

ers emphasized only the need for variable allocated

capacities. Our model presumes baseline security

requirements that necessitate an SC in every team,

which most experts agreed with. However, we recog-

nize the mandatory SCs as a limitation that requires

further research on its impact on applicability.

The experts stated that successful SC implemen-

tation necessitates clearly deﬁned incentives, training

roadmaps, and long-term goals. Adequate capacity

for their tasks and training is crucial.

Experts agreed on employing SEs to support ag-

ile teams and act as reviewers for teams that do not

already receive their support. The introduction of the

ﬁrst-and-a-half LoD and its associated SEs received

particular praise, especially for ensuring duty separa-

tion and in-depth reviews. However, ofﬂoading team

responsibility to SEs was identiﬁed as a potential risk,

which our model mitigates by deﬁning SEs as sup-

porters, not primary actors.

The experts conﬁrmed including central gover-

nance and security functions in the second LoD to

facilitate cross-team collaboration and balance busi-

ness needs and security requirements. They also sup-

ported the translation of generic policies into concrete

security standards by central security teams, with SEs

assisting in their practical implementation. How-

ever, they also discussed alternatives to central teams,

such as a security architect role or self-organization

through communities, which presuppose a high level

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

of organizational maturity.

Experts agreed with not explicitly including the

third LoD, as active involvement would conﬂict with

its audit function. However, they noted interest in the

model’s promotion of continuous compliance and po-

tential auditing culture shift.

Communities of Practice (CoPs) were generally

endorsed for their role in knowledge sharing, although

incentives for participation were seen as critical for

their success. One expert explained that “enabling

knowledge sharing is one of the most important as-

pects in agile [environments]”, thereby stressing the

importance of security-focused CoPs.

While deeming our model applicable, one expert

suggested a more generic version to account for other

types of non-functional requirements.

5.2 Team Autonomy Assessment

Evaluation

The experts considered the assessment of team au-

tonomy and inﬂuencing factors feasible and valu-

able, provided that adequate resources such as SEs

are available. One expert noted that the assess-

ment aligns well with agile principles and meth-

ods, e.g., retrospectives. Another expert voiced con-

cerns about allowing low-autonomy teams to handle

high-protection-need projects, suggesting to remove

the protection need from the autonomy assessment

and assigning the respective projects according to the

team autonomy instead. We decided against such a re-

moval but acknowledge the possibility of adding indi-

vidual constraints or actions to the model, e.g., chang-

ing the team-product assignment in case of a “low”

assessment result.

An auditor proposed that a maturity score could

prove beneﬁcial for tracking the impact and progres-

sion of security initiatives over time. However, the

expert observed that such scores typically do not suf-

ﬁce to derive suitable measures for enhancing security

maturity, potentially leading to overlooked deﬁcien-

cies, especially when a team’s overall maturity rating

is high yet has a signiﬁcant shortfall in a particular

area.

No additional factors affecting team autonomy

were identiﬁed during the evaluation, but a consen-

sus was reached that organizational risk appetite in-

ﬂuences protection need and should not be assessed

separately. Organizations adopting such an approach

should be able to clearly communicate in an audit why

certain teams are assumed to have a speciﬁc level of

security maturity and how the resulting governance

approach aligns with the general risk management.

The inclusion of team security maturity was uni-

versally valued, particularly when evaluated using ob-

jective measurements. While self-assessments were

deemed valuable for lean, self-dependent governance,

their subjectivity was viewed as a potential drawback.

The standardization level was generally

deemed important, despite potential loopholes

and workarounds in highly standardized systems.

Experts suggested additional aspects, such as the

proportion of outsourced components, since these

might introduce risks that development teams do not

directly control.

5.3 Adaptive Collaboration Model

Evaluation

The experts agreed that increased autonomy serves as

a compelling incentive for teams to enhance their se-

curity focus, thereby facilitating the transition of se-

curity responsibilities to the teams. They regarded the

model as ﬂexible and adaptable, providing sufﬁcient

guidance while preserving room for customization.

One expert emphasized the positive impact of col-

laborative security activities such as threat model-

ing and stated that “[...] once you show them how

something can go wrong, they are going to be self-

motivated to make the thing [the threat] go away.

They are going to educate themselves.”

Another expert stated that the model’s adaptabil-

ity makes it a “valuable resource-saving approach” by

focusing efforts on teams with less autonomy address-

ing the important lack of security resources issue.

Nonetheless, auditors emphasized the importance

of documenting the completion of security activities

for compliance, which should be ensured across all

teams, irrespective of maturity. Auditors also noted

that while the adaptive approach does not conﬂict

with common security standards, initial audits may

necessitate closer examination due to its novelty.

The categorization of activities is deemed useful,

adding to the model’s ﬂexibility. One expert high-

lighted the inclusion of triggered activities, as it is

something the expert has “not seen so far in any other

model”, but thinks that they provide great value.

We offered illustrative conﬁgurations to enhance

the model’s comprehensibility, encompassing speciﬁc

security activities. However, the evaluation high-

lights that the selection and conﬁguration of activities

largely depend on the speciﬁcs of the organizations.

Overall, the experts were satisﬁed with the level

of complexity, for example stating that “the model is

not over-engineered” and that “[...] being too detailed

would be the pitfall of the model.”

However, while appreciating the model’s ability

to distill a complex issue, experts expressed concerns

Balancing Autonomy and Control: An Adaptive Approach for Security Governance in Large-Scale Agile Development

about managing the remaining complexity - in partic-

ular, conveying the model’s conﬁguration to the re-

spective teams considering their team autonomy. We

showcased potential solutions for this challenge by

using the web-based diagramming tool “Lucidchart”

for demonstration. Its simple interactive elements al-

low to create ﬁlters for different maturity levels and

a process diagram that adapts to the selected ﬁlters,

reducing the visualization complexity and enhancing

comprehensibility - a factor critical for the model’s

practical applicability.

5.4 Evaluation of Framework

Integration

Expert opinions on incorporating the artifacts into

existing scaling agile frameworks varied. Some ex-

perts saw merit in offering integration guides, argu-

ing that such guidance could streamline adaptation for

companies utilizing these frameworks. Others recog-

nized the potential utility but considered the integra-

tion straightforward and thus would not prioritize it.

One expert highlighted the possible resistance of agile

practitioners to the introduction of specialized roles,

stressing the importance of illustrating the congru-

ence between our role model and these frameworks.

6 DISCUSSION

6.1 Key Findings

To answer our RQ and address the identiﬁed research

gap, we created artifacts that guide in balancing the

control and autonomy tension in LSAD. In the fol-

lowing, we present four key ﬁndings of our research.

First, the expert evaluation ﬁnds that our adaptive

approach, anchored in team autonomy assessments,

forms a valuable basis for resource-efﬁcient gover-

nance for security compliance within LSAD. Accord-

ing to our interviews, the current modus operandi in

large-scale enterprises leans towards top-down gover-

nance procedures. However, we advocate for a trans-

formation towards autonomy and self-governance to

facilitate sustainable security integration into LSAD.

Organizations can leverage team autonomy to adapt

their governance process and avoid having controls

in place when circumstances do not call for them,

aiming to ensure security compliance while reducing

governance bottlenecks. This approach improves the

compatibility of security governance and compliance

efforts with agile methods at scale, a key challenge

reported in existing research (N

agele et al., 2023).

Second, the experts assessed the collaboration

model as valuable. The model provides a customiz-

able distribution of security activities among roles and

iterative development phases, thereby offering clear

guidance on the collaboration between agile teams

and security experts. By incorporating visualization

and a ﬁltering functionality, the model enhances its

usability and boosts transparency. Team autonomy,

which serves as an input to the model, helps to deter-

mine the roles that participate in an activity and the

frequency of speciﬁc activities, thereby achieving a

desirable degree of adaptivity. We recommend a re-

duced collaboration with team-external stakeholders

and security specialists for teams with high autonomy,

and fewer prescribed security activities and audits.

By shifting responsibility to teams, the model aims

to conserve scarce security resources while encour-

aging teams to prioritize security and achieve faster

delivery. We thereby tackle challenges described in

previous literature, such as the shortage of security

practitioners (Moy

on et al., 2021) and the need for

guidance on integrating security activities in LSAD

(Edison et al., 2021; D

annart et al., 2019).

Thirdly, during expert interviews, some intriguing

perspectives on the rigidity of our approach emerged.

Initially, a few auditors preferred more structure and

control, while some agile practitioners found it too

rigid and process-based. This divergence in percep-

tions afﬁrmed the relevance of the tension we aim to

reconcile. Through further dialogue, iterations, and

the incorporation of the expert feedback into our mod-

els, both groups started to appreciate the advantages

of our approach. Governance and auditing roles par-

ticularly valued the systematic and traceable method

for granting autonomy. At the same time, agile practi-

tioners saw value in the approach because it empow-

ers experts to hone and reﬁne their skills, rewarding

expertise with greater autonomy and accountability.

Lastly, we acknowledge that our approach is ex-

tensive, and its implementation within an organization

may require signiﬁcant effort. However, our approach

could also inspire incremental changes to existing es-

tablished procedures within organizations. Our expert

interviews also corroborated this, sparking consider-

able interest in integrating the perspective of team au-

tonomy within their organizations.

6.2 Limitations

To yield robust results and artifacts, we incorporated

expert interviews into the development and ﬁnal eval-

uation of our work. Recognizing the potential im-

pact of expert representativeness on the validity of our

ﬁndings (Miles et al., 2014), we prioritized experts

ICEIS 2024 - 26th International Conference on Enterprise Information Systems

with extensive experience and diverse backgrounds.

Additionally, we acknowledge the potential inﬂu-

ence of researchers on the objectivity of the collected

data and its analysis (Miles et al., 2014). To miti-

gate this, we followed the interview questionnaire as

closely as possible during the semi-structured inter-

views and employed cyclic coding in our analysis.

Transcription of the interviews further limited the in-

ﬂuence of researcher-inherent bias.

Another notable limitation of this study lies in the

absence of experiments and practical applications of

our approach due to the complexity of the research

topic. However, such investigations are currently in

progress, even extending to cross-cutting concerns

beyond security, such as software architecture and

user experience.

7 CONCLUSION

The increasing adoption of LSAD, coupled with

the growing signiﬁcance of security, necessitates ap-

proaches to achieve a balance between team auton-

omy and organizational control. Existing literature

recognizes this tension and its resultant challenges,

but comprehensive solutions remain scarce. To ad-

dress this gap, we employed a DSR approach to de-

velop solution artifacts. We combined this approach

with an expert interview study to improve our arti-

facts and ensure practical relevance and applicabil-

ity. Our approach aspires to harmonize governance

with LSAD by using a team autonomy assessment

as a determinant of role responsibilities and security

activity frequency. Our central recommendation is

that more capable and mature teams should receive

more autonomy, based on a documented and trans-

parent assessment and process model. This solution

balances the granted autonomy and required control

while preserving compliance and auditability. The ex-

pert evaluations generally endorse our approach while

illuminating areas for enhancement and additional re-

search opportunities. Future experiments should scru-

tinize the practicality of our approach, perhaps focus-

ing initially on a select few teams to increase feasi-

bility before scaling to larger environments. Prospec-

tive adaptations of the approach could also encom-

pass other cross-cutting concerns and non-functional

requirements beyond security.

ACKNOWLEDGEMENTS

This work has been supported by the German Federal

Ministry of Education and Research (BMBF) Soft-

ware Campus grant 01IS17049.

REFERENCES

Ambler, S. W. and Lines, M. (2020). Choose Your WoW: A

Disciplined Agile Delivery Handbook for Optimizing

Your Way of Working. PM Institute.

Bartsch, S. (2011). Practitioners’ perspectives on security in

agile development. In Sixth International Conference

on Availability, Reliability and Security (ARES), pages

479–484, Piscataway, NJ. IEEE.

Bell, L., Bird, J., Brunton-Spall, M., and Smith, R. (2017).

Agile application security: Enabling security in a

continuous delivery pipeline. O’Reilly Media, Se-

bastopol, CA.

Boldt, M., Jacobsson, A., Baca, D., and Carlsson, B. (2017).

Introducing a novel security-enhanced agile software

development process. International Journal of Secure

Software Engineering, 8(2):26–52.

annart, S., Moy

on, F., and Beckers, K. (2019). An as-

sessment model for continuous security compliance

in large scale agile environments. In Advanced Infor-

mation Systems Engineering, pages 529–544, Cham,

Switzerland. Springer.

Dikert, K., Paasivaara, M., and Lassenius, C. (2016). Chal-

lenges and success factors for large-scale agile trans-

formations: A systematic literature review. Journal of

Systems and Software, 119:87–108.

Edison, H., Wang, X., and Conboy, K. (2021). Comparing

methods for large-scale agile software development:

A systematic literature review. IEEE Transactions on

Software Engineering, pages 1–23.

Hevner, A. R., March, S. T., Park, J., & Ram, S. (2004).

Design science in IS research. MIS Quarterly, 28(1),

75–105.

Julisch, K. (2008). Security compliance: The next fron-

tier in security research. Proc. of the new security

paradigms workshop, 71–74.

Kalenda, M., Hyna, P., and Rossi, B. (2018). Scaling ag-

ile in large organizations: Practices, challenges, and

success factors. Journal of Software: Evolution and

Process, 30(10):p. 1954.

Knaster, R. and Lefﬁngwell, D. (2020). SAFe 5.0 Dis-

tilled: Achieving Business Agility with the Scaled Ag-

ile Framework. Addison-Wesley, Boston.

Larman, C. and Vodde, B. (2016). Large-scale Scrum:

More with LeSS. Addison-Wesley, Boston and Am-

sterdam and London.

Microsoft (2012). Security development lifecycle - sdl pro-

cess guidance version 5.2.

Miles, M. B., Huberman, A. M., and Salda

na, J. (2014).

Qualitative data analysis: A methods sourcebook.

SAGE, Thousand Oaks Califorinia, 3 edition.

Moyon, F., Almeida, P., Riofrio, D., Mendez, D., and Kali-

nowski, M. (2020). Security compliance in agile soft-

ware development: A systematic mapping study. In

46th Euromicro Conference on Software Engineering

Balancing Autonomy and Control: An Adaptive Approach for Security Governance in Large-Scale Agile Development

and Advanced Applications (SEAA), pages 413–420.

IEEE.

Moy

on, F., M

endez, D., Beckers, K., and Klepper, S.

(2021). How to integrate security compliance re-

quirements with agile software engineering at scale?

In Product-Focused Software Process Improvement,

pages 69–87, Cham, Switzerland. Springer.

agele, S., Korn, L., and Matthes, F. (2023). Adoption

of information security practices in large-scale agile

software development: A case study in the ﬁnance in-

dustry. In Proc. of the 18th Int. Conf. on Availability,

Reliability and Security, ARES ’23, New York, NY,

USA. Association for Computing Machinery.

agele, S., Schenk, N., and Matthes, F. (2023). The cur-

rent state of security governance and compliance in

large-scale agile development: A systematic literature

review and interview study. In IEEE 25th Conference

on Business Informatics (CBI).

agele, S., Watzelt, J.-P., and Matthes, F. (2022). Investi-

gating the current state of security in large-scale agile

development. In 23rd Int. Conf. on Agile Software De-

velopment (XP), pages 203–219. Springer.

agele, S., Watzelt, J.-P., and Matthes, F. (2024). Assess-

ing team security maturity in large-scale agile devel-

opment. In Proc. of the 57th Hawaii Int. Conf. on

System Sciences, pages 7259–7269.

Newton, N., Anslow, C., and Drechsler, A. (2019). Informa-

tion security in agile software development projects:

A critical success factor perspective. In 27th European

Conference on Information Systems (ECIS), pages 1 –

17.

Peffers, K., Rothenberger, M., Tuunanen, T., and Vaezi, R.

(2012). Design science research evaluation. In Design

Science Research in Information Systems. Advances in

Theory and Practice, volume 7286, pages 398–410.

Berlin, Heidelberg.

Peffers, K., Tuunanen, T., Rothenberger, M. A., and Chat-

terjee, S. (2007). A design science research method-

ology for information systems research. Journal of

Management Information Systems, 24(3):45–77.

Petit, Y. and Marnewick, C. (2019). Earn your wings: A

novel approach to deployment governance. In Agile

Processes in Software Engineering and XP – Work-

shops, volume 364, pages 64–71, Cham, Switzerland.

Springer.

Poth, A., Jacobsen, J., and Riel, A. (2020). Systematic agile

development in regulated environments. In Systems,

Software and Services Process Improvement, volume

1251, pages 191–202, Cham. Springer.

Rindell, K., Hyrynsalmi, S., and Lepp

anen, V. (2018).

Aligning security objectives with agile software de-

velopment. In 19th Int. Conference on Agile Software

Development, pages 1–9, New York, NY, USA. ACM.

Rubin, H. J. and Rubin, I. S. (2011). Qualitative Interview-

ing: The Art of Hearing Data. SAGE, 3 edition.

Salda

na, J. (2016). The coding manual for qualitative re-

searchers. SAGE, Los Angeles and London, 3 edition.

Stray, V., Moe, N. B., and Hoda, R. (2018). Autonomous

agile teams: Challenges and future directions for re-

search. In Proceedings of the 19th International Con-

ference on Agile Software Development: Companion,

pages 1–5, New York, NY, USA. ACM.

Tayaksi, C., Ada, E., Kazancoglu, Y., and Sagnak, M.

(2022). The ﬁnancial impacts of information systems

security breaches on publicly traded companies: reac-

tions of different sectors. Journal of Enterprise Infor-

mation Management, 35(2):650–668.

Uluda

O., Philipp, P., Putta, A., Paasivaara, M., Lasse-

nius, C., and Matthes, F. (2022). Revealing the state

of the art of large-scale agile development research:

A systematic mapping study. Journal of Systems and

Software, 194.

van der Heijden, A., Broasca, C., and Serebrenik, A.

(2018). An empirical perspective on security chal-

lenges in large-scale agile software development. In

12th ACM/IEEE International Symposium on Empiri-

cal Software Engineering and Measurement, pages 1–

4, New York, NY. ACM.

Williams, P. (2001). Information security governance. In-

formation Security Technical Report, 6(3), 60–70.

Wright, C. (2014). Agile Governance and Audit. IT Gover-

nance Publishing, Cambridgeshire.

ICEIS 2024 - 26th International Conference on Enterprise Information Systems