Making Sense of the Agile Methodology Wars

FOUNDATIONAL Refreshed: 14 June 2017 | Published: 19 February 2016 ID: G00278387

Analyst(s): Mike West, Maritess Sobejana

Becoming agile is now a top priority for many application development

organizations, but the process of becoming agile may not involve one single
methodology. This research will help CIOs and application leaders to choose
the method or methods that best suit their organization's needs.

FOUNDATIONAL DOCUMENT
This research is reviewed periodically for accuracy. Last reviewed on 14 June 2017.

Key Challenges
■ Agile is an approach toward software delivery, rather than a specific method or life cycle model.
■ Many organizations commit to agile without knowing the trade-offs between the various agile
methodologies and frameworks.
■ Over the past 15 years, agile processes have evolved, and new agile methods and frameworks
have emerged to address changing business needs, which makes selecting the right approach
even more difficult.
■ Scale and scope, specification, and schemas vary widely among the agile methods and
frameworks. One size does not fit all.

Recommendations
■ Use this research to select a "good enough" set of methods and practices to start with if there
is no "perfect fit" for your organization, and then make it yours.
■ Pick only methods with adequate training available in your area. Building knowledge and
expertise is an ongoing occupation in agile development.
■ Manage the process of culture change proactively.
■ Use regular retrospective reviews to adapt and improve the processes and practices in use.
 Table of Contents

Introduction............................................................................................................................................ 2
One Important Distinction................................................................................................................. 2
Analysis.................................................................................................................................................. 3
Select a "Good Enough" Agile Methodology to Start With, Then Make It Yours.................................3
Pick an Agile Methodology That Has Adequate Training in Your Area................................................ 6
Manage the Process of Cultural Change Proactively......................................................................... 6
Continuously Review, Adapt and Improve Your Agile Processes and Practices................................. 7
Case Study............................................................................................................................................ 7
Tollway Tech..................................................................................................................................... 8
Gartner Recommended Reading............................................................................................................ 8

List of Tables

Table 1. Methodology Decision Table......................................................................................................5

Introduction
This document was revised on 6 May 2016. The document you are viewing is the corrected version.
For more information, see the Corrections page on gartner.com.

The many flavors of agile (see Note 1) are fighting a war for the hearts and minds of CIOs and
application leaders. They are asking: "Should I do Scrum or Kanban? Or should I implement an
enterprise agile framework like SAFe?" Yet few CIOs or application leaders have the time to explore
these varied alternatives, or their strengths and differences in approach, when selecting a
methodology or process model (see Note 2) for developing today's business solutions.
Nevertheless, shifting to agile development has become a critical capability for digitalization and
competitive survival. This research can help CIOs and application leaders to choose an agile
methodology amid the noise and competing claims of the agile methodology wars.

One Important Distinction

Agile methodologies appropriate for small-scale, ongoing agile efforts are very different from those
designed for large-scale, enterprisewide development initiatives. Enterprise agile undertakings are
far more complex to coordinate, and also require a more-mature agile culture to attain — and
sustain — success.

It is important to begin with smaller-scale efforts (see "Getting Started With Transitioning to Agile"
and "Using a Pilot Project in Transitioning to Agile"). While agile methodologies used for smaller-
scale development initiatives are not sufficient in themselves for managing the multiple release
cadences of complex enterprise-level development, agile is a cultural transformation that impacts

Page 2 of 12 Gartner, Inc. | G00278387

 more than just the development teams. Developing agile capabilities is a learning experience for
teams, for end users, for infrastructure and operations partners, and for the organization as a whole.
Introducing agile methods into a mature IT organization is a significant cultural change for every
single function in IT, and for every business manager that engages with IT.

Executed well, the use of agile methods will have a major positive impact on the relationship
between business and IT units, and on the value of IT delivery. But, make no mistake about it,
becoming agile will be an upheaval for the entire organization.

Analysis
Agile methodologies are a set of approaches to software development that share a common
philosophy, but differ in their focus and in the details of execution. Sophisticated agile organizations
with a lot of experience may use more than one of these approaches, but any IT organization that is
getting started with agile should select just one approach and master that before attempting to use
others.

