Content uploaded by Bruno Rossi
Author content
All content in this area was uploaded by Bruno Rossi on May 19, 2018
Content may be subject to copyright.
Received 13 September 2017; Revised 14 March 2018; Accepted 15 March 2018
Accepted version of the article. Final version at https://doi.org/10.1002/smr.1954
PRACTICE
Scaling Agile in Large Organizations: Practices, Challenges and
Success Factors
Martin Kalenda1| Petr Hyna2| Bruno Rossi*1
1Faculty of Informatics, Masaryk University,
Brno, Czech Republic
2Kentico, Brno, Czech Republic
Correspondence
*Corresponding author,Email:
brossi@mail.muni.cz
Summary
Context: Agile software development has nowadays reached wide adoption. However, moving
agile to large scale contexts is a complex task with many challenges involved. Objective: in this
paper, we review practices, challenges and success factors for scaling agile both from literature
and within a large software company, identifying the most critical factors. Method: we conduct
a focused literature review to map the importance of scaling practices, challenges and success
factors. The outcome of this focused literature review is used to guide action research within a
software company with a view to scaling agile processes. Results: company culture, prior agile and
lean experience, management support and value unification were found to be key success factors
during the action research process. Resistance to change, an overly aggressive roll-out time-
frame, quality assurance concerns, and integration into pre-existingnon-agile business processes
were found to be the critical challenges in the scaling process. Conclusion: the action research pro-
cess allowed to cross-fertilize ideas from literature to the company’s context. Scaling agile within
an organization does not need to follow a specific scheme, rather the process can be tailored to
the needs while keeping the core values and principles of agile methodologies.
KEYWORDS:
Large-scale Agile, Agile Adoption, Large Scale Scrum (LeSS), Scaled Agile Framework (SAFe),
Action Research
1 INTRODUCTION
Agile software development is very popular nowadays, as its application
in many different contexts shows.1,2 However, traditional agile meth-
ods were designed with a single team in mind and were not meant to
face scalability challenges.3In this sense, "scaling" can be described as "a
continuous process of transferring, translating and transforming knowledge
across various communities and individuals" ( Rolland4citing Carlile5,6 )—
placing large emphasis on the communication needs during a scaling
process.
Scaling agile software development in large organizations is complex
and poses several challenges.7–11 Large projects require appropriate
coordination and communication between teams,12–14 dependencies
0Abbreviations: LeSS, Large Scale Scrum; SAFe, Scaled Agile Frame-
work; CoP, Communities of Practice; SoS, Scrum of Scrums; CTO, Chief
Technology Officer; CEO, Chief Executive Officer; UX, User eXperience, QA,
Quality Assurance; CMS, Content Management System
between teams need to be managed, other non-agile units need to be
involved,15 and the right people need to be part of the process.16,17
Recent research reports that the majority of goals and practices for scal-
ing agile are domain independent, listing as key factors challenges in coor-
dinating multiple teams,difficulties with managing requirements,problems
in adaptation with the organizational structure and issues in understanding
agile concepts along the value chain.1Additionally, customer involvement,
software architectural concerns, and inter-team coordination were also
reported,18 together with challenges in coordinating the work of several
teams.19
In general, training personnel,informing and engaging people in the pro-
cess, and involving actors that can push the process further were general
success factors found in case studies related to agile scalability.9,20
Adopting new scaling practices is also challenging, as there are many
cross-cutting factors that can impact and have been found in technology
adoption studies.21–26 In particular, resistance to change and weak man-
agement support can play a relevant role.22,25, 26 As it has been observed,
2MARTIN KALENDA ET AL
"real agile development with Scrum implies a deep change to become an agile
organization; it is not a practice, it is an organizational design framework.
Start a large-scale agile Scrum adoption by ensuring leadership understands
the organizational implications, and they have been proven adoptable in the
small scale".27,28
Scaling agile and finding the best scaling agile practices is among
the most relevant research topics in terms of interest for practition-
ers.29,30, 9 We are, however, far away from reaching consensus on the
best set of practices given a context.9,4 We know that scaling agile is
particularly challenging in the distributed development context,31,10 for
the development of safety critical systems in regulated environments,2
for continuous value delivery,32 and due to contradictions that might
emerge in large bureaucratic organizations.33
The goal of this paper is to collect more evidence about impact fac-
tors during an agile scaling process, as we need more evidence about
practices that work best in a given context,34,1 collected as the process
happens and not ex-post,4possibly to research variations over time.18
We approach the goals by firstly evaluating existingmethods and frame-
works for scaling agile development. We select two of them—SAFe
(Scaled Agile Framework)35,36 and LeSS (Large Scale Scrum)27—that we
examine more deeply. Using the knowledge assessed from this evalua-
tion, we extract common practices that these methods and frameworks
use to scale agile development. Secondly,we conduct a research of stud-
ies that examine experiences of large companies adopting agile meth-
ods. In this research, we determine challenges and success factors of
these adoptions, as well as study scaling practices that these companies
used. Finally, we conduct an action research study37,38 in a large com-
pany scaling-up the agile software development processes, to derive
challenges, success factors, and specific scaling practices.
In this paper, we aim at answering six main research questions. The
first three are derived from literature dealing with large-scale projects:
RQ1. Which agile scaling practices reported in literature did large compa-
nies (embracing practices from SAFe, LeSS) use?
RQ2. Which challenges reported in literature did large companies (embrac-
ing practices from SAFe, LeSS) face when adopting scaled agile devel-
opment?
RQ3. Which success factors reported in literature helped large companies
(embracing practices from SAFe, LeSS) to adopt and scale agile devel-
opment?
At the company-specific level, we aimed at answering:
RQ4. Which agile scaling practices were the most effective in the com-
pany’s context?
RQ5. Which challenges did the company face when adopting a scaled agile
development process?
RQ6. Which success factors were relevantin the company to adopt a scaled
agile development process?
The paper is structured as follows. Section 2 proposes the research
methodology, based on a focused literature review (step 1) used to sup-
port an action research study (step 2) conducted within large software
company. Section 3 presents the background about scaling practices,
discussing six frameworks for scaling agile, extracting common prac-
tices used in other parts of the research. Section 4 presents the results
from the main literature review (step 1) to collect evidence about prac-
tices, challenges and success factors from previous research (RQ1, RQ2,
RQ3). These factors are used during the action research process (step 2),
presented in Section 5, discussing the context, the needs to scale agile
development processes and the findings in terms of practices, success
factors and challenges within the company (RQ4, RQ5, RQ6). Section
6 presents the summary of the findings with a comparison with other
papers reviewing primary studies on scaling agile processes. Section 7
provides the conclusions.
2RESEARCH METHODOLOGY
We followed a research process based on two main steps. The first step
(step 1, Fig. 1 ) was a scoped literature review. The goal of the literature
review was to make aware industrial study partners of impact factors
in scaling agile studies. We were aware of the excellent and exhaustive
review by Dikert et al,34 and our goal was not to provide another exten-
sive review in the agile context (e.g. Schön et al,39 Torrecilla-Salinas et
al40). Our aim was to disseminate the company with material that could
be easy to understand and consult, providing a good starting point for
the second step.
The literature review was useful to define practices, challenges and
success factors that were found in previous research. After the initial
identification of common practices from SAFe and LeSS frameworks,
we run the literature review to identify most used practices, challenges
faced and success factors in previous studies. We used similar process to
Systematic Mapping Studies (SMS) and Systematic Literature Reviews
(SLR),41–43 although our aim was different and the applied process was
less extensive. The main similarity was in mapping research outcomes,
commonly done in SMS to map the current status of a research area,42
to identify the quantity and type of research and results available.41 In
our case, the mapping was done between factors identified and previous
research articles.
The second step was an action research process37,38 (step 2, Fig. 1 )
conducted by one of the authors during a process to scale-up agile pro-
cesses within a software company. The identified practices, challenges,
and success factors were the input for this process. Action research is
a combination of theory and practice, as it attempts to provide practi-
cal values to the case organization while also acquiring new theoretical
knowledge,44 in an actionable and iterative manner.45 Therefore, we
iteratively provided feedback to the case company, while also observing
the changes and analyzing them, in order to provide further knowledge
about the large-scale agile implementation.
MARTIN KALENDA ET AL 3
FIGURE 1 Research Process from Literature Review to Action Research
Action research has five identifiable phases that are iterated: diag-
nosis, action planning, action taking, evaluation and specifying learn-
ing.46,47 We conducted two loops of this cycle in our research. There
were limitations with the action taking phase, as adjusting the whole
development process is lengthy and our research was limited by time
constraints: some suggestions could not be implemented.
The diagnosis phase develops theoretical assumptions about the
nature of the organization and its problem domain, with identification
of the primary problems. This diagnosis was conducted with interviews
with organization representatives presented the organization’s context
and the problem domain for researchers.
In the action planning phase, an action plan which establishes the tar-
get for change and the approach to change is created. The proposed
measures are guided by both the desired goal of the organization, and
the corresponding changes that would achieve the company’s target.
We presented the plan at consecutive meetings. The plan was in the
form of concrete actions as well as additional suggestions that sup-
ported the change to the desired future state.
Once the action plan is executed, both the collaborative researchers
and practitioners undertake an evaluation of results. The results were
mainly presented by the representatives of the organization. As we
mentioned, the action plan execution was limited by the ability to
change the development process in constrained time.
The activity of specifying learning is formally described as the last
phase of the action research method. However,it is usually ongoing pro-
cess as the new knowledge is gained and reflected upon continuously.
3 BACKGROUND - SCALING AGILE
When scaling agile to large-scale, how can "large-scale" be defined?
There is no clear agreement in literature. While agile methodologies
prescribe 7±2 developers per team, the discriminating factor to dis-
tinguish small and large-scale projects is the number of teams, with
2-9 teams implying "large-scale" and over 10 "very large-scale".48 A more
restrictive definition of "large-scale" was given in,34 considering 50-100
developers and six teams for a large development project.
There are nowadays several frameworks that can be used to guide
the scaling process in organizations.29 Based on the needs emerging
over the years,29,30, 9, 49, 50 several methods, practices, and frameworks
were derived to extend traditional agile methods: Scrum of Scrums
(SoS), Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Dis-
ciplined Agile Delivery (DAD), Lean Scalable Agility for Engineering
(LeanSAFE), Recipes for Agile Governance in the Enterprise (RAGE)—
with SoS, SAFe, and LeSS considered the more mature.51,9, 35, 27
According to the Version One 2017 survey on the state of agile,56,57
the most used agile scaling methods are currently—ordered from higher
adoption level: the Scaled Agile Framework (28%), Scrum/Scrum of
Scrums (27%), internally created methods (13%), Lean Management
(4%), Agile Portfolio Management (4%), Large Scale Scrum (3%), Disci-
plined Agile Delivery (1%), Recipes for Agile Governance in the Enter-
prise (RAGE) (1%), Nexus (1%). "Internally created" or ad-hoc methods
play a major role, combining several practices in new ways. We summa-
rize in Table 1 themajor frameworks for scaling agile and describe them
in the following.
SAFe. SAFe is a framework as well as a collection of best practices of
agile development for large enterprises.35,36 The framework has been
adopted by large enterprises such as Intel, Hewlett-Packard Enterprise,
and Cisco.27 The framework is built upon ideas of agile development,
lean product development, and systems thinking. It supports companies
of different sizes, from small ones with less than hundreds of employees
to larger enterprises with thousands of people. To support such a degree
of flexibility, SAFe has optional extensions for large companies.35,36
The SAFe definition is very detailed and sometimes contains even
up to concrete agenda schedule of individual meetings.35,36 Its orga-
nizational structure is large, has several hierarchical layers with many
defined roles and responsibilities.35,36
The architecture of SAFe consists of levels. There are three base lev-
els: Portfolio level, Program level, and Team level. For large enterprises,
there is an optional Value Stream level. Across all the levels spans a
4MARTIN KALENDA ET AL
TABLE 1 Comparison of major frameworks for scaling agile. SAFe=Scaled Agile Framework, SoS=Scrum of Scrums, LeSS=Large Scale Scrum,
DAD=Disciplined Agile Delivery, RAGE=Recipes for Agile Governance in the Enterprise
Aspect SAFe35,36 SoS52 LeSS27 DAD53 Nexus54 RAGE55
Team size 50-120 people in
release trains
5-10 teams 10 Scrum teams,
7 members x
team
200 people or
more
3-9 Scrum teams no specific size
Diffusion High High Medium Low Low Low
Maturity level High High High Medium Low Low
Complexity High/Medium Medium / low Medium / low for
Scrum-aware
High (many prac-
tices)
Medium / low for
Scrum-aware
Medium / low for
Scrum-aware
Organization
Type
Traditional Enter-
prises
Traditional and
Agile Enterprises
Large Enterprises Multiple orga-
nizations &
Enterprises
Traditional and
Agile Enterprises
Traditional and
Agile Enterprises
Source: adapted from Ebert and Paasivaara,9Alqudah and Razali51
Foundation level with additional elements that support organizations.
Elements of the Foundation layer are, for example, SAFe core values, the
lean-agile mindset, and SAFe principles.35,36
The Portfolio level is guiding the enterprise in its mission. It defines
and governs the core strategic decisions which should bring value to the
organization. The Program level then implements the defined mission.
It manages, supports and synchronizes multiple agile teams which cre-
ate the solution. The Team level is the lowest level of SAFe. It describes
how agile teams work: it uses Scrum, Kanban and XP techniques in the
development process of agile teams.35,36
SoS. Scrum of Scrums (SoS) is an approach to scale agile to projects
with 5-10 teams, based on the reduction of communication overhead
that can emerge when scaling projects.52 The main idea is to designate
some members of daily Scrum meetings as ambassadors that will partic-
ipate to SoS meetings together with ambassadors from other teams.58
Such daily meetings progress as normal Scrum meetings, with focus
on challenges of coordination that might hinder team cooperation—all
managed through a separate backlog.58
SoS is mostly a cross-team synchronization method, with the main
goal of ensuring the quality of the Scrum processes in each team,52 but
is often cited in studies as full framework for scaling agile.9However, it
reaches full potential when adopted within the context of other frame-
works (e.g. SAFe35,36 ). In the remaining part of this article, we consider
SoS as a scaling practice that can be used to scale-up agile processes.
LeSS. LeSS takes a different approach than SAFe.27 Although still a
framework, it is much more lightweight than the SAFe. The core idea
of LeSS is that even for large organizations there is no need for an
overcomplicated process. LeSS tries to be compliant to one of the core
principles of the agile manifesto—that individuals and interactions are
more valuable than processes and tools. There are two variants: LeSS is
for organizations which develop products that need up to 8 agile teams.
LeSS Huge is for enterprises that require a higher number of teams.27
Compared to SAFe, LeSS is less strict in the description of the prac-
tices.27 LeSS stays as agile as possible: focusing on mindset, values,
and principles without introducing too many processes and roles.27 The
framework itself is much younger and does not have such enterprise
support as SAFe.
Authors of both SAFe and LeSS frameworks agree that understand-
ing the underlying values is important, and without their definition,
processes are meaningless.35,36, 27 We can see some similar patterns
in organizational structure and processes between these frameworks.
Both frameworks use the scaled role of Product Owner and a hierarchy
of backlogs. Moreover,they both lean towards Feature Teams59—cross-
component, cross-functional teams—that can enable easier require-
ments management.35,36, 27 Furthermore, both frameworks use some
additional teams that help the development teams with their work, the
so-called Undone Department, that can help with cross-cutting con-
cerns such as Quality Assurance and their integration of the concept
of "done" in a sprint/iteration.27 Last but not least, LeSS and SAFe use
scaled forms of common meetings, such as Scaled Planning, Scaled
Demo and Scaled Retrospective.35,36, 27
DAD. Disciplined Agile Delivery (DAD) extends Scrum by means of
other agile methods such as lean and Kanban.51,53, 60 Many agile prac-
tices are part of the framework: Kanban for visualizing time-boxedwork
progress, Scrum, Agile Modeling, the Unified Process, eXtreme Pro-
gramming (XP), Test Driven Development (TDD) and Agile Data—agile
strategies that can be applied to the "data" aspects of software systems
implementation and deployment.53,51
DAD covers three main project life-cycle phases: inception (initial
exploratory phase to understand project scope), construction (produc-
tion of the solution), and transition (deployment of the solution).51,53, 60
DAD phases can be customized according to the needs: Agile/Basic
(more similar to Scrum application), Advanced/Lean (more similar to
Kanban), Continuous Delivery Lifecycle (brief transition period, ideal
for quick releases, even daily), Exploratory Lifecycle (for start-up /
research projects with more phases for envisioning and measuring prod-
uct releases).51,53, 60
MARTIN KALENDA ET AL 5
Apart traditional Scrum roles, DAD introduces a role called Team
Lead (similar to Scrum Master) and an Architecture Owner role derived
from the Agile Modeling method.51,53 DAD provided other roles to
address scalability issues across teams (Specialist, Independent Tester,
Domain Expert, Technical Expert and Integrator).51, 53
One difference of DAD compared to other frameworks is that it
allows freedom of the teams to adapt the processes, and it also allows
to be customized according the aforementioned lifecycles, depending
on the needs.51 DAD is particularly useful for having guidance in the
area of architecture and design and DevOps, and can also be integrated
with capability maturity models.51 Nevertheless, it did not reach wide
adoption so far.51,56
Nexus. Nexus was born with the intention of scaling-up Scrum
practices, allowing for lower barrier to adoption and easier applica-
tion.51,61, 54 Nexus allows to scale-up workload from two to nine teams,
with Scrum used to manage interdependencies across teams and prob-
lems that can arise when increasing the number.61,51
In Nexus, all Scrum teams work on a Product Backlog, aiming to
reach an Integrated Increment with the Nexus Sprint Planning to coor-
dinate the activities of all Scrum teams.54 One Product Owner, a Scrum
Master, and an Integration Team member are part of an Integration
Team in Nexus.54 There are Nexus Sprint Retrospectives in which rep-
resentatives from each Scrum Team discuss sprint challenges. Such
retrospectives are conducted in parallel with team retrospectives.54,61
Nexus is relatively less mature than the other frameworks, however
it is expected to reach wider adoption in upcoming years.51
RAGE. Recipes for Agile Governance in the Enterprise (RAGE) is
a framework for Agile Governance, with processes applicable at the
project, program, and portfolio level of any enterprise.55 Key charac-
teristics are rapid decision-making, light artifacts, customization for
different processes (fully agile, waterfall, hybrid).55
At the project level, RAGE prescribes teams to be similar to Scrum
teams with traditional activities such as sprint planning and retrospec-
tives, with the governance level suggesting to apply ranking estimation
and story development.51,55 At the program level, area product owner
and program manager conduct release planning meetings, Scrum of
Scrums meeting or release reviews, with the governance level focus-
ing on release hand-offs, staging readiness reviews, product readiness
review and the validation of product development.51,55 At the portfolio
level, the portfolio owner, area product owner and program managers
conduct mainly portfolio grooming meetings to develop strategies, with
the governance level focused mainly on monitoring, decisions and qual-
ity assessments.51,55
RAGE allows quite a high level of customization of the processes, but
is relatively new, and the adoption level is still low.51
Merging the views. We used information from the frameworks to
target the subsequent literature review. However, to simplify knowl-
edge transfer within the company part of the action research process,
we had to focus on a subset of frameworks—covering all of them with
all small difference would have been unpractical and would have lead to
more complex communication. We selected two main frameworks: the
Scaled Agile Framework (SAFe)35 and Large Scale Scrum (LeSS).27 The
reason is that these can be seen as two representative frameworks, as
they take different approach to scalability: SAFe is the most complex
agile scaling method, while LeSS attempts to be as minimalistic as possi-
ble: it relies less on processes and specific organizational structures and
more on a mindset of people and ad-hoc communication. For this reason,
the upcoming sections take these two frameworks (and their practices)
as reference frameworks for the agile scaling process.
We identified eight common scaling practices which the two frame-
works (SAFe, LeSS) utilize. We use for each of them an identifier (SP =
Scaling Practices) to ease the readability:
SP1. Scrum of Scrums: approach to scale Scrum to large groups, divid-
ing people into groups and having daily Scrums with ambassadors from
the teams. We already covered SoS main characteristics, as it can be
considered as a kind of standalone framework for scaling agile within
an organization.52 SoS is contained in both LeSS and SAFe.35,36, 27, 52
SP2. Communities of Practice: a group of people with a common con-
cern or passion, that learn how to improve, share their knowledge and
expertise by interacting on an ongoing basis.62 The main idea is that
participation in such a community can be a way to increase the learning
outcomes also at the organizational level.62 Large agile organizations
can benefit from various overlapping, informal cross-team communi-
ties,63 and Communities of Practices can help in having leaders act-
ing as coordinators of the community members, rather than acting
purely as hierarchical superiors in agile projects.64 Both LeSS and SAFe
strongly suggest using Communities of Practice in a large-scale agile
organization.35,36, 27
SP3. Scaled Sprint Demo: a meeting in which teams show all the fea-
tures that were implemented, with the focus on the main product
under development.27 SAFe calls it System Demo,35,36 LeSS calls it
Sprint Review.27
SP4. Scaled Requirements Management: a group of scaling practices
that are concerned about requirements management, such as the cre-
ation of the hierarchical structure of Product Owners, the hierarchical
structure of Product Backlogs and its management. LeSS Huge uses
Requirement Areas, Area Product Owners, and Area Product Back-
logs.27 In SAFe this practice is utilized in the form of Value Streams,
Agile Release Trains, and its backlogs and managers.35, 36
SP5. Scaled Sprint Planning: a meeting where the future of a prod-
uct is discussed. SAFe calls the meeting PI Planning35,36 and LeSS
calls it Sprint Planning One.27 The meeting is larger in the context of
SAFe than LeSS. According to SAFe, the agenda of the meeting can be
business context and product vision, architecture vision, organization
readiness and risk analysis.35,36 LeSS suggests only a straightforward
and short meeting, in which the Product Owner presents the priori-
tized list of items that are ready for development and their clarification
together with the definition of the Sprint goal. The teams then select
which items they will work on.27
6MARTIN KALENDA ET AL
SP6. Scaled Retrospective: a meeting that reflects on the execution of
the previous iteration above the level of a single team. Teams should
brainstorm about larger obstacles that are impeding them. The meet-
ing is a part of the Inspect and Adapt workshop in SAFe.35,36 LeSS calls
it Overall Retrospective.27
SP7. Feature Teams: cross-component, cross-functional, stable, long-
lived and self-organized teams that can help in design, planning and
implementation in a sprint.59 Therefore, a Feature Team should be able
to fully implement a feature that spans across any component of a
product and ideally the team should be stable for several years. LeSS
and SAFe suggest using Feature Teams instead of specialized teams for
individual components.35,36, 27
SP8. Undone Department: a group of teams that support develop-
ment teams to achieve potentially shippable increments at the end
of each iteration.35,36 Both LeSS and SAFe agree that teams should
be able to create potentially shippable increment at the end of each
iteration.35,36, 27 An Undone Department is supposed to aid with the
overall definition of "done" in an iteration. The Undone Department
can support with all cross-cutting concerns that are part of product
development, from architectural design to Quality Assurance (QA)
activities.27
4 REVIEW OF PRACTICES, CHALLENGES AND
SUCCESS FACTORS IN SCALING AGILE (STEP 1)
With the emergence of Evidence Based Software Engineering
(EBSE),65,66 a plethora of systematic literature reviews were performed
in the area.67 There is a huge variation of methods that can be applied
in place or as complement of traditional literature reviews:68 from
Systematic Literature Reviews (SLR),69,67 Systematic Mapping Studies
(SMS),42,41 Multi-vocal literature reviews,70 to meta-analysis reviews.71
The main discriminating factor is the final goal of the review.68 As
reported (Research Methodology, section (2 ), our literature used simi-
lar process to an SMS and an SLR,41–43 although our aim was different
and the applied process was less extensive. In this section, we report
about the focused literature review that was conducted as a first step
towards the action research process.
4.1 Methodology
The literature review study was performed using four digital reposito-
ries (IEEE Explore,Springer,Research Gate,ACM). The goal was to map the
practices identifies in the previous section from SAFe and LeSS to expe-
riences and lessons learned in the transformation process. We aimed at
answering three main questions:
RQ1. Which agile scaling practices reported in literature did large compa-
nies (embracing practices from SAFe, LeSS) use?
RQ2. Which challenges reported in literature did large companies (embrac-
ing practices from SAFe, LeSS) face when adopting scaled agile devel-
opment?
RQ3. Which success factors reported in literature helped large companies
(embracing practices from SAFe, LeSS) to adopt and scale agile devel-
opment?
We defined search strings for three facets to find relevant primary
studies:
1. Agile methods ("agile, lean, scrum, kanban, agile");
2. scaling frameworks ("large scale scrum, OR scaled agile framework
OR safe OR disciplined agile delivery")
3. We could not include a third facet for large organizations, so
we performed a successive filtering: to include one paper in
the review, an examined company needed to have at least 50
employees and multiple teams developing one product.
We defined the following inclusion / exclusion criteria:
1. primary studies could be eligible;
2. inclusion of gray literature, if found (this was the main choice to
include a repository such as ResearchGate)
3. English language only;
4. Excluding papers that did not deal with the practices of SAFe or
LeSS identified in the previous section;
5. Excluding articles that did not provide lessons learnt in terms of
evidence from case studies / surveys;
Results of full-text search in all the repositories (IEEE, SpringerLink,
ACM, ResearchGate), are presented in Table 2 . After title, and abstract
reviewing, we included 12 articles in the review (Table 3 ), that also
represents the mapping of articles in the figures to the corresponding
citation.
4.2 Results
To answer the research questions, we next present three mappings
(practices, challenges, success factors), discussing each finding accord-
ing to the classification scheme that was derived from either the articles
or the initial review of scaling frameworks. If some papers are not
included in one of the mappings in subsequent figures (Fig. 2 , 3 & 4 ), it
is because we did not find a relevant mapping to the factors in the paper.
4.2.1 Scaling Practices
Taking into account the common practices identified in the SAFe and
LeSS frameworks, this section describes which scaling practices were
found in the reviewed literature (Fig. 2 ).
MARTIN KALENDA ET AL 7
TABLE 2 Repositories and query results. All were full-text search (not
just meta-data)
Repo Query Results
IEEE ( agile, lean, scrum, kanban, agile ) AND
(large scale scrum OR scal* agile frame-
work OR safe OR disciplined agile deliv-
ery)
105
Springer agile AND lean AND scrum AND kan-
ban AND agile AND ("large scale scrum"
OR "scaled agile framework" OR safe
OR "disciplined agile delivery")
60
ACM "query": { content.ftsec:(+agile, +lean,
+scrum, +kanban, +agile large scale
scrum, scaled agile framework, safe, dis-
ciplined agile delivery) }
73
Research-
Gate
manually queried –
FIGURE 2 Mapping of papers to individual scaling practices. O = the
practice is discussed in the article
SP1. Scrum of Scrums: was the most used scaling practice.72,74–76, 78, 79
A typical use of SoS was for synchronization between teams,72,74, 76 but
in some cases it was used as a daily meeting, which can lead to prob-
lems over time due to the many distributed teams that needed to be
represented.74,79 Feature specific SoS was used to avoid the problem of
too large meetings.79 Oversize SoS meetings can cause teams to stop
reporting their impediments, feeling there is not enough time during the
meetings.74 As LeSS or SAFe suggest, having team representatives in
the meetings can reduce this issue, however they need to be involved in
team’s work to bring useful points to the discussion.35,36, 27
SP2. Communities of Practice: in total, five cases mentioned the use of
CoPs.75,77, 79, 80, 83 CoPs resolved the lack of information about system
design, agile development, and tools,77,79 or were used for knowledge
sharing and promotion of best practices to facilitate the transition to
Feature Teams.80 CoPs were also used for coaching, coordination, and
design between teams, improving software craftsmanship and tech-
nologies and improving the way of working.84
SP3. Scaled Sprint Demo: in all cases, the Scaled Sprint Demo was uti-
lized as a demonstration of features of all areas of a product.72,74, 75 Scal-
ability of the demo can be an issue in case of many teams attending,74
suggesting to either let the Product Owner attend the demo sessions or
using a science fair model with teams showcasing their effort on some
stands.74,75 The case by Paasivaara and Lassenius74 experiencedseveral
problems with the Scaled Sprint Demo. At first, the meeting was held
in a big auditorium with all teams attending it. As the project grew, the
Scaled Sprint Demo became too large. Thus teams started to have sep-
arate demo meetings, with only Product Owners attending them, but
this did not give teams enough context of the whole product. The next
step was to use the Scaled Sprint Demo in one place with all the teams
again, but due to time constraints, the demonstrations of the teams
were reduced to slide presentations. Authors reported that the orga-
nization is planning to revert the Scaled Sprint Demo back to separate
demonstrations of individual teams.
The organization reported by Long and Starr75 went through a similar
transformation of Scaled Sprint Demo as the previous organization.74
The first attempt was to let teams do a demonstration of their work in
one place. The second stage was to have only a slide presentation by
each team. The last state of the meeting was a so-called science fair
model: "each team sets up a display, and employees visit those displays they
find interesting. Each ’booth’ offers a 15-minute presentation about recent
work efforts".74 A similar model is suggested by LeSS.27
SP4. Scaled Requirements Management: scaling of requirements man-
agement was identified in three cases.74,76, 80 Cross-component depen-
dencies can be an issue as they lead to large component overhead not
allowing separate meetings for different product areas.74,76 Adjusting
the architecture of a product according to the needs of large-scale
software development can be a key factor.76
SP5. Scaled Sprint Planning: scaled Sprint Planning was identified in
three cases.72,74, 80 It might be challenging in a distributed project with
multiple sites, as it can lead to late planning, wrong estimations, and mis-
understanding of requirements.72 Additional meetings were required
to explain requirements to the teams sufficiently.74 Teams also needed
more detailed explanation and clarifications in terms of Feature Inves-
tigation and Feature Concept Study for each feature, to find out if a
feature is doable, how much effort is required and how it can be imple-
mented.80
SP6. Scaled Retrospective: Scaled Retrospectives were identified in
two cases,72,74 noting that problems identified can be too large and com-
plex to be solved. An issue with Scaled Retrospective in the organization
reported in Paasivaara and Lassenius74 was that the problems identified
in the Scaled Retrospective were often too big and hard to solve. Resolu-
tion of these challenges might take several months. Therefore the same
problems were identified by teams in several consecutive iterations
of the meeting. Thus teams questioned the usefulness of the meeting
as they identified the same impediments again and again, without any
progress.
SP7. Feature Teams: only two cases79, 80 mentioned the use of Fea-
ture Teams. Unfortunately, none of these cases was successful. In one
8MARTIN KALENDA ET AL
TABLE 3 Mapping of articles to references
ID C1 C2 C3 C4 C5 C6 C7
Ref →Vallonet al (2013)72 Moe (2013)73 Paasivaara and Lassenius (2016)74 Long and Starr (2008)75 Schnitter and Mackert (2011)76 Atlas (2009)77 Hanly et al (2006)78
ID C8 C9 C10 C11 C12
Ref →Paasivaaraet al (2013)79 Paasivaara et al (2014)80 Schatz and Abdelshafi(2005)81 Hajjdiab et al (2012)82 Benefield (2008)83
case by Paasivaara et al,80 the organization created cross-component,
cross-functional teams specializing on specific business flows. This spe-
cialization allowed the teams to focus on a narrower product area.80
In another case by Paasivaara et al,79 the solution was to establish a
systematic exchange program between teams.
SP8. Undone Department: although many cases had to cope with
architecture design problems and with inadequate development infras-
tructure,72,74, 75, 79 only two cases mentioned the use of an Undone
Department,74,76 namely an Architecture Team consisting of 9 high-
level technical specialists in Paasivaara and Lassenius,74 and testers,
quality assurance experts and DevOps teams in Schnitter and Mack-
ert.76
4.2.2 Challenges
There were several challenges that the companies experienced during
their transformation to large-scale agile development (Fig. 3 ). We sum-
marize them, together with comments about each of the challenges. For
each challenge, we give a common identifier (SC =Scaling Challenge).
FIGURE 3 Mapping of papers to individual challenges. O = the challenge
is discussed in the article
SC1. Resistance to change: resistance to change and attachment to
previous processes were very common challenges. Some form of resis-
tance to change was reported in eight papers.73–77, 80, 82, 83 The resis-
tance occurred at all levels of organizations, including development
teams, middle and upper management. Moreover,in large organizations,
the resistance to change on higher levels, such as middle and upper
management, is a more significant problem.73,74, 77, 80, 82 For a successful
transition, a supportive change management is necessary: several cases
faced significant challenges due to lack of it.
One of the reasons why team members did not want to change to
agile development was an increased transparency75,76 because people
felt observed and did not want to share their problems. Another reason
for the resistance were the new responsibilities that agile development
brought to teams. Teams are expected to be self-managed in agile devel-
opment, but not everybody was pleased. As Long and Starr75 reported,
teams did not want to solve their new problems. Firstly, in agile devel-
opment middle management is not expected to manage teams anymore.
This shift of responsibilities of middle management caused confusion as
well as resistance to change because managers feared that they would
not be needed anymore.73 Secondly, managers did not respect team’s
decisions and their visions of a development process. In Paasivaara and
Lassenius,74 managers tried to micromanage teams. This micromanage-
ment caused several problems, one of them was that teams lost interest
in meetings and stopped attending them, as they were not responsible
for synchronization and communication, and therefore found the meet-
ings useless. Lastly, in Hajjdiab et al82 teams were unmotivated due to
lack of resources and lack of recognition for their efforts to improve the
development process. In the end, the teams gave up their endeavors.
SC2. Distributed environment: any organization that had its devel-
opment teams distributed across several sites experienced significant
challenges with agile development. Challenges due to distributed envi-
ronment were reported in six cases.72,73, 75, 76, 79, 80 Agile development
puts emphasis on constant communication and team spirit. Distributed
environment makes these close relationships hard to obtain.76 Trans-
parency is one of the cornerstones of agile development, and without
it, agile development cannot succeed. Achieving transparency between
teams that are distributed across multiple sites is very complicated.72
Information sharing might be easily forgotten in a multi-site environ-
ment. Information from discussions and meeting notes from one site
might not reach other locations. The organization should emphasize
transparency of all information between sites and provide necessary
tools, such as wikis and video conferencing. It is important to have all
the needed knowledge and infrastructure at each location.79 To miti-
gate these challenges, Paasivaara et al80 suggested visiting engineers
and providing high-quality video conferencing equipment.
SC3. Quality Assurance issues:five studies73,75, 76, 79, 80 reported prob-
lems with quality assurance and a loss of quality in code shortly after the
transition to scaled agile processes. The quality loss was caused mainly
by additional responsibilities, pressure on teams or bad definition of
the concept of "done".73 Teams skipped bug fixing,73,75 testing and did
MARTIN KALENDA ET AL 9
not use continuous integration,79 thus technical debt piled up. Prob-
lems with large technical debt might take years to solve.79 The quality
loss resulted into teams discouragement. The teams started to lie and
report false status of their work to hide the problems.73 These issues
were mainly solved by introducing an Undone Department and train-
ing. For example, the organization reported in Longand Starr75 included
testers and quality assurance experts in the teams. The experts defined
tolerance levels of technical debt for individual products: new features
could not be added to a product whose tolerance levels were not satis-
fied. Additionally, Longand Starr75 proposed that teams should be fixing
bugs immediately. Paasivaara et al80 suggested establishing a common
backlog, introducing supportive roles, such as people responsible for a
particular subsystem and architects, building an appropriate test envi-
ronment and training personnel on continuous integration. The Undone
Department of the organization76 included an Architectural Team, a
Support Team—which removed impediments that could not be resolved
by development teams— and an expert lean team.
SC4. Integration with non-agile parts of organization: misalignment of
organizational structures caused problems in four cases.75,76, 79, 80 For
example, the problem was that non-agile teams did not want to rely on
agile teams—not knowing whether the agile teams would deliver their
work on time. These issues can be solved by including waterfall parts of
the organization in the planning process and involving non-agile teams
early in planning process.80 Also, improvement of continuous integra-
tion and test automation systems helps, as it allows faster and better
integration.80
SC5. Lack of commitment and teamwork: three cases reported prob-
lems with commitment and teamwork.72,73, 76 Vallon et al72 indicated
that issues with the dedication of teams were caused by frequent
changes to User Stories which were being implemented and uncertainty
due to wrong and late specification of User Stories. Lack of teamwork
was also due to the specialization of team members.73 Specialized peo-
ple in teams were concerned with their problems and did not want to
commit to a common team plan. Team’s definition of "done"was also very
different across team members: individual team members prioritized
different concerns based on their specialization. Distributed decision
making was hindered as well, team members did not understand work
of others and therefore did not want to rely on the others. Addition-
ally, knowledge sharing was not working as the specialists realized that
they are important for the company. They did not want other develop-
ers to know how to do their special job because that made them more
indispensable for the company. All of this resulted in a very compet-
itive environment, and therefore some people were scared to report
their problems. In one case, teamwork was hindered, because people
thought that Scrum was introduced to increase efficiency and substi-
tutability of programmers. Also, they thought that flatter management
hierarchy offered fewer career opportunities. Hence, people tried to be
more visible and competitive.76
SC6. Too much pressure and workload: high pressure and workload
caused many problems. Issues related to them were reported in five
cases.72–75,82 A new way of working, new responsibilities, together
with constant market pressure increased tension in teams. This tension
resulted in bad quality code and late planning.72 Teams also skipped
testing, refactoring, defect fixing, and engineering practices, thus cre-
ating a lot of technical debt.73,75 Furthermore, as the teams that were
new to agile development had not yet realized the importance of pro-
cess improvement, too much pressure caused them not to comply with
their responsibilities.73,74, 82 Time deficit caused teams not to care about
the identified issues from their Retrospectives. Hence, these problems
never made to the top of their backlogs.73 In Paasivaaraand Lassenius,74
inexperienced teams did not have a shared vision of Scrum and their
development process yet, therefore it was essential to let them have
enough time to develop such vision. Moreover, high pressure impeded
communication in teams. Teams started to skip and postpone meetings.
Therefore daily meetings became weekly and then even monthly.82
SC7. Lack of knowledge, coaching, and training: the most common
challenges—which in many cases became the cause of other difficulties
and problems—were a lack of knowledge, training, coaching or under-
standing. These issues were reported in ten cases.72–77,79, 80, 82, 83 Several
factors caused the lack of coaching and knowledge, most of the time
due to underestimated difficulty of the agile transformation, financial
constraints, lack of support of management or rushed transition. For
example, the organization in Hajjdiab et al82 underestimated the diffi-
culty of agile adoption. The organization did not have sufficient knowl-
edge in their ranks but refused to use external expert due to financial
constraints. Instead, managers who were new to agile took the role of
agile experts. There were several consequences of lack of coaching and
training. Teams could not change their habits as easily as they expected.
Schnitter and Mackert76 reported that due to a fast transition with a
lack of knowledge and experience, many assumptions were purely the-
oretic. Therefore a lot of unexpected problems emerged. Additionally,
the case reported that the teams that were mentored performed better
than the teams without mentoring.76
The consequence of lack of knowledge was the erroneous imple-
mentation of agile practices. For example, in three cases people did
not understand the purpose of meetings.73–75 Teams were not finding
underlying causes in retrospectives, but merely identifying symptoms.
Also, teams did not respect core principles of practices they were sup-
posed to implement, such as respect for iterations in Scrum, prioritiza-
tion of User Stories or the importance of customer contact.74,75
The consequence of such misunderstanding was an overzealous
change. Although the teams had all the information about the prac-
tices, they did not understand them and used them improperly. For
example, the organization in Benefield83 experienced a situation where
a manager enforced Scrum practices in a strict, by-the-book fashion and
forced them against their will. Also, some teams followed the practices
too religiously and lost perspective.
Furthermore, the transition to large-scale agile required training in
domain knowledge as well. In Paasivaara et al79 the organization had
to train teams in other domain areas to establish feature teams, due to
10 MARTIN KALENDA ET AL
the previous component-based architecture of their product. Appropri-
ate coaching of management increased management support of agile
methods.83
SC8. Requirements management hierarchy: in large projects, require-
ments are not manageable by a single person (Product Owner), hence
there is a need to divide the responsibility of their management. This
division was in many cases a significant challenge.74,76, 79, 80 Scaling of
requirements management cannot be avoided when scaling agile. The
fact that some organizations had to adjust the whole architecture of
their products, like in Schnitter and Mackert,76 shows such difficulty.
The fact that the entire transition may fail due to the wrong division of
a product in areas as in Paasivaara and Lassenius74 demonstrates the
importance. Hence, it should be done carefully and properly.
SC9. Measuring progress: when an organization is changing the devel-
opment process, measuring the changing trend is important. However,
this proved to be challenging in large-scale agile development, as three
cases77,80, 83 experienced difficulties when it came to monitoring and
measuring the progress of their agile development. The biggest problem
was finding the right metrics—the organizations did not know what to
measure to get meaningful results.83
4.2.3 Success factors
From all the papers included in the review, we identified and grouped
reported success factors into seven groups (Fig. 4 ). Each factor is given
a unique identifier (SF =Success Factor).
FIGURE 4 Mapping of papers to individual success factors. O = the
success factor is discussed in the article
SF1. Acquire knowledge: as the most reported challenge was a lack of
knowledge, it is no surprise that the most common reported success
factor was to try to increase the level of knowledge and expertise on
agile practices. Thorough, deep and systematic knowledge acquisition
and sharing were stated as success factors in eleven cases.72,73, 75–83
The most recommended way to acquire knowledge and expertise was
to hire an external expert with broad and deep familiarity with agile
development.75–78,82, 83
The external expert shared his knowledge with several internal
employees, who then spread it across the organization. One of the rea-
sons why it was more beneficial to bring an expert than investing into
knowledge acquisition from other sources, was that organizations real-
ized the general and theoretical suggestions were not easily applicable
in their particular context, and a deeper understanding of the methods
was needed.72,78 Another recommendation was to coach people deeply
and not broadly. For example, Hanly et al78 stated that coaching has to
be about both values and processes, but unfortunately, the values are
often omitted. The lack of understanding of values might lead to a lack of
pragmatism and inability to deal with the new and unknown situations.
Agile means to be flexible, but its tailoring requires a deep understand-
ing of its values. It is better if people are committed to constant learning
than committed to particular agile method or principle.73 Also, it is
valuable to teach teams how to learn, for example using double-loop
training, so they are better at finding an underlying cause of a problem,
and they can adjust their team processes correctly.73
According to two cases,77,83 it is important to coach people and not
to dictate them. Coaches should be using "should" instead of "must" and
let the transformation be a bottom-up approach. As for successful agile
transformations, it is a must to have employee support.83 Furthermore,
a systematic training of coaches and other people inside of an organi-
zation was required for successful large-scale agile adoption.77,78, 82, 83
Systematic coaching and training both mean to have recurring events,
presentations of external experts or Communities of Practice. Besides,
systematic training ensures enough available coaches in an organiza-
tion. Lack of coaches leads to the uncontrolled and untrained adoption
of agile methods by overzealous teams. Changing their wrong habits
was harder than changing a team without any experience.83 Moreover,
so-called pair coaching, which combines agile experts with an expert
with domain knowledge to enable more efficient and accurate coaching,
proved to work well.78,83
SF2. United view on values and practices: for a successful agile tran-
sition, it is necessary to define a common view on the change. In total,
six cases found unification of values, definitions, way of working and
understanding beneficial.75,76, 78–81
There is a need to define roles, their responsibilities, and common
definitions properly. Also, it is important to point out wrong ideas and
misconceptions.78 Teams are more willing to follow an unified view on
Scrum.75 Schnitter and Mackert76 stated that it was beneficial to use a
common language between teams, architects and Product Owners, such
as established agile definitions, the Unified Modelling Language (UML)
or Fundamental Modeling Concepts (FMC). There are several ways to
establish a shared view and way of working. For example, it can be
done through coaching, documentation,78 Communities of Practice84 or
value workshops.80
SF3. Tools and infrastructure: organizations have to be prepared to
provide sufficient resources to teams while transforming to agile devel-
opment. Five cases72,76, 79–81 stated that decent tools and infrastructure
were helpful. The tools include, for example, development and local test
environments, continuous integration and automated tests, communi-
cation infrastructure including video conference equipment.79 Common
tools and infrastructure were particularly beneficial in a distributed
environment, where teams need all the help to reduce their communi-
cation impediments.72
MARTIN KALENDA ET AL 11
SF4. Solid engineering practices: many teams experienced loss of qual-
ity in their code during an agile transformation. Therefore, having solid
engineering practices is crucial.75,83 Long and Starr75 suggested includ-
ing QA and testers into development teams. Additionally, good technical
debt management, such as tolerance levels and visual indications for the
tolerance levels were suggested.75
SF5. Careful transformation: changing an organization to agile develop-
ment means changing the mindset of people. This change might take a
long time. Hence, a slow and careful transformation was needed in six
cases.73,75, 76, 81–83 It is better to perceive the transformation as a long-
term organizational change.73 The organization should improve the
development process gradually and take at least three months before
changing methods and practices.75 Organizations should also reassure
to have all the necessary resources—such as enough time, a prepared
plan and expertise—before making the transition. Teams need time and
space to learn and adapt to the new way of working and change their
habits. Thus, the organization should give them enough time and not
overpressure them82 or let them work overtime.81
SF6. Teamwork support: seven cases reported that close connections
and constant communication between teams and team members are
necessary for successful agile development.72–74,77, 79, 81, 83 The organi-
zation should establish a transparent environment for openness in the
team without fear of discussing problems to improve teamwork.73,83
Also, it is better to keep teams small.77 Communication between teams
and team members can be enhanced by SoS meetings and CoPs. These
practices are "both forums and provokers of discussion".79
SF7. Executive sponsorship: executive sponsorship is the most funda-
mental factor for a successful transformation of an organization.73,75
Without proper executive sponsorship, no other success factors would
be realizable, as not enough resources would be allocated. Five cases
stated that an executive sponsorship and management support is a
must.73,75, 77, 79, 81 Obtaining executive sponsorship might be problem-
atic if the transition to agile is a bottom-up incentive. The only sugges-
tion we found was to gather enough proof about the effectiveness of
agile development, by means of a measurement program.73,75, 77, 79, 81
4.3 Threats to Validity
There are few internal and external limitations in the literature review
performed which need to be considered. We did not follow all the
phases of the systematic mapping processes,41,42 as our aims were dif-
ferent. Concretely, we did not conduct the fourth phase—keywording
of abstracts. However, there were two reasons for this decision. Firstly,
we already had a set of categories of common scaling practices from the
initial definition of practices. Secondly, success factors and challenges
cannot be inferred by simple keywording of abstracts.
The needs for our literature review were peculiar due to the collabo-
ration with industry.It is common knowledge that majority of practition-
ers do not read research articles.85 This does not depend—or depends
partially— on the fact that research is answering interesting questions
from practitioners point of view, as there can be a gap,86 but also from
the fact that that journal and conference papers are not a good com-
munication channel between academia and industry.87 For this reason,
we needed some targeted review for the company audience: providing
to company’s stakeholders previous excellent systematic reviews pub-
lished in the area (e.g. Dikert et al34) would have not been sufficient to
reach our goals. Thus, the literature review in this paper needs to be
read in this sense, not as exhaustive, rather supportive of the subse-
quent action research process. Our goals were to provide the organiza-
tion with the synthesis of all was known from literature in terms of map-
ping of practices from SAFe and LeSS. The extensiveness of the review
was not the main goal: the completion of the review was needed in due
time before the action research process could start, as collaboration
with industry need to comply to strict time requirements.88–90
5 ACTION RESEARCH IN A LARGE ORGANIZATION
(STEP 2)
The review of the practices, challenges and success factors from lit-
erature was the theoretical input for an action research run within
Kentico1, a software development company with headquarters in Brno,
Czech Republic. Kentico was founded in 2004 and has nowadays around
200 employees. The primary product is a platform which includes a
Content Management System (CMS) and e-Commerce and Online Mar-
keting features. Recently, the company started to shift its focus towards
the Cloud platform. The project started with one team that was given
absolute freedom to define its development process. Other three teams
were added. These teams were still free to select tools, technologies and
partially define their development process. The teams were separated
from the former organization structure. Each team developed a differ-
ent part of the complete Cloud solution. The main problem was that the
Cloud platform started to grow, and the organization wanted to allocate
more developers and resources. Therefore, a more precise development
process was needed.
5.1 Contextual Information
At the beginning of the action research process, the new Cloud plat-
form had four development teams (Fig. 5 ). Each team had its Product
Manager and Agile Coach. Product Managers were coordinated by the
Director of Product and Agile Coaches by the Development Direc-
tor. The Architecture Team was being consulted regarding the product
architecture. There were additional specialized roles that supported
the teams: there was a Security Specialist who specialized in product
security, and Quality Assurance Coordinator who was in charge of the
DevOps team. Agile Coaches, the Security Specialist, and the Quality
Coordinator were coordinated by the Development Director. There was
also a team of Technical Writers which was responsible for the techni-
cal documentation. Furthermore, a User Experience Team was available.
1www.kentico.com
12 MARTIN KALENDA ET AL
FIGURE 5 Structure of the organization
We describe in more detail the different roles, as the action research
process started.
5.1.1 Development Teams
At the beginning of the action research process, all four development
teams were using Scrum. Additionally, lean principles were utilized,
mainly focusing on waste elimination, but also addressing other six prin-
ciples of lean. Each team had its Product Manager and Agile Coach.
Moreover, some team members had specialized roles such as DevOps
and UX Designers.
Teams were in contact with the customer primary through interviews
aimed at solution validation. Usually, one developer together with the
Product Manager was communicating with the customer. Other team
members could use recordings of the calls. The Product Manager was
summarizing the result from the interviews on a daily basis. Addition-
ally, everybody in the teams had access to the so-called Product Board,
which was a tool used for aggregation of feedback from customers.
Teams had a synchronization meeting every day — the Scrum daily
meeting. Every week, there was the whole Cloud platform synchroniza-
tion meeting. It was attended by the Director of Product, the CEO, and
representatives from all teams. Additionally, each team had a meet-
ing with the CEO to discuss their progress and future steps. The other
meetings such as design workshops, synchronization meetings between
teams, risk analysis meetings, were organized ad-hoc.
In three teams the backlog was owned by the team instead of the
Product Manager. The reason was to allow Product Managers to focus
more on their tasks. Initially, the backlog was prepared by the Prod-
uct Manager, but the company decided that the role should concentrate
more on obtaining feedback from customers and on market analysis.
Thus, the ownership of the backlog was moved to the teams while Prod-
uct Managers were bringing inputs to the teams from outside. This
change helped the organization as intended. Product Managers had
more time for focusing on the market. Additionally, the teams better
understood needs of customers, since they needed to work with the pre-
viously provided inputs. Therefore the teams were more active, asked
additional questions and analyzed data more carefully. There were also
some challenges connected to this change. Firstly, at the beginning,
the motivation behind this change had to be explained properly, so the
teams would participate. Secondly, the teams were in different stages of
product development, thus when a new feature was being implemented,
the overall view-point and its implementation were very different in the
individual teams. Last but not least, the new way of working created
additional overhead for the teams for the creation of the User Stories.
5.1.2 Product Managers
Product Managers were responsible for finding a problem-solution fit
and product-market fit, the return on investment, the competitive land-
scape analysis, the win/loss analysis, the buyer and user personas and
the go-to-market strategy. The responsibility for the go-to-market strat-
egy was shared with Sales and Marketing departments. Product Man-
agers were supervised by the Director of Product.
Product Managers were part of the development teams: they were
sitting in the same office and communicated with the teams on a daily
basis. Synchronization between Product Managers was mostly ad-hoc.
Two synchronization meetings were held each week, one for cross-
team synchronization and the other for synchronization among Agile
Coaches and Product Managers.
5.1.3 Agile Coaches
Each team had one Agile Coach. The four Agile Coaches together with
the Development Director were part of the Scrum Master team. Agile
Coaches were responsible for the satisfaction of team members, their
motivation, team organization, and team administration, information
spreading, helping teams with global issues and impediments and soft
skills teaching. They also participated in the hiring process.
Agile Coaches increased their skill by sharing their knowledge, for
example using knowledge base tools such as the Confluence software,
and attending agile and lean conferences. Agile Coaches also visited
other companies and shared their experience with them. There was also
the so-called Scrum Club, which was one-hour meeting for additional
knowledge sharing.
Agile Coaches attended several meetings such as Scrum of Scrums,
Cloud platform synchronization meetings and product strategy meet-
ings. They were in contact with the teams on a daily basis and also had
regular one-to-one meetings with team members.
5.1.4 Director of Product
The Director of Product was responsible for the complete accomplish-
ment of the product. His responsibilities included timely product deliv-
ery to the market, product communication to the market and product
adoption by the market. He was also driving cross-team prioritization
and validation of cross-team iteration outcome, by managing Product
Managers. He attended weekly teams synchronization meeting and
MARTIN KALENDA ET AL 13
weekly synchronization meetings for Agile Coaches and Product man-
agers. Additionally, he was having one-to-one meetings with Product
Managers.
5.1.5 Development Director
The Development Director was responsible for the effective coopera-
tion among the development and other departments, correct operation
of the development organization, increasing employee value and help-
ing them with career paths, correctly interpreted and implemented
company strategy and vision, performance and efficiency growth of
development and implementation of continuous improvement mech-
anism into the development organization. The Development Director
visited synchronization meetings for the Cloud platform, Agile Coaches,
and Product Managers every week.
5.1.6 CTO and Architecture
The CTO was a member of the Architecture Team. His role was to con-
sult the architecture of the planned features. He was also a team mem-
ber of one of the development teams. The Architecture Team reviewed
the implemented User Stories from the architectural point of view and
notified the teams if there was something that needed to be addressed.
The architecture was discussed during the Cloud platform synchro-
nization meeting and during ad-hoc meetings when the teams needed to
discuss.
5.1.7 DevOps
The DevOps team was responsible for various tools and the develop-
ment infrastructure: this included version control tools, code merging,
monitoring applications performance, infrastructure configuration and
management, release automation, artifact repository, test and result
performance, continuous integration tools and build status. DevOps
representatives attended synchronization meetings for Agile Coaches
and Scrum of Scrums. Additionally, there were weekly synchronization
DevOps meetings and also ad-hoc DevOps meetings with the develop-
ment teams.
5.2 Research Questions
We defined three main research questions that were the target for the
whole action research process. These research questions were mim-
icking the ones we set for the initial literature review part (section
4)—this time contextualized to the main company’s context. This would
allow to determine differences between the case studies included in the
literature review and the results derived from the action research.
RQ4. Which agile scaling practices were the most effective in the com-
pany’s context?
RQ5. Which challenges did the company face when adopting a scaled agile
development process?
RQ6. Which success factors were relevantin the company to adopt a scaled
agile development process?
5.3 Data Collection & Process
The collaboration with Kentico lasted for a period of around 8 months, in
which the action research process took place. During this period, one of
the researchers was in contact with Kentico and was actively involvedin
the provision of feedback based on the necessities arising from the scal-
ing process (Fig. 6 ). The researcher had access to the online tools used
for documenting the development process—mainly issue trackers—with
a more limited set of permissions than developers. He could also have
access to meeting notes—when the information shared during the meet-
ings was not considered as reserved. Another author was the main
contact at Kentico, and would allow for faster communication with the
development teams and the other parts of the organization. The main
contact point was helpful to reduce the burden of communication and
provide access to any relevant information, granting that no reserved
information would leave the company. If information from the teams—
that could not be derived from the shared documents— was needed,
the main researcher would get in touch with the main contact point
at Kentico. The same worked in the other direction, from the devel-
opment teams to the researcher, as a kind of two-way communication.
Although this seems as a level if indirection, in reality it provided quick
information to the researchers. Only violation for this research setting
were direct interviews from the main researcher to different roles in
the development teams, that clearly could not pass through the main
contact point at Kentico. Based on the literature review and emerging
new knowledge during the process, suggested practices were commu-
nicated by the main researcher to main contact point that would then
provide feedback back to the researcher based on the application within
the teams. Clearly, the changes to the development process were at the
discretion of the development directors / development team—this was
a real setting in which products needed to be shipped.
FIGURE 6 Collaboration academia-industry during the action research
process (structure of the development teams is explicated in Fig. 5 )
14 MARTIN KALENDA ET AL
FIGURE 7 The dialogical action research process (adapted from
Mårtensson and Lee91)
Data was collected / exchangedcontinuously using several methods2.
1. There were several meetings during which the problem domain
at Kentico was defined.
2. Afterwards, the main Researcher presented solutions from lit-
erature in several iterations and discussed the progression with
concrete problems in more detail.
3. Once the problems at Kentico were properly understood, a ques-
tionnaire was created. The questionnaire was given to the main
contact at Kentico that distributed it to the different roles.
The roles which we included were managers, developers, Agile
Coaches, DevOps, and members of Support Team. The goal of
the questionnaire was to get additional opinions from different
points of view. Additional questions were discussed using online
communication. The questionnaire was submitted twice, once at
the beginning of the research process and at the end.
4. Interviews were the primary source of information. The main
researcher conducted six interviews which were about an hour
– an hour and a half long. Additionally, constant online communi-
cation was realized for additional specification, clarification, and
validation of information.
There can be different types of action research,92,93 and the type of
action research we applied was in line with action science: where the
goal of research is to solve a problem in client organization by exposing
differences between given theory and theory in use.94
The design of the action research process took inspiration from the
dialogical action research process,91 in which knowledge evolves over
time from both sides of researchers and practitioners (Fig 7 ). The main
researcher would propose to the main contact at Kentico approaches to
experiment based on the evolving knowledge from both the literature
review and the previous feedback from the development teams. Devel-
opment teams would get information about approaches that could be
meaningful to try in a real setting. Iteration zero dealt with the provi-
sion of the results from the literature review (section 4). The diagrams
2questionnaire and interviews material is available online https://goo.gl/
n81tAj
from the literature review (Fig. 2 , 3 , & 4 ) proved to be a quick and
effective way of communication also with the main contact point. Such
knowledge evolved during the action research process, as some of the
approaches were changed by the development teams.
5.4 Results
We present the main results from the action research, discussing
changes during the process (section 5.4.1), the identified scaling prac-
tices (section 5.4.2), challenges (section 5.4.3) and success factors
(section 5.4.4). We conclude with suggestions that were derived from
the action research process (section 5.4.5).
5.4.1 Changes during the action research process
Compared to the initial situation at Kentico we reported at the begin-
ning of this section, there were several changes that were performed.
•Meetings. Scrum daily meetings were still used within the devel-
opment teams. In general, the synchronization of the teams
via various platforms stayed the same (no change). A leader-
ship meeting was introduced to discuss company topics (mission,
vision, strategy);
•Backlog Management. There were no changes to the product
backlog management. Opportunities (Epics) defined by Product
Managers and UX teams were introduced.
•Changes in roles. The Development Director is now closely
cooperating with the Scrum Master Leader for assistance in solv-
ing strategic topics. The Product Manager Team Lead role was
introduced—helping with the organization of the Product Man-
ager Team (similar to a Scrum Master Leader role).
•Software Architecture. Changes introduced: every team has to
validate their changes in the architecture with the Architect Role
(currently two). The team has to prepare the overview regard-
ing the Opportunity and its effect on the architecture, architects
will then review it and discuss with teams further questions if
needed.
•Scaled Retrospective. The Milestone Retrospective (held 4
times a year) was introduced—people in the development can
add their topics, and after all topics are collected, there is vot-
ing mechanism. Top voted issues are then discussed in separate
meetings—all voters are invited to the session.
•Scaled Planning. There is more flexibility—originally the priori-
tization was happening every 3 months only. The prioritization
happens now on monthly bases, where new opportunities are
introduced and then prioritized against already prioritized ones.
•Iteration Reviews. Shifted to Thursdays bi-weekly—two parts:
public, and private (where news related to marketing, sales, and
customer success are shared).
MARTIN KALENDA ET AL 15
•Scrum of Scrums. the concept remained the same.
•Requirements Management Scaling. The handling of the back-
log was unified across the teams. There is one backlog with all
the bugs for cross-development teams (based on the agreed
rules, the teams are supposed to take specific amount of bugs
in one sprint and fix them). There is also one common backlog
for UX improvements. Each iteration has a naming convention
for automation of data collection: status from iterations can be
automatically filled daily without manual operation.
•Undone Department. the concept remained the same.
•Communities of Practice (Guilds). No significant changes. Cod-
ing Dojos95—meetings in which group of programmers get
together to learn and practice—were run monthly.
•Differences in agile culture across company. The new vision
and mission was discussed and introduced to the employees. A
new aspirational value was introduced—"Strive for excellence". In
general, continuously visiting conferences, gatherings and shar-
ing with other companies the experiences, being open to any
practice are relevant aspects.
•Process measures. Continuously monitoring the backlog readi-
ness and the ratio of maintenance within every iteration is
applied. Committed / Delivered is also being monitored.
•New Software Engineering Practices. Usage of the Gherkin
notation3was introduced to be able to better address the need
of automation tests. Combining agile, lean methodologies and
experimenting are aspects that are enforced.
5.4.2 Scaling Practices
Throughout the action research process, we identified a series of agile
scaling practices that the organization used. The identified seven scal-
ing practices were: Scrum of Scrums (SP1), Communities of Practice
(SP2), Requirements Management Scaling (SP4), Scaled Sprint Plan-
ning (SP5), Scaled Retrospective (SP6), Undone Department (SP8) and
Scaled Sprint Demo/Review (SP3, at Kentico called Iteration Review).
These were the most important practices to allow the adoption of a
scaled agile process. Feature Teams (SP7) were not among the practices
adopted at Kentico.
•Scaled Retrospective: the format of the Scaled Retrospective
was the result of several iterations. The company first tried to
generate topics during team retrospectives, but there was not
enough time and context for identification of major cross-team
impediments. Another experiment was to let Agile Coaches cre-
ate the topics, but this included only their point of view. The
3Domain Specific Language to describe the software behaviour with-
out entering the details of implementation, https://github.com/cucumber/
cucumber/wiki/Gherkin
addition of the voting system, together with the topics generated
by anyone further improved the Scaled Retrospective, as only
people interested in the discussed topic attended.
•Scaled Planning: revolved around so-called Milestones. A Mile-
stone defined vision, goals, business and technical initiatives the
company wanted to achieve in the next release. An iteration of a
milestone was 16 weeks long with four phases (Discovery, Strat-
egy, Sub-Strategy & Go-to-Market, Development). The Discov-
ery phase identified the most valuable directions of the product,
taking into account emerging technologies, market and compet-
itive analysis. The Strategy phase generated and also validated
solutions based on the Discovery phase. The Sub-Strategy sub-
phase was to create an initial roadmap for the new release, iden-
tify any obstacles, dependencies and risks associated with the
roadmap and define steps to mitigate them. The Go-to-Market
used the roadmap from the first sub-phase, setting-up a docu-
ment summarizing what the new release is selling, to whom and
how. The Development phase dealt with the implementation of
the previously specified goals in two weeks Sprint iterations.
•Scaled Sprint Demo / Review (called Iteration Review): took
place bi-weekly at the end of every development iteration. The
primary goal was to spread knowledge across development
teams—the meeting was mandatory for everyone in Kentico
Cloud. Another goal of the meeting was to collect early feedback
and incorporate it early. The meeting also evaluated if every-
thing was delivered or something was missing. Furthermore, the
subsequent steps and future of the product were discussed.
•Scrum of Scrums: A first meeting was a synchronization meeting
for Scrum Masters, Development Director and other specialists,
such as Quality Assurance Coordinator. A second meeting was
called Kentico Cloud Sync, and it was a synchronization meeting
for the whole Cloud platform. It was attended by Agile coaches,
Development Director,and development teams. The current for-
mat was the result of multiple iterations of improvements, for
example knowledge sharing was separated to a different meet-
ing which took place before SoS meetings.
•Requirements Management Scaling: Management of cross-
team requirements did not follow any particular process. Teams
were communicating and synchronizing on items, which had
to be implemented by multiple teams, using ad-hoc meetings
and visiting other teams on a daily basis. The teams could also
have some team meetings, such as groomings, together with the
other teams. Furthermore, team members could be exchanged
between teams, and a cross-team review process was estab-
lished. The same ad-hoc process was used by Product Managers.
All features were initially prioritized in one backlog. After the ini-
tial prioritization, each feature was handled in the backlog of the
team which was responsible of implementation. If more teams
16 MARTIN KALENDA ET AL
were cooperating on a single feature, they used the backlog of
the team which owned the feature.
•Undone Department: The company used many different spe-
cialized teams that helped the development teams with their
work. There were an Architecture Team, a DevOps team, a Secu-
rity Team, a team of Technical Writers and one User Experience
team. Each team had one team member who was also a member
of one of these expert teams.
•Communities of Practice: The company used a similar con-
cept called Guilds. Topics of these Guilds were, for example,
performance improvements, graphical design, coaching, contin-
uous integration and automatic testing. The number of people
involved in these Guilds ranged from five to ten. Guilds met at
average every two weeks.
5.4.3 Challenges
During the transformation process, we identified four challenges which
the case company faced. They were resistance to change (SC1), Quality
Assurance issues (SC3), integrating with non-agile parts of the organiza-
tion (SC4), too fast roll-out (SC not identified before).
•Resistance to change: Although many people in the company
were already very experienced with agile development, there
were still some that did not like the new way of working. The
problem with resistance was also caused by the fact that the
development teams—which were given absolute freedom and
chose their path—were forced to change. The teams did not want
to abandon their previously created process and selected tools.
•Too fast roll-out: There were different situations where prob-
lems emerged due to the rushed adoption of a new process.
Utilizing piloting or smaller gradual changes with one or two
teams could have saved a lot of company’s resources.
•Quality Assurance issues: At the beginning of company’s new
Cloud platform, the development teams were given absolute
freedom. The teams were developing separate products, which
were still at the phase of validation. The company let the teams
create their entire development process, select their tools and
technologies because there was no need to unify the processes,
as the development teams almost did not interact among them-
selves. Although this created a great atmosphere in teams and
improved their motivation, the company soon realized that the
development teams did not manage their processes properly.
Technical debt piled up and development infrastructure was not
set-up properly.
•Integrating the previous and non-agile parts of organization:
Many parts of the organization were still adopting a non-agile
development process, as the new agile development process was
created next to the old development model of a previous prod-
uct. People were moved from the old development process to
the new one as necessary. However, the former product still
needed maintenance. Some resources, such as Technical Writers,
needed to be shared between the two processes. At the end of
our research, the company tried to resolve this by including the
shared resources into each team. For example, each team would
have one Technical Writer.
5.4.4 Success Factors
Overall, we identified four main success factors which helped the com-
pany with the adoption of agile development. They were: unification of
views and values (SF2), executive sponsorship / management support
(SF7), and company culture (new) and prior agile and lean experience
(new).
•Company culture and prior agile and lean experience: Many
people in the company had prior experience in agile and lean
development, especially Agile Coaches and management. There-
fore, the company did not suffer from lack of knowledge or
experience as many other companies. The knowledge was spread
by Agile Coaches which used lean practices. They coached peo-
ple by listening and asking questions, not forcing them to change.
Many individuals in the company were interested in agile and
lean in general. They were involved in the agile community and
followed latest trends in agile development. The company used
exchange programs of Agile Coaches with other organizations
and was also collaborating with universities. Furthermore, some
employees presented the company results on university lec-
tures. The culture of the company helped as well. People did not
feel observed due to transparency as the environment was very
open-minded and relaxed.
•Executive Sponsorship / Management support: the manage-
ment initiated the change: this helped consistently with the
adoption. All required resources were available. Also, managers
did not try to suffocate employees but helped them grow. The
management was also actively involved with the teams during
the test phase of new processes. Some members of management,
such as CEO and CTO, were members of the development team
that tried out the new process. This engagement of executives
improved motivation of other team members, as they saw the
interest from the management. It also helped the management,
because they better understood the practices and the processes.
•Unification of view and values: The company defined shared val-
ues: it was achieved by introducing an "Agile and Lean Manifesto".
The Manifesto contained twelve statements about the core val-
ues and principles the company wanted to follow. Additionally,
it contained several rules that guided the way of working in
the company. These rules defined the priorities in the organiza-
tion, for example, i) cross-team cooperation and consistency before
autonomy and ii) specialization with substitutability before team
responsibility distribution. The Manifesto helped the company to
enforce the adoption of the values.
MARTIN KALENDA ET AL 17
5.4.5 Suggestions from the Action Research
During the action research process, several suggestions for the scal-
ing process were put forward, but could not be evaluated given the
time-frame of the research. They are suggestions that were given the
company but will be part of future release cycles, if considered relevant.
The first suggestion is to promote better engineering practices
and debt management. We saw that technical debt and bad engineer-
ing practices caused a lot of challenges in large-scale agile.73,75, 76, 79, 80
Therefore, having solid engineering practices and debt management are
some of the prerequisites for successful large-scale agile development.
A robust development infrastructure with proper continuous integra-
tion and automated tests allows teams to focus more on the new way
of working. Teams will also have more time to think about improve-
ments to their development process. If technical debt and bad quality
code will pressure the development teams too much, they will not be
able to focus on other responsibilities that agile development brings.
Teams might also experience overall discouragement: they might start
to skip bugs fixing or report a false status of their work. Long and Starr75
improved their debt management by introducing visual indications of
the state of their products, to decide if the product was ready for a new
feature or defects had to be solved first. A similar solution is described
in detail in dos Santos et al.96 The paper also adds further motivation
of teams for their technical debt management by introducing elements
of gamification.96 Additionally, Long and Starr,75 Schnitter and Mack-
ert,76 Paasivaara et al80 suggested additional training, use of cross-team
backlog and DevOps teams. However, this problem may not be easily
resolved: it may take years.73
A second suggestion is to be careful about too much specialization
without knowledge sharing. Communication plays a key role within and
across agile development teams.97 The case company was using spe-
cialization in the development teams. It also provided good arguments
about the reasons. However, we saw that too much specialization in
teams might considerably damage teamwork73 and create a highly com-
petitive environment.76 It reduced the overall productivity of teams and
caused several other issues. Teams did not have clear, unified view of
the development and team plan, as specialized team members focused
more on their particular area. The team members only did their par-
ticular job. They did not understand the work of other team members
and hence distributed decision making was not possible. Moreover,indi-
vidual team members became unsubstitutable. Therefore, they did not
want to share their knowledge and know-how with their colleagues.73
We suggested considering establishing a process for knowledge sharing
between team members early, for example using workshops or estab-
lishing CoPs. In later stages, there is the risk that team members might
consider their knowledge too important to share it.
The third suggestion is to use Feature Teams and divide the product
into customer-centered development areas. Both LeSS and SaFE pro-
mote Feature Teams.35,36, 27 One of the characteristics of Feature Teams
is that they are cross-component. The reason for establishing cross-
component teams is that they allow much easier scaling of agile devel-
opment, as Feature Teams minimize dependencies between teams. They
also enable a much more flexible structure of the organization, because
the teams can work on any component and they are not constrained by
technical knowledge. Hence, teams can be easily moved between differ-
ent development areas. As there are no technical constraints, the teams
can be divided into development areas, which are centered around the
customer: this allows teams to see the whole features from a customer
point of view and not only part of the features under implementation
in their components. Implementing Feature Teams is not easy.79,80 LeSS
suggested way to transition to Feature Teams is to establish one Fea-
ture Team from individuals with knowledge about each component.27
Team members of such Feature Teams share their knowledge and work
together on a feature that spans between multiple components.27 The
organization should not add more feature teams until the first is per-
forming well.27 However, there is a risk involved in this strategy, as a
similar one was reported in Paasivaara et al,80 and it caused problems
as team members of the first Feature Team had central roles in their
previous teams.
The fourth suggestion is to support and promote Communities of
Practice: CoPs are used in both SAFe and LeSS.35,36, 27 They are an
instrument that allows voluntary cooperation in an arbitrary area. The
most common use of CoPs is knowledge sharing. Thus, they can be uti-
lized to enable better transition to Feature Teams, to promote better
engineering practices or to avoid too much specialization in teams. CoPs
are self-organized and are not part of a process or organization entity.
However, to establish working CoPs, an organization must actively sup-
port and promote them by allocating resources: this means that an
organization should provide facilitators, the IT infrastructure and bud-
get. CoPs also need a capable leader, that coordinates and motivates
the community. Therefore, organizations should try to find, motivate
and support CoP leaders. There are many ways to use CoPs. Paasivaara
and Lassenius84 studied the use of CoPs with the goals of coaching,
improving software craftsmanship, researching emerging technologies,
uplifting work and improving coordination and design across teams.84
Afinal suggestion is to better deploy indicators and metrics to mea-
sure progress of the development process: research of existing adop-
tions of agile showed that the adoption is a continuous process with a
long-term goal.9This transformation takes effort, resources and time.
Therefore, there is a need for better understanding and evaluation. This
can be achieved by quantitatively measuring the change. The transfor-
mation also needs to be gradually tailored to the particular context of
the organization. Therefore, metrics can be used as a valid argument
for this process adjustment. Many organizations struggled to find mean-
ingful metrics to measure their agile transformation.77,80, 83 The reason
is that in a traditional waterfall development process, there are clear
inputs and outputs of process resources streams. On the other hand,
agile development has much more an ad-hoc nature: streams of process
resources might change daily. Therefore, it is very challenging to find
relevant metrics. However, there are metrics that can be used to mea-
sure the agile transformation process in different areas, such as change
18 MARTIN KALENDA ET AL
in responsiveness, change in throughput, change in workflow distribu-
tion and change in quality.98 Having such metrics and indicators in place
can be useful to track the agile scaling process.
5.5 Threats to Validity
The action research methodology was deemed appropriate for the goals
of the current research, as authors wanted to assist the company with
the scaling the agile processes and at the same time researching on
the way the adoption was performed.99,38 It also gave the opportunity
of benefits beyond other research methodologies, as it has been often
reported: "in action research, the emphasis is more on what practitioners do
than on what they say they do".47
The action research methodology sometimes faces philosophical
issues about its scientific correctness as the method is empirical,
experimental, observational, and yet it is interpretative, multivariate,
and interventionist.46 It is a research methodology that requires vast
amount of time as there needs to be enough time to impact on the pro-
cesses and to observe the results. This paper involved eight months of
direct contact with the company, with some parts of the transforma-
tion process still ongoing. Years might be required to observe the full
effects of some changes. Although the application of action research
in empirical Software Engineering is limited,100 we believe that such
research method can provide more benefits to industry than tradi-
tional case study research101,38 —being the final goal of Software Engi-
neering research to support practical software development with rele-
vant contributions.100 Action research can be fitting in this context, as
while qualitative research is research about practice, action research is
research with practitioners.93
We are aware that the conducted action research is limited due to the
possibility of researchers to impact in the development process. In our
case, one limitation is that we conducted most of the process through
a main contact point at the company. However, we created a research
protocol that would allow fast feedback loops from researchers to the
development teams in the application of the techniques. Such proto-
col was based on the application of dialogical action research.91 This
is in line with the fact that in action research, the level of participa-
tion of researchers can be be placed on a different spectrum. Learning
from the action process is what matters,93 with the ultimate goal of
bringing together "action and reflection, theory and practice".37 To reduce
these threats, we applied the framework from Lau102 to enhance action
research quality.In particular, we rigorously ensured feedback cycles for
the actions performed. However, being our approach nearer to action
science,94 we could not cover all aspects.
Another threat to validity is confirmation bias,103 in that we could
have interpreted evidence collected according to our expectations
derived from the main literature review. We believe that this threat is
limited in the current work, as we did not set a-priori hypotheses to fal-
sify,104 ratherreported findings from the field by different stakeholders.
Still, our approach might have lead towards getting answers adjusted
according to our previous beliefs.
About construct validity of the action research, the main threat
is about how much the organization considered complies with the
definition of "large-scale". We believe the organization is representative
of such concept, taking into account the two main definitions of large-
scale presented in the introduction.34,48 In our case, we considered four
main teams of 7+ members, plus additionally three other cross-cutting
teams (architecture team, user experience team and team of technical
writers). Considering all the other roles presented (security specialists,
quality coordinators, etc...) the amount sums up to more than seven
teams and more than 50 members involved.
We cannot generalize the results to other cases, as the case reported
one single instance and other replications would be necessary. The
challenge is on finding other large organizations in the process of scal-
ing their development processes. Nevertheless, given the complexity
of organizational contexts, we would expect slightly different results,
as the literature review in the first part of the paper has shown. Even
the most successful practices might fail in a different context, as the
importance of the context is well known in Software Engineering.105
As reported, we conducted two loops of the action research cycle in
our research. We were limited by the length of software development
process adjustments and by time constraints. Overall, the results can
be considered gathered over a period of eight months of continuous
collaboration with the company. Even though some transformation pro-
cesses were still ongoing, we consider the time devoted to the research
adequate to collect answers to the research questions.
6SUMMARY OF THE FINDINGS
Overall we identified many practices, challenges and success factors for
scaling agile in large organizations (Fig. 8 , in which we compare findings
from the literature and the action research part). We saw that a success-
ful scaling of agile in a large company does not need to follow a particular
scheme. Quite the contrary,the case company tailored the development
process to the needs while also keeping the core values and principles
of agile development. The transformation was mainly successful thanks
to the agile mindset and prior experience with agile development of the
individuals that were in charge of the the transformation process. Dif-
fusing a new mindset by utilizing coaching with lean principles allowed
to spread the new values to other team members. Previous experience
from other cases of scaling agile can serve as a useful reference to eval-
uate several alternatives—the outcomes seem, however, very specific to
the context. The factors we identified were generally found as positive
for the scalability of agile processes, but it is relatively easy to find cases
in which an enabling practice is not successful in other contexts. Never-
theless, we believe that the factors we derived from both the literature
review and the action research process, together with the experiences
we summarized, can be valuable to other organizations in need to scale
their software development processes.
We identified challenges and success factors of "large-scale" agile
adoption in an action research within a company. We found out that
MARTIN KALENDA ET AL 19
TABLE 4 Comparison of main scaling practices at Kentico (SP1,SP4,SP5,SP6) compare to literature
Scaling
Practices
Action Research (Kentico) Literature
Scrum of
Scrums
(SP1)
– Several tiers of SoS.
– Every topic is time boxed, when the time box expires the
whole audience agrees on proceeding further.
– Two SoS meetings per week were too many.
– Sharing knowledge about topics during meetings was ineffi-
cient: separation of knowledge sharing to different meetings.
– The meeting needs to be properly prepared (topics need to
be described, no new ad-hoc topics added during the meeting,
attendance has to understand the context of the topics).
– SoS takes too long when projects grow. Teams were told to
report only impediments, this can lead to decrease of collabo-
ration of teams as they might feel nothing is important enough
to be reported.74
– One solution can be to use representatives of teams when
meetings grow too large—important is to rotate people in
common meetings. One problem involving Scrum Masters is
that they are not directly involved with team work and do not
have sufficient contextual information.74
– Daily SoS reduced to weekly.79
– Separate feature specific SoS from general ones, and create a
hierarchy of SoS.79
– SoS can be used for synchronization.72
Scaled
Require-
ments
Man-
agement
(SP4)
– One backlog for the prioritization: after prioritization is over
the items are further handled in the team backlog.
– It may happen that more teams are cooperating over one
backlog if they are working together on particular features.
– No hierarchy is defined, PMs are cooperating (DoP is continu-
ously being informed)
– Great for synchronization
– Scaling might include creating a hierarchy of POs74 or scaling
PO role to a team PO.76
– The main challenge in creating hierarchical backlog manage-
ment is to divide the requirements in product areas. Cross-
area dependencies can cause huge communication overhead
and impossibility to have separate scaled meetings for the
product areas.74
– One idea is to introduce new levels to manage requirements
for larger products, e.g. Product Team, Area Product Team.76
– Clarifying responsibilities, setting up a Product Owner Team
can be important.80
Common
Planning
(SP5)
– Different perception of priorities across separate teams.
– Helps to focus on the top priority issues in need to be
addressed.
– Scaled Sprint Planning might be challenging in a distributed
project with multiple sites.72
– Planning might need more attention and might span across
several meetings in large-scale agile development. Addi-
tional meetings might be required to explain requirements to
teams.74
Common
Retro-
spective
(SP6)
– Helps to address the issues cross teams/departments.
– Improves the way of working across the teams.
– Inefficiencies in involving too many people.
– Many topics are hard to address during team retrospectives.
– Problems which can occur in one team will be heard by mem-
bers of other teams. All get the same context of the issues.
– Extrovert people can overrun introverts because of the large
group audience.
– There might be small "easy-to-fix" topics with high value but
the voting mechanism eliminates them.
– Problems which are identified are often too big and hard to
solve—might need several iterations to be resolved and the
teams might get demoralized when seeing that the problems
identified in previous retrospectives are still not resolved and
might stop going to the retrospectives. One proposed solu-
tion is to set one goal and keep the goal through several
iterations until it is resolved.74
20 MARTIN KALENDA ET AL
FIGURE 8 Overall Research Findings (RQ1, RQ2, RQ3, RQ4, RQ5, RQ6)
the case company experienced similar problems, challenges and success
factors to the ones we identified in literature. The biggest challenges
the company faced were resistance to change (SC1), quality assurance
issues (SC3), integrating the previous and non-agile parts of organiza-
tion (SC4), and too fast roll-out (new).
There were four main success factors which were the most benefi-
cial for the adoption in the case company: unification of view and values
(SF2), executive sponsorship / management support (SF7), company
culture (new) and prior Agile and Lean experience (new).
The main practices adopted were: Scrum of Scrums (SP1), Communi-
ties of Practice (SP2), Requirements Management Scaling (SP4), Scaled
Sprint Planning (SP5), Scaled Retrospective (SP6), Undone Department
(SP8) and Scaled Sprint Demo/Review (SP3, at Kentico called Iteration
Review). In Table 4 we provide in more detailed form the main findings
related to SP1, SP4, SP5 and SP6 and their comparison with findings
from previous literature.
6.1 Findings in Related Literature
There are two main studies that reviewed primary studies on large-scale
agile, namely Version One Report57 and Dikert et al.34 The Version One
report57 identified 14 barriers to further agile adoption and gave five
recommendations for success with scaling agile.
The five biggest barriers to agile adoption mentioned in Version One
report57 were: the ability to change the organizational culture (55%), gen-
eral organizational resistance to change (42%), preexisting rigid/waterfall
framework (40%), not enough personnel with the necessary agile experience
(39%) and management support (38%).
The ability to change the organizational structure and the barrier general
organizational resistance to change are both identified in our research as
the challenge resistance to change. The barrier preexisting rigid and water-
fall framework was not found in our research as a barrier. The barrier
not enough personnel with the necessary agile experience was considered
in our research as a challenge; it was included in our challenge Lack of
knowledge, coaching, and training. The last barrier management support,
which was considered by the Version One report57 as not enough man-
agement support, was not identified in our research. However, executive
sponsorship was one of the success factors in our study.
There are suggestions for a successful agile adoption that Version
One report57 discussed: consistent process and practices (43%), implemen-
tation of a common tool across teams (40%), agile consultants or trainers
(40%), executive sponsorship (37%) and internal agile support team (35%).
The suggestion consistent process and practices can be considered part
of our success factor careful transformation, as we mentioned that pro-
cesses should not be changed very often. Implementation of common tools
across teams can be regarded as our success factor tools and infrastruc-
ture. In our research, we identified knowledge acquisition as the most
important success factor: we mentioned that using agile consultants and
trainers was one of the most suggested way to acquire knowledge. Thus,
both suggestions agile consultants or trainers and internal agile support
team can be regarded as this success factor. Executive sponsorship was
exactly one of our identified success factors.
The other review by Dikert et al34 examined 52 publications. The
paper was published in 2016 and considered only studies after the year
2000. Therefore the findings are relatively recent. The research found
that the most used agile method was Scrum, XP and Lean software
development.34
The research by Dikert et al34 pinpointed 29 success factors in total.
The success stories were divided into nine categories. The most fre-
quently identified categories were: choosing and customizing the agile
approach (48%), mindset and alignment (40%), management support (38%),
training and coaching (36%) and piloting (36%).
The first success factor choosing and customizing the agile approach
was not identified by our research. All studied cases we examined cus-
tomized their development process, but, as we saw, manyof them failed.
The success factor mindset and alignment could be considered as part
of our success factors acquire knowledge and common view on values and
practices. Success factors management support and training and coaching
MARTIN KALENDA ET AL 21
were both identified in our research—we called them executive sponsor-
ship and acquire knowledge respectively. The last success factor piloting
can be considered as our success factor careful transformation.
In total, the research by Dikert et al34 identified 35 challenges, which
the authors divided into nine categories. The biggest challenges of large-
scale agile transformation were: agile difficult to implement (48%), inte-
grating non-development functions (43%), change resistance (38%), require-
ments engineering challenges (38%), hierarchical management and organiza-
tional boundaries (33%).
The first challenge agile difficult to implement was not identified in
our research. However, the challenge can be caused by lack of knowl-
edge, coaching, and training, which was considered as a challenge in our
study. The challenge integrating non-development functions can be con-
sidered as our challenge integration with non-agile part of the organization
as many of the non-development parts of the company did not use any
agile method. The challenges change resistance, and requirements engi-
neering challenges were both identified in our research—we called them
resistance to change and requirements management hierarchy, respectively.
Neither of these studies identified measuring progress as a challenge.
Also, use of common tools was considered as a success factor only by
the Version One study.57 Moreover, none of these studies investigated
individual scaling practices.
7 CONCLUSION
The goal of this paper was to collect more evidence about impact fac-
tors for scaling agile software development processes inside companies,
to better understand practices that work best in a given context.34,1 By
means of a review of studies about large-scale agile in organizations,
we identified practices, challenges and success factors. The initial lit-
erature review was the input to conduct an action research study in a
software company that was in the process of scaling the agile software
development processes. We studied the concrete scaling practices the
company utilized, which success factors the company experienced and
which challenges the company faced. Thus, we contributed to the exist-
ing set of studies about scaling agile with the experience derived from
the action research.
Agile culture within the company and prior agile and lean experience,
management support, unification of views and values were found to be
key success factors during the action research process. Resistance to
change, too quick roll-out, quality assurance issues and the integration
with previous non-agile parts of the organization were found to be crit-
ical challenges in the scaling process. Overall, a positive outcome from
the action research process was to cross-fertilize ideas from literature
to the practical context of the company.
We mentioned several challenges which are connected to large-scale
agile. These challenges need more detailed investigation in coopera-
tion with large companies in order to find appropriate solutions. More
studies are necessary to find causal relationships between factors.
References
1. Eklund Ulrik, Berger Christian. Scaling agile development in
mechatronic organizations: a comparative case study in Proceed-
ings of the 39th International Conference on Software Engineering:
Software Engineering in Practice Track:173–182IEEE Press 2017.
2. Fitzgerald Brian, Stol Klaas-Jan, O’Sullivan Ryan, O’Brien Donal.
Scaling agile methods to regulated environments: An industry
case study in Software Engineering (ICSE), 2013 35th International
Conference on:863–872IEEE 2013.
3. Boehm B., Turner R.. Management challenges to implementing
agile processes in traditional development organizations IEEE
Software. 2005;22:30-39.
4. Rolland Knut H. Scaling Across Knowledge Boundaries: A Case
Study Of A Large-Scale Agile Software Development Project in
Proceedings of the Scientific WorkshopProceedings of XP2016:5ACM
2016.
5. Carlile Paul R. A pragmatic view of knowledge and boundaries:
Boundary objects in new product development Organization sci-
ence. 2002;13:442–455.
6. Carlile Paul R. Transferring, translating,and transforming: An inte-
grative framework for managing knowledge across boundaries
Organization science. 2004;15:555–568.
7. Dyba T., Dingsoyr T.. What Do We Know about Agile Software
Development? IEEE Software. 2009;26:6-9.
8. Ambler Scott W. Scaling agile software development through lean
governance in Software Development Governance, 2009. SDG’09.
ICSE Workshop on:1–2IEEE 2009.
9. Ebert C., Paasivaara M.. Scaling Agile IEEE Software. 2017;34:98-
103.
10. Paasivaara Maria. Adopting SAFe to scale agile in a globally dis-
tributed organization in Global Software Engineering (ICGSE), 2017
IEEE 12th International Conference on:36–40IEEE 2017.
11. Kasauli Rashidah, Liebel Grischa, Knauss Eric, Gopakumar Swathi,
Kanagwa Benjamin. Requirements engineering challenges in
large-scale agile system development in Requirements Engineering
Conference (RE), 2017 IEEE 25th International:352–361IEEE 2017.
12. Mishra Deepti, Mishra Alok. Complex software project develop-
ment: agile methods adoption Journal of Software Maintenance and
Evolution: Research and Practice. 2011;23:549–564.
13. Heikkila Ville, Rautiainen Kristian, Jansen Slinger. A revelatory
case study on scaling agile release planning in Software Engineering
and Advanced Applications (SEAA), 2010 36th EUROMICRO Confer-
ence on:289–296IEEE 2010.
22 MARTIN KALENDA ET AL
14. Power Ken. A model for understanding when scaling agile is
appropriate in large organizations in International Conference on
Agile Software Development:83–92Springer 2014.
15. Saddington Peter. Scaling Agile Product Ownership through Team
Alignment and Optimization: A Story of Epic Proportions in Agile
Conference (AGILE), 2012:123–130IEEE 2012.
16. Moore E., Spens J.. Scaling Agile: Finding your Agile Tribe in Agile
2008 Conference:121-124 2008.
17. Conboy K., Coyle S., Wang X., Pikkarainen M.. People over
Process: Key Challenges in Agile Development IEEE Software.
2011;28:48-57.
18. Dingsøyr Torgeir, Moe Nils Brede, Fægri Tor Erlend, Seim
Eva Amdahl. Exploring software development at the very large-
scale: a revelatory case study and research agenda for agile
method adaptation Empirical Software Engineering. 2017:1–31.
19. Paasivaara Maria, Lassenius Casper. Challenges and success fac-
tors for large-scale agile transformations: A research proposal and
a pilot study in Proceedings of the Scientific Workshop Proceedings of
XP2016:9ACM 2016.
20. Chow Tsun, Cao Dac-Buu. A survey study of critical success fac-
tors in agile software projects Journal of systems and software.
2008;81:961–971.
21. Rossi Bruno, Russo Barbara, Succi Giancarlo. Open source soft-
ware and open data standards as a form of technology adop-
tion: a case study in IFIP International Conference on Open Source
Systems:325–330Springer 2007.
22. Rossi Bruno, Russo Barbara, Succi Giancarlo. Adoption of free/li-
bre open source software in public organizations: factors of
impact Information Technology & People. 2012;25:156–187.
23. Rossi Bruno, Russo Barbara, Succi Giancarlo. Evaluation of a
migration to Open Source Software Handbook of Research on Open
Source Software: Technological, Economic, and. 2007:309.
24. Fitzgerald Brian. Open source software adoption: anatomy of
success and failure Multi-Disciplinary Advancement in Open Source
Software and Processes. 2011:1–23.
25. Fitzgerald Brian, Kesan Jay P, Russo Barbara, Shaikh Maha, Succi
Giancarlo. Adopting open source software: A practical guide. The MIT
Press 2011.
26. Wang Xiaofeng, Conboy Kieran, Pikkarainen Minna. Assimi-
lation of agile practices in use Information Systems Journal.
2012;22:435–455.
27. Larman Craig, Vodde Bas. Practices for scaling lean & Agile develop-
ment: large, multisite, and offshore product development with large-
scale scrum. Pearson Education 2010.
28. Larman Craig, Vodde Bas. Scaling agile development CrossTalk.
2013;9:8–12.
29. Reifer Donald J, Maurer Frank, Erdogmus Hakan. Scaling agile
methods IEEE software. 2003;20:12–14.
30. Freudenberg Sallyann, Sharp Helen. The top 10 burning research
questions from practitioners Ieee Software. 2010;27:8–9.
31. Paasivaara Maria, Lassenius Casper. Scaling scrum in a large dis-
tributed project in Empirical Software Engineering and Measurement
(ESEM), 2011 International Symposium on:363–367IEEE 2011.
32. Kasauli Rashidah, Knauss Eric, Nilsson Agneta, Klug Sara. Adding
Value Every Sprint: A Case Study on Large-Scale Continuous
Requirements Engineering. in REFSQ Workshops 2017.
33. Hobbs Brian, Petit Yvan. Agile methods on large projects in large
organizations Project Management Journal. 2017;48:3–19.
34. Dikert Kim, Paasivaara Maria, Lassenius Casper. Challenges and
success factors for large-scale agile transformations: A systematic
literature review Journal of Systems and Software. 2016;119:87 -
108.
35. Scaled Agile Inc.. SAFe 4.0 Introduction A Scaled Agile, Inc. White
Paper July 2016 Overview of the Scaled Agile Framework for
Lean Software and Systems Engineering tech. rep.Scaled Agile,
Inc.5480 Valmont Rd, Suite 100, Boulder CO 80301 USA 2016.
36. Leffingwell Dean. SAFe R
4.0 Reference Guide: Scaled Agile
Framework R
for Lean Software and Systems Engineering.
Addison-Wesley Professional 2016.
37. Brydon-Miller Mary, Greenwood Davydd, Maguire Patricia. Why
action research? 2003.
38. Easterbrook Steve, Singer Janice, Storey Margaret-Anne, Damian
Daniela. Selecting empirical methods for software engineer-
ing research Guide to advanced empirical software engineering.
2008:285–311.
39. Schön Eva-Maria, Thomaschewski Jörg, Escalona Maria Jose.
Agile Requirements Engineering: A systematic literature review
Computer Standards & Interfaces. 2017;49:79–91.
40. Torrecilla-Salinas CJ, Sedeño Jorge, Escalona MJ, Mejías Manuel.
Agile, Web Engineering and Capability Maturity Model Integra-
tion: A systematic literature review. Information and SoftwareTech-
nology. 2016;71:92–107.
41. Budgen David, Turner Mark, Brereton Pearl, Kitchenham Barbara.
Using mapping studies in software engineering in Proceedings of
PPIG:195–204Lancaster University 2008.
MARTIN KALENDA ET AL 23
42. Petersen Kai, Feldt Robert, Mujtaba Shahid, Mattsson Michael.
Systematic Mapping Studies in Software Engineering in Proceed-
ings of the 12th International Conference on Evaluation and Assess-
ment in Software EngineeringEASE’08(Swindon, UK):68–77BCS
Learning & Development Ltd. 2008.
43. Pergher Massimiliano, Rossi Bruno. Requirements prioritization
in software engineering: a systematic mapping study in Empirical
Requirements Engineering (EmpiRE), 2013 IEEE Third International
Workshop on:40–44IEEE 2013.
44. Sjoberg Dag IK, Dyba Tore, Jorgensen Magne. The future of empir-
ical methods in software engineering research in 2007 Future of
Software Engineering:358–378IEEE Computer Society 2007.
45. Coughlan Paul, Coghlan David. Action research for operations
management International journal of operations & production man-
agement. 2002;22:220–240.
46. Baskerville Richard L., Wood-Harper A. Trevor. A Critical Per-
spective on Action Research as a Method for Information Systems
Research:169–190. Cham: Springer International Publishing
2016.
47. Avison David E, Lau Francis, Myers Michael D, Nielsen Peter Axel.
Action research Communications of the ACM. 1999;42:94–97.
48. Dingsøyr Torgeir, Fægri Tor Erlend, Itkonen Juha. What Is
Large in Large-Scale? A Taxonomy of Scale for Agile Software
Development:273–276. Cham: Springer International Publishing
2014.
49. Dingsøyr Torgeir, Moe Nils Brede. Towards principles of large-
scale agile development in International Conference on Agile Soft-
ware Development:1–8Springer 2014.
50. Moe Nils Brede, Dingsøyr Torgeir. Emerging research themes and
updated research agenda for large-scale agile development: a
summary of the 5th international workshop at XP2017 in Proceed-
ings of the XP2017 Scientific Workshops:14ACM 2017.
51. Alqudah Mashal, Razali Rozilawati. A review of scaling agile
methods in large software development International Journal
on Advanced Science, Engineering and Information Technology.
2016;6:828–837.
52. Sutherland Jeff. Agile Can Scale: Inventing and Reinventing
SCRUM in Five Companies 2001;Vol. 14, No. 12.
53. Ambler Scott W, Lines Mark. Disciplined agile delivery: A practi-
tioner’s guide to agile software delivery in the enterprise. IBM Press
2012.
54. Schwaber Ken. Nexus Guide. The Definitive Guide to Nexus: The
exoskeleton of scaled Scrum development PDF). scrum. org. 2015.
55. Thompson Kevin. Recipes for agile governance in the enterprise
2013.
56. One V. 11th annual state of agile survey tech. rep.Technical report,
Version One 2017.
57. One V. 10th annual state of agile survey tech. rep.Technical report,
Version One 2016.
58. Alliance Agile. Scrum of Scrums Online at http://www. agilemani-
festo. org. 2001;6.
59. Frank Andre, Hartel Charles. Feature teams collaboratively build-
ing products from ready to done in Agile Conference, 2009.
AGILE’09.:320–325IEEE 2009.
60. Ambler Scott W, Lines M. Going Beyond Scrum: Disciplined Agile
Delivery Disciplined Agile Consortium. White Paper Series. 2013:1–
16.
61. Bittner Kurt, Kong Patricia, Naiburg Eric, West Dave. The Nexus
Framework for Scaling Scrum: Continuously Delivering an Integrated
Product with Multiple Scrum Teams. Addison-Wesley Professional
2017.
62. Wenger Etienne. Communities of practice: Learning, meaning, and
identity. Cambridge university press 1998.
63. Kahkonen Tuomo. Agile methods for large organizations-building
communities of practice in Agile Development Conference, 2004:2–
10IEEE 2004.
64. Borzillo Stefano, Schmitt Achim, Antino Mirko. Communities of
practice: keeping the company agile Journal of Business Strategy.
2012;33:22–30.
65. Kitchenham Barbara A, Dyba Tore, Jorgensen Magne. Evidence-
based software engineering in Proceedings of the 26th international
conference on software engineering:273–281IEEE Computer Soci-
ety 2004.
66. Dyba Tore, Kitchenham Barbara A, Jorgensen Magne. Evidence-
based software engineering for practitioners IEEE software.
2005;22:58–65.
67. Kitchenham Barbara, Brereton O Pearl, Budgen David, Turner
Mark, Bailey John, Linkman Stephen. Systematic literature
reviews in software engineering–a systematic literature review
Information and software technology. 2009;51:7–15.
68. Arksey Hilary, O’Malley Lisa. Scoping studies: towards a method-
ological framework International journal of social research method-
ology. 2005;8:19–32.
69. Budgen David, Brereton Pearl. Performing systematic literature
reviews in software engineering in Proceedings of the 28th interna-
tional conference on Software engineering:1051–1052ACM 2006.
24 MARTIN KALENDA ET AL
70. Benzies Karen M, Premji Shahirose, Hayden K Alix, Serrett
Karen. State-of-the-evidence reviews: advantages and challenges
of including grey literature Worldviews on Evidence-Based Nursing.
2006;3:55–61.
71. Hayes Will. Research synthesis in software engineering: a case for
meta-analysis in Software Metrics Symposium, 1999. Proceedings.
Sixth International:143–151IEEE 1999.
72. Vallon Raoul, Strobl Stefan, Bernhart Mario, Grechenig Thomas.
Inter-organizational co-development with scrum: experiences
and lessons learned from a distributed corporate develop-
ment environment in International Conference on Agile Software
Development:150–164Springer 2013.
73. Moe Nils Brede. Key Challenges of Improving Agile Teamwork:76–90.
Berlin, Heidelberg: Springer Berlin Heidelberg 2013.
74. Paasivaara M., Lassenius C.. Scaling Scrum in a Large Globally
Distributed Organization: A Case Study in 2016 IEEE 11th Inter-
national Conference on Global Software Engineering (ICGSE):74-83
2016.
75. Long Ken, Starr David. Agile Supports Improved Culture and Qual-
ity for Healthwise in Proceedings of the Agile 2008AGILE ’08(Wash-
ington, DC, USA):160–165IEEE Computer Society 2008.
76. Schnitter Joachim, Mackert Olaf. Large-Scale Agile Software Devel-
opment at SAP AG:209–220. Berlin, Heidelberg: Springer Berlin
Heidelberg 2011.
77. Atlas A.. Accidental Adoption: The Story of Scrum at Amazon.com
in 2009 Agile Conference:135-140 2009.
78. Hanly S., Wai L., Meadows L., Leaton R.. Agile coaching in British
Telecom: making strawberry jam in AGILE 2006 (AGILE’06):9 pp.-
202 2006.
79. Paasivaara M., Lassenius C., Heikkila V. T., Dikert K., Engblom C..
Integrating Global Sites into the Lean and Agile Transformation
at Ericsson in 2013 IEEE 8th International Conference on Global
Software Engineering:134-143 2013.
80. Paasivaara M., Behm B., Lassenius C., Hallikainen M.. Towards
Rapid Releases in Large-Scale XaaS Development at Ericsson: A
Case Study in 2014 IEEE 9th International Conference on Global
Software Engineering:16-25 2014.
81. Schatz B., AbdelshafiI.. Primavera gets agile: a successful transi-
tion to agile development IEEE Software. 2005;22:36-42.
82. Hajjdiab Hassan, Taleb Al Shaima, Ali Jauhar. An industrial case
study for scrum adoption Journal of Software(Oulu). 2012;7.
83. Benefield Gabrielle. Rolling Out Agile in a Large Enterprise 2008
41st Annual Hawaii International Conference on System Sciences.
2008;00:462.
84. Paasivaara Maria, Lassenius Casper. Communities of practice in
a large distributed agile software development organization –
Case Ericsson Information and Software Technology. 2014;56:1556
- 1577. Special issue: Human Factors in Software Development.
85. Mohammadi Ehsan, Thelwall Mike, Haustein Stefanie, Larivière
Vincent. Who reads research articles? An altmetrics analysis of
Mendeley user categories Journal of the Association for Information
Science and Technology. 2015;66:1832–1846.
86. Mishra Alok, Garbajosa Juan, Wang Xiaofeng, Bosch Jan, Abra-
hamsson Pekka. Future Directions in Agile Research: Alignments
and Divergence between Research and Practice Journal of Soft-
ware: Evolution and Process. 2017;29.
87. Runeson Per. It Takes Two to Tango–An Experience Report on
Industry–Academia Collaboration in Software Testing, Verification
and Validation (ICST), 2012 IEEE Fifth International Conference
on:872–877IEEE 2012.
88. Wohlin Claes. Empirical software engineering research with
industry: Top 10 challenges in Proceedings of the 1st International
Workshop on Conducting Empirical Studies in Industry:43–46IEEE
Press 2013.
89. Garousi Vahid, Petersen Kai, Ozkan Baris. Challenges and best
practices in industry-academia collaborations in software engi-
neering: A systematic literature review Information and Software
Technology. 2016;79:106–127.
90. Martínez-Fernández Silverio, Marques Helena Martins. Practi-
cal experiences in designing and conducting empirical studies in
industry-academia collaboration in Proceedings of the 2nd Inter-
national Workshop on Conducting Empirical Studies in Industry:15–
20ACM 2014.
91. Mårtensson Pär, Lee Allen S. Dialogical action research at omega
corporation MIS Quarterly. 2004:507–536.
92. Baskerville Richard, Wood-Harper A Trevor. Diversity in informa-
tion systems action research methods European Journal of informa-
tion systems. 1998;7:90–107.
93. Bradbury-Huang Hilary. What is good action research? Why the
resurgent interest? Action Research. 2010;8:93–109.
94. Argyris Chris, Schön Donald A. Participatory action research and
action science compared: A commentary American behavioral sci-
entist. 1989;32:612–623.
95. Sato Danilo Toshiaki, Corbucci Hugo, Bravo Mariana Vivian. Cod-
ing dojo: An environment for learning and sharing agile practices
in Agile, 2008. AGILE’08. Conference:459–464IEEE 2008.
96. Santos Paulo Sérgio Medeiros, Varella Amanda, Dantas
Cristine Ribeiro, Borges Daniel Beltrão. Visualizing and Managing
MARTIN KALENDA ET AL 25
Technical Debt in Agile Development: An Experience Report:121–134.
Berlin, Heidelberg: Springer Berlin Heidelberg 2013.
97. Pikkarainen M., Haikara J., Salo O., Abrahamsson P., Still J.. The
impact of agile practices on communication in software develop-
ment Empirical Software Engineering. 2008;13:303–337.
98. Olszewska Marta, Heidenberg Jeanette, Weijola Max, Mikkonen
Kirsi, Porres Ivan. Quantitatively Measuring a Large-scale Agile
Transformation J. Syst. Softw.. 2016;117:258–273.
99. Davison Robert, Martinsons Maris G, Kock Ned. Princi-
ples of canonical action research Information systems journal.
2004;14:65–86.
100. Santos Paulo Sergio Medeiros, TravassosGuilherme Horta. Action
research use in software engineering: An initial survey in Empir-
ical Software Engineering and Measurement, 2009. ESEM 2009. 3rd
International Symposium on:414–417IEEE 2009.
101. Dos Santos Paulo Sergio Medeiros, Travassos Guilherme Horta.
Action research can swing the balance in experimental software
engineering in Advances in computers:205–276Elsevier 2011.
102. Lau Francis. Toward a framework for action research in
information systems studies Information Technology & People.
1999;12:148–176.
103. Nickerson Raymond S. Confirmation bias: A ubiquitous
phenomenon in many guises. Review of general psychology.
1998;2:175.
104. Mynatt Clifford R, Doherty Michael E, Tweney Ryan D. Confirma-
tion bias in a simulated research environment: An experimental
study of scientific inference The quarterly journal of experimental
psychology. 1977;29:85–95.
105. Dybå Tore, Sjøberg Dag IK, Cruzes Daniela S. What works for
whom, where, when, and why? On the role of context in empirical
software engineering in Empirical Software Engineering and Mea-
surement (ESEM), 2012 ACM-IEEE International Symposium on:19–
28IEEE 2012.
How cite this article: Kalenda M., Hyna P., Rossi B. (2018), Scaling Agile
in Large Organizations: Practices, Challenges, and Success Factors, J.
Softw. Evol. Proc.,2018;e1954. https://doi.org/10.1002/smr.1954
