corporate culture (Gruver & Mouser,
2015; Iivari & Iivari, 2011).
Scaling Agility (or not)
Although agile methodologies have
provided flexibility in the software
development process, most benefits
have been achieved with small projects composed of one or a few dedicated self-managed teams (Kruchten,
2013). For some organizations, the issue
might become whether or not to adopt
agile approaches, considering the size
and legacy of their systems and practices. Kruchten attempts to answer this
dilemma by proposing some scaling factors, which might distinguish the contexts in which agile might be easier to
introduce than others.
There has been very limited research
on the topic of large-scale software development projects using agile approaches
(Dyba & Dingsøyr, 2008; Razavi & Ahmad,
2014), although a number of specific cases
have been investigated, for example, in
the oil industry (Grewal & Maurer, 2007);
in large software and product development organizations (Gruver & Mouser,
2015; Lindvall et al., 2004 ; Mahanti, 2016);
in regulated environments (Fitzgerald,
Stol, O’Sullivan, & O’Brien, 2013); and at
BMC Software Infrastructure (Gat, 2006).
In these cases, the level of scaling varies significantly (in terms of project size,
number of teams, and number of sites).
To help categorize the varying levels of
scaling, Dingsøyr et al. (2014) suggest a
taxonomy of scale of agile software development projects based on the number
of teams, where small-scale corresponds
to one team, large-scale to two to nine
teams, and very large-scale to more than
ten teams. Based on this scale, the main
focus was on large-scale projects using
agile in this research.
Challenges Facing Large Organizations
Trying to Implement Agile Approaches
While agile methodology seems suited
for small collocated teams in which
the customer can be directly involved,
there are a number of impediments to
the scaling of these practices in large
multisite, multi-customer, and multi-
project organizations. At the 2004 Uni-
versity of Southern California Center for
Software Engineering (USC-CSE) Annual
Research Review, Boehm and Turner
(2005) identified some of the challenges
to implementing agile processes in tra-
ditional development organizations.
The result was a collection of change-
related challenges and a list of nearly
40 perceived barriers to agile implemen-
tation in large organizations. Many of
these challenges were related to scope
or scale, but some were related to the
clash between the agile and traditional
cultures; for example, development pro-
cess conflicts, variability in subsystems
developed that might not integrate eas-
ily, different life cycles, and difficulty in
using agile on legacy systems.
Leffingwell (2007) groups the challenges of scaling agile into two broad
categories: ( 1) those inherent to the
methods themselves, “because of the
fixed rule bases and assumptions built
into the methods” (p. 87); and ( 2) challenges imposed by the enterprise that
“will prevent the successful application
of the new methods” (p. 87). Included
in the first category are challenges such
as: number and size of teams, difficulty
in making the customer an integral part
of the team, collocation, emergence of
the architecture, lack of requirements
analysis, and documented specifications. The impediments related to the
enterprise would include: clashes with
the existing process and project management organizations, existing formalized policies and procedures, corporate
culture, fixed schedule/fixed functionality mandates, and people organized
by discipline rather than product line.
Mahanti (2006) found similar challenges adopting agile practices in large
organizations but identified the prime
challenge as the integration of agile
projects with the project environment's
existing processes.
Scaling Frameworks
The literature on scaling agile has been
dominated by consultants proposing a
number of frameworks (Agilealliance.
org) developed in recent years to
facilitate the use of agile principles in
larger projects. According to the sur-
vey performed by VersionOne (2016),
the most commonly used is Scaled
Agile Framework (SAFe®), which has
evolved from the Rationale Unified
Process (Leffingwell, 2015). Scott W.
Ambler (2009) initially proposed a scal-
ing model, called Agile Scaling Model
(ASM), which evolved into the frame-
work called Disciplined Agile Deliv-
ery (DAD) (Scott W. Ambler & Lines,
2014; DAD—Disciplined Agile Delivery,
2015). Under this model, projects can
be scaled based on factors such as team
size, geographical distribution, regula-
tory compliance, domain complexity,
organizational distribution, technical
complexity, organizational complexity,
and enterprise discipline. Other recent
frameworks include: Large-Scale Scrum
(LeSS) (Larman, 2015; Larman & Vodde,
2014), and Nexus (Schwaber, 2015). All
these frameworks attempt to preserve
the benefits of agile while improving the
links to larger organizations (Gruver &
Mouser, 2015). Because of their recent
introduction on the market, it is very
difficult to assess whether these frame-
works have indeed properly addressed
some of the issues related to scaling
agility and how organizations are actu-
ally implementing them.
Investigating the Use of Agile in Large
Projects and Large Organizations
Little has been reported in the literature
on the interplay between agile methods
and the accompanying organizational
arrangements (Kettunen, 2007). However, Kettunen (2009) suggests that further
improvements in software development
could be inspired by organization-oriented
business concepts, such as concurrent
engineering, multi-project management,
and being proactive.
At the XP 2010 conference in Trondheim, Norway, practitioners were polled
on what they felt should be the most
relevant research topic in their fields.
The topic of “agile and large projects”