Select a "Good Enough" Agile Methodology to Start With, Then Make It Yours
A vast majority of agile teams use Scrum, especially at the beginning, and find it "good enough."
Most continue to use Scrum as their foundation as they mature. Scrum provides the team-level
process framework for applying agile practices, such as those originating under the Extreme
Programming (XP) banner. Even as IT organizations move to implement enterprise agile frameworks
(see Note 3), Scrum is most often the core team-level framework where the work gets done.

■ In the Gartner Research Circle survey titled "Agile in the Enterprise," IT leaders reported that
1
Scrum is used by 91% of organizations doing agile development.
■ Alternatives to Scrum include Kanban (29%), Extreme Programming (11%) and Scrumban (8%)
a hybrid of Scrum and Kanban, but agile teams will usually incorporate several additional XP
practices or add the Kanban framework later in their agile journey, once they have mastered
Scrum.
■ Extreme Programming (also known as XP) is rarely followed as a methodology in itself, but
provides a large set of practices that have been adopted widely for use in Scrum and other
methodologies. Scrum implementations often incorporate XP practices, such as test-driven
development (TDD), pair programming, unit testing, code refactoring or continuous integration.
■ Dynamic Systems Development Method (DSDM) has its earliest roots in rapid application
development. One DSDM technique, MoSCoW, is widely applied in agile development as a way
of defining the essential requirements of the minimum viable product (MoSCoW stands for
"must have, should have, could have, won't have" and refers to requirements to meet business
needs). Project focus, rather than product focus, is another important aspect of DSDM.
■ Feature-Driven Development stems from large-scale object modeling and development projects
in Java and focuses the work of development (or feature) teams across a two-week cadence.

Gartner, Inc. | G00278387 Page 3 of 12

 Several FDD practices have been especially influential, such as development by feature, feature
teams, configuration management and regular builds.
■ The Unified Process family of methods (better known as UP methods) — including Rational UP
(RUP), OpenUP, EnterpriseUP and AgileUP — are not, strictly speaking, agile methods. AgileUP
is intended for development organizations that want to think of themselves as agile while
working and delivering in familiar processes and artifacts. The UP methods derive from the
iterative and round-trip engineering tools developed by IBM Rational.

This is by no means an exhaustive list of agile methods; rather, it is a shortlist of the best-known,
team-level frameworks. There are many others that have achieved limited traction and mind share in
the agile world, despite being championed by pioneering agile thinkers. New methods and practices
also emerge every year to offer yet more agile choices.

There are also several methodologies that are usually implemented by mature agile organizations
scaling to large enterprise initiatives. These "enterprise agile frameworks" build on team-level
methodologies such as Scrum or Kanban, and may add program- and portfolio-level coordination to
enable complex releases.

Examples of enterprise agile frameworks include:

■ Disciplined Agile Delivery (also known as DAD) grew out of the UP methods under the guidance
of Scott Ambler at IBM Rational. DAD is a set of enterprise agile process frameworks, a hybrid
of practices drawn from Scrum, Kanban, XP and RUP. DAD can be a comfortable migration
option for development organizations familiar with RUP that are seeking an enterprise agile
framework.
■ Large-Scale Scrum (commonly called LeSS and LeSS Huge), created by Craig Larman and Bas
Vodde, is an enterprise agile framework that applies scaling by extending Scrum with multiple
(between one and eight) Scrum teams or, for LeSS Huge, more than eight teams. The LeSS
principles build on feature teams with customer-centric Lean IT.
■ Scaled Agile Framework (or SAFe), devised by Dean Leffingwell, is a four-level structured
framework that builds on Scrum or Kanban and targets complex enterprise projects across the
team, program, value stream and portfolio levels with detailed, control-oriented management of
multiple release trains drawing heavily on lean principles. SAFe is the best-known enterprise
agile framework and also the most complex in its specification of processes, practices and
organizational models. SAFe can be used to develop embedded or cyberphysical systems.
■ Spotify is an evolving set of roles and practices within an organizational model based on
squads, tribes, chapters and guilds. At the heart of the Spotify framework are feature teams
called "squads" that may use Scrum or Kanban as the team-level framework. Squads are part
of a larger "tribe" and own responsibility for a given feature set. "Chapters" and "guilds" provide
matrix support for specialized expertise and interests, and help ensure consistent practices.

A summary of the agile methodologies discussed above is shown in Table 1. It provides a quick
reference when considering agile alternatives. Organizations starting out (or restarting) their agile
development efforts can use this table to select options to consider further. We include in the table
both team-level frameworks and enterprise agile frameworks.

Page 4 of 12 Gartner, Inc. | G00278387

 Table 1. Methodology Decision Table

Methodology Best-Fit Context

Team-Level Frameworks

Scrum 91% of organizations start with and continue to use Scrum

Constitutes the team-level core of most enterprise agile frameworks
Generally the best fit when a release is at least one week long and backlog priorities can
be kept stable for the duration of a sprint
Complements the popular Extreme Programming practices, with Scrum providing the
process framework

Kanban A continuous process model derived from the Toyota Production System and applied to
software delivery
Especially good fit for projects with large number of small independent tasks or constantly
changing priorities
Fits well with continuous delivery and DevOps
Can be used in combination with Scrum (for example, many organizations use Kanban for
production support, while an iteration-based methodology like Scrum is used for longer-
lasting development efforts)

DSDM Possible fit for an organization with a strong project management organization wanting to
adopt agile
Customizable process with guidance for meeting the needs of solutions across a spectrum
of governance rigor

FDD For organizations that want to keep a design-driven focus and still become more agile
Good source of practices for use with Scrum

UP methods Based on RUP and, therefore, may provide an easier transition to agile for RUP
practitioners

Enterprise Agile Frameworks

DAD Comfortable migration option for development organizations familiar with RUP that are
seeking an enterprise agile framework.
A set of three top-down, control-oriented approaches, but open to incorporating many
agile practices
Includes support for agile modeling and designed for managing trade-offs between risk
and value

LeSS For development organizations seeking to apply Scrum to larger-scale development efforts
A bottom-up, principles-based approach designed to enable multiple scrums (between
zero and eight for LeSS, or more than nine for LeSS Huge) to deliver releases based on
multiple features

SAFe Designed for complex enterprise projects across the team, program, value stream and
portfolio levels with detailed, top-down, control-oriented management
Also suitable for cyberphysical systems
Well-established with excellent availability of training, tools and consulting

Gartner, Inc. | G00278387 Page 5 of 12

 Methodology Best-Fit Context

Spotify With its organizational model based on squads, tribes, chapters and guilds, Spotify's
model is suitable when the need for creativity and innovation among developers is a top
priority
A bottom-up agile approach designed to enable multiple teams to work together, deliver
value through consistent practices and coordinated releases

DAD = Disciplined Agile Delivery; DevOps = development and operations; DSDM = Dynamic Systems Development Method; FDD =
Feature-Driven Development; LeSS = Large-Scale Scrum; PMI = Project Management Institute; RUP = Rational Unified Process; SAFe
= Scaled Agile Framework; UP = Unified Process

Source: Gartner (February 2016)

Pick an Agile Methodology That Has Adequate Training in Your Area

Any selected agile methodology will require both training and continuous improvement in order to fit
and adapt to the larger organization and its established management processes, so make sure the
right levels of training are available close to you.

■ In selecting an agile method or methods, application development leaders will want to consider
the availability of training and tools support. However, a basic level of Scrum training, which is
almost universally available, would serve as a good starting point for any team embarking on
agile development.
■ Agile is a learning process that begins with a clear understanding of its foundational principles.
In order to build basic competency in any of these methods, training and, if available,
certification is advised. Part of selecting a methodology would be evaluating its suitability for a
given organization including its cultural norms, the nature and scale of the projects that will be
undertaken, and the availability of support for the tools selected.
■ All of these listed methods have reasonably good tools support with the exception of Spotify.
FDD and DSDM have limited training available. The methodologies with the most readily
available training and certification are Scrum, Kanban, XP, XP practices, LeSS and SAFe.

Manage the Process of Cultural Change Proactively

Training by itself, while necessary, is not sufficient to enable the cultural changes that must take
place to build an effective agile development organization. Having success with agile methods will
require a fundamentally different organizational culture in both the business and IT organizations.
Formal change management strategies are essential to the successful implementation of agile
methods.

There are several specific shifts in cultural norms from waterfall development to agile, as detailed in
"The Transition to Agile Methods Requires a Culture Shift From 'Me' to 'We.'"

These shifts include:

■ From change avoidance — to change acceptance

Page 6 of 12 Gartner, Inc. | G00278387

 ■ From plan- and sequence-driven — to features and collaboration
■ From task-oriented — to goal-oriented
■ From "Can I trust you?" — to "What do you need?"
■ From faith in processes and technology — to faith in the people leveraging processes and
technology

Underpinning the transition to product-centric development is a transition from a culture of "me" to

a culture of "we." Responsibility proceeds from different assumptions. In agile development, the
team is accountable for its work, and team members are accountable to each other. Moreover,
these teams are self-managed. Authority doesn't flow from the top down, but each individual team
member is responsible to their teammates. The team is the essential cultural unit, not the individual.
Successful agile teams are essentially high-performing, self-managed groups of individuals. Agile
metrics, too, are team-oriented and focused on the customer value delivered by the team.

Continuously Review, Adapt and Improve Your Agile Processes and Practices
Continuous improvement is at the heart of agile. Furthermore, few mature agile organizations use an
unmodified, "off-the-shelf" methodology. Bear in mind that the best methodology for your
organization today may not be the best several years from now. Effective agile organizations
continuously adapt their processes and even change to new methodologies or incorporate new
practices to improve or augment their development capabilities.

"Shu Ha Ri" is a discipline associated with Japanese martial arts that distinguishes the stages of
learning from disciple to master. One simple translation is: "Follow the rules. Know and break the
rules when necessary. Do what you need to do."

In the Shu stage, agile teams conform to the established principles and practices. In the Ha stage,
agile teams know the rules well enough, and why they were made, to be able to deviate from a
principle or practice when necessary. In the Ri stage, agile is second nature and neither rules nor
deviation from rules is relevant. Ri is a level of mastery beyond principles and practices.

In adopting a methodology, it is a good general practice to begin with Shu, implementing the
method as it was designed. Under the guidance of an experienced agile coach, or once thoroughly
familiar with the method, it may be a good idea to vary practices to enable the organization to
function at its best. Regular retrospectives will be a good way to identify these opportunities.

Case Study
What follows is a theoretical case study of a fictional company we have invented to illustrate this
concept. All of the methods and practices involved here have been witnessed in real-word scenarios
by the author or other Gartner analysts.

Gartner, Inc. | G00278387 Page 7 of 12

 Tollway Tech
At Tollway Tech, the company responsible for operating and maintaining a privately owned toll
highway, the transformation to agile arose out of necessity. As their chief architect puts it, "We
realized that things had to change, and they had to change immediately, because there was no way
to sustain what we'd been doing."

The change at the midsize company was sudden. "Basically we pushed everybody into the deep
end of the pool. The whole thing, from inception, took less than three months. We got executive
sponsorship, got everybody trained in Scrum, realigned people into Scrum teams, changed the floor
plan, and off we went. And there was tons of screaming and splashing and dog-paddling, but
nobody drowned."

Today, Tollway Tech successfully manages its entire application portfolio using agile methods.
Individual teams are free to choose their tools and practices within the Scrum framework. And
continuously improving the organization is as important as delivering software solutions.

"Every time we felt like we were over the hump, it turned out that there was another hump. After a
while, we kind of stopped thinking of agile as some kind of destination, and accepted that it was a
continuing journey. But that wasn't discouraging — we became comfortable with the idea of always
changing a little, always getting better. In fact, that's very much what agile was about for us: failing
fast, always retrospecting, always learning."

Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

"Adapt Your Application Architecture Practices to Work Better With Agile Teams"

"Agile Development Organizations Must Define the Role of the Application Architect"

"Avoid Chaos in Agile Development by Defining When a Story Is 'Done'"

"Best Practices for Adopting an Enterprise Agile Framework"

"Enterprise Architects Combine Design Thinking, Lean Startup and Agile to Drive Digital Innovation"

"How to Size, Estimate and Track Agile Releases in a Bimodal World"

"Improve Your Application Delivery With Gartner's ITScore for Applications"

"Magic Quadrant for Enterprise Agile Planning Tools"

"Planning an Agile Project"

"Predicts 2017: Application Development"

"Scrum Is Not Enough: Essential Practices for Agile Success"

Page 8 of 12 Gartner, Inc. | G00278387

 "Survey Analysis: Agile Now at the Tipping Point — Here's How to Succeed"

"The End of the Waterfall as We Know It"

"The Transition to Agile Methods Requires a Culture Shift From 'Me' to 'We'"

"Use Agile and DevOps to Implement Lean IT and Improve Software Delivery"

Note 1 Agile Methods

Extreme Programming (XP): A set of 12 agile development practices intended to improve software
quality and responsiveness to changing customer requirements. Many organizations that primarily
use Scrum also include several of the XP practices.

Kanban: An agile method for managing process with an emphasis on continuous delivery. Unlike
Scrum, Kanban does not specify roles or time-boxed delivery. A lean IT technique, Kanban has
three rules:

1. Visualize what you do

2. Limit work in progress
3. Enhance flow based on pull

Scrum: An agile method based on small teams of cross-functional developers working

collaboratively with a product owner and a scrum master in time-boxed intervals of typically two to
four weeks to deliver increments of software.

Scrumban: is a customized hybrid of Kanban and Scrum, with a pull-based system in which the
team continually grooms the backlog (from Kanban), while retaining planning, review and
retrospective meetings (from Scrum).

Note 2 Process Models

Agile: A development approach that delivers software in increments by following the principles of
the "Agile Manifesto" (1999).

Iterative: An abbreviation of "iterative and incremental development," any combination of both

iterative design or iterative method and incremental build model for software development (Spiral,
which dates back to 1985 DoD-STD-2167). While agile is technically also iterative, it came later and
is distinct in its emphasis on people and collaboration.

Lean IT: The application of lean manufacturing principles to the development and management of IT
products and services. Its central focus is on the elimination of waste, where waste is work that
adds no value to a product or service. Kanban is often used in Lean IT.

Waterfall: A sequential design process used in software development in which value is seen as
flowing steadily through the phases of conception, initiation, analysis, design, construction, testing,
implementation and maintenance.

Gartner, Inc. | G00278387 Page 9 of 12

 Note 3 Enterprise Agile Frameworks
Disciplined Agile Delivery (DAD): An enterprise agile framework with its roots in IBM/Rational
Software's Unified Process, designed to manage complex projects involving multiple scrums.

Large-Scale Scrum (LeSS): An enterprise agile framework comprising a set of principles and rules
to enable scaling of Scrum development across multiple feature teams without losing touch with the
spirit of agile.

Scaled Agile Framework (SAFe): An enterprise agile framework, also with its roots in IBM/Rational
Software's Unified Process, that addresses coordination across the portfolio, program and team-
level management of complex projects.

Spotify: An enterprise agile framework based on feature teams or "squads" that belong to "tribes"
of common functional domains and that support collaboration and best-practice sharing through a
matrix of "chapters," supporting technical specialties, and "guilds" for broader communities of
interest.

Evidence
1 In the 2015 Gartner Research Circle survey, 91% of respondents indicated they use Scrum (see
Figure 1 in the Appendix). Other methods in use include Kanban, XP and Scrumban.

Of CIOs Gartner recently surveyed who are investing in bimodal capability, 76% cite the importance
of adopting an agile methodology as the top-ranked choice of tools for the bimodal transformation.
However, the wide variety of agile methods and practices built to conform to the principles of the
"Agile Manifesto" range from very lightweight approaches to those that are designed for large
numbers of agile teams delivering complex products. Our annual Gartner CIO surveys indicate that
a growing percentage of Gartner clients are developing business solutions using agile
methodologies.

In 2014, CIOs reported that 22% of their IT projects used agile, an increase of 8% since 2010 (see
Figure 2 in the Appendix). In the same period, waterfall projects declined by a similar percentage.

In an even more recent survey on "Agile in the Enterprise," conducted by Gartner's Research Circle,
IT leaders reported that agile is used in 37% of development initiatives. Clearly, agile development is
increasing in IT organizations, and the use of waterfall is declining. CIOs and application leaders that
have not yet moved to agile need a way to understand their agile methodology choices.

Page 10 of 12 Gartner, Inc. | G00278387

 Appendix

Figure 1. Which of These Agile Methods Are Used in Your Organization?

Source: Gartner (February 2016)

Figure 2. Projects Using Waterfall, Iterative and Agile Methodologies, 2010-2014 (Gartner CIO Survey)

Source: Gartner (February 2016)

Gartner, Inc. | G00278387 Page 11 of 12

 GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

© 2016 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see “Guiding Principles on Independence and Objectivity.”

Page 12 of 12 Gartner, Inc. | G00278387