Adopt Disciplined Agile Deli 310317

This research note is restricted to the personal use of jzuazoo@repsol.com.
Adopt Disciplined Agile Delivery for a

Comprehensive and Scalable Agile IT Approach
Published: 1 June 2017 ID: G00310317
Analyst(s): Bill Holz
Success with agile development is important, but comes in different forms

across enterprises. Technical professionals responsible for application
development can use Disciplined Agile Delivery to tune agile processes and
practices, including SAFe, to their specific needs.
Key Findings
■ Scrum is intended for development scenarios in which a single agile team supports a product
throughout its entire development life cycle. Disciplined Agile Delivery (DAD) provides guidance
for project-based agile teams that cannot be dedicated to a single application or product.
■ DAD supports the full solution delivery life cycle by adding "project initiation" and "transition
into production" phases to methodologies primarily focused on implementation (e.g., Scrum or
kanban).
■ A single development life cycle, like Scrum, is not appropriate for all situations (e.g., those with
volatile specifications or those with continuous delivery requirements). DAD teams can choose
the development life cycle that best fits the situation — instead of trying to make the situation fit
the life cycle.
■ DAD supports scaling the use of agile. DAD provides the foundational concepts that are
required to scale, such as DevOps and agile architecture.
Recommendations
Technical professionals responsible for agile application delivery:
■ Tailor your agile practices using the guidance provided by DAD. Use the goal-driven framework
to help determine whether you should stay the course, enhance your current implementation or
choose other options that better fit the current situation.
■ Implement the DAD framework incrementally. Start with a pilot project to build competence and
proficiency. Deliver individual agile projects at the team level first, before trying to scale DAD to
the rest of IT.

■ Implement technical practices like test-driven development, continuous integration, continuous

delivery and DevOps to enable IT teams to work with confidence. As you gain experience, use
the goal-driven approach to determine when you are ready to adopt each practice.
Table of Contents
Analysis.................................................................................................................................................. 3
Disciplined Agile IT............................................................................................................................5
What the Practitioner Needs to Know About DAD............................................................................ 6
Hybrid Framework...................................................................................................................... 6
Roles and Responsibilities: DAD vs. Scrum.................................................................................8
DAD Life Cycles........................................................................................................................11
Goal-Driven Approach.............................................................................................................. 14
Disciplined Agile Architecture.................................................................................................... 16
Scaling Agile With DAD...................................................................................................................19
Disciplined DevOps...................................................................................................................21
Scaling Factors.........................................................................................................................21
Extending SAFe With DAD........................................................................................................23
Strengths........................................................................................................................................24
Weaknesses................................................................................................................................... 25
Guidance..............................................................................................................................................26
The Details........................................................................................................................................... 27
A Brief History of Disciplined Agile Delivery..................................................................................... 27
"The Disciplined Agile Manifesto".................................................................................................... 27
Training and Certifications...............................................................................................................29
Gartner Recommended Reading.......................................................................................................... 30
List of Figures
Figure 1. Software Development Context Framework............................................................................. 4

Figure 2. Scrum Team vs. DAD Team..................................................................................................... 8
Figure 3. Three Phases of the DAD Delivery Life Cycle..........................................................................12
Figure 4. Four DAD Delivery Life Cycles................................................................................................ 13
Figure 5. DAD Process Goals............................................................................................................... 15
Figure 6. DAD Construction Phase Practices........................................................................................ 16
Figure 7. DAD Architecture Community of Practice............................................................................... 18
Page 2 of 32 Gartner, Inc. | G00310317

Figure 8. Enterprise Agile Framework Awareness................................................................................. 20

Figure 9. Scaling Factors Impact Your Strategy.....................................................................................22
Figure 10. Disciplined Agile Values........................................................................................................28
Figure 11. The Principles Behind "The Disciplined Agile Manifesto".......................................................29
Figure 12. Disciplined Agile Certifications..............................................................................................30
Analysis
Disciplined Agile Delivery helps you choose and integrate additional practices to extend Scrum, so
that your agile teams can tailor their processes and practices to fit their current situation.
"The Disciplined Agile Delivery (DAD) process decision

framework is a people-first, learning-oriented hybrid agile
approach to IT solution delivery. It has a risk-value delivery
1
lifecycle, is goal-driven, is enterprise aware, and is scalable."
IT organizations begin their agile transition by adopting methods such as Scrum, along with a few
concepts, such as user stories, which come from extreme programming (XP). Organizations start
their agile journey by running a few pilot projects that allow them to learn about the fundamentals of
agile. As agile maturity grows, technical professionals quickly realize that Scrum doesn't provide
any guidance for situations in which a single agile team cannot be dedicated to a single application
or product. IT organizations support a large number of applications with a relatively small number of
people. Successful agile teams adopt techniques from other sources to extend Scrum and fill in the
gaps that Scrum purposely does not address.
Without guidance on how to customize Scrum to meet their needs, the only choice for many
organizations is to engage agile consultants or to "go it alone" by attempting to implement their own
extensions to Scrum. Extending Scrum or choosing a different life cycle model, like kanban or lean
startup, is a time-consuming, expensive and difficult endeavor, especially when agile process
expertise isn't available to provide guidance. The worst cases result in chaos and a failure to adopt
agile.
DAD takes a hybrid approach to agile solution delivery by leveraging strategies from various
methods, such as Scrum, kanban, Agile Modeling (AM), XP, Unified Process (UP), lean software
development and Scaled Agile Framework (SAFe). To help you tailor your agile process, DAD offers
the necessary expertise by:
■ Providing contextual advice that shows when to use a specific strategy

■ Describing how these agile strategies work together
Gartner, Inc. | G00310317 Page 3 of 32

■ Analyzing the trade-offs associated with these agile strategies
With an understanding of what works, what doesn't and, more importantly, why, you can adopt the
right strategies to address the current situation.
DAD leverages theSoftware Development Context Framework (SDCF), which provides guidance for
selecting and tailoring your strategy. The SDCF provides context for organizing the people,
processes and tools in a software-based solution delivery team. Figure 1 depicts the selection
factors that drive the choice and customization of your team, delivery processes and tools.
Figure 1. Software Development Context Framework
This figure was derived from "Scaling Agile: The Software Development Context Framework."
Source: Adapted from Disciplined Agile 2.X and Disciplined Agile Consortium
For any project, you need to form the team, define the processes for how team members will work
together, and determine what tools the team will use. These decisions are driven by factors such as
the skill and culture of the people, the organizational culture and policies, the nature of the problem,
and the business constraints. The selection factors are only the beginning. You must tailor your
choices further to address the impact of the scaling factors. Different situations require different
solutions.
This research is intended for technical practitioners who are seeking to successfully implement agile
development practices in a situation where they cannot maintain the long-lived product
development teams prescribed by Scrum. This document will not delve into other parts of the
framework, such as portfolio management, product management, enterprise architecture (EA) or
release management. Because the documentation on the Disciplined Agile 2.X website can lack
coherence, this document can be used as a guide to help you navigate the website.

Disciplined Agile IT
Widely available agile advice is oriented toward product development teams — small colocated
teams, with engaged stakeholders, working on an application or product that they support
throughout the entire life span of the application. Unfortunately, few agile IT teams have this luxury.
IT departments typically have limited budget and staff, and this staff must build, maintain, enhance
and support all of the applications in the portfolio. These are the applications that support your
products and power your business. It is not unusual for an agile IT team to develop, enhance and
support many different applications in the course of any given year.
While Scrum and other agile methodologies focus primarily on the construction phase, DAD
provides advice that supports the full delivery life cycle. This advice helps agile IT teams avoid the
water-Scrum-fall trap (see the sidebar).
Water-Scrum-Fall
In water-Scrum-fall, the "water" part begins with upstream activities, such as business
case creation and budgeting. Requirements are executed via waterfall methods. Then,
"Scrum" starts as the requirements, in the form of a product backlog, are thrown over
the wall to the delivery team, which is working in a time-boxed, iterative fashion. "Fall"
begins when the development team completes the construction phase activities and
hands the product over to the dedicated system integration testing team, which
executes manual test scripts, security scans, user acceptance testing (UAT) and
deployment-related tasks.
By incorporating practices based on DAD advice, agile IT teams can:
■ Perform just enough strategic analysis to establish the initial:

■ Vision for the project or application
■ Scope of the effort
■ Data model and technical architecture
■ List of risks
■ Testing strategy
■ Opportunities for reuse
■ Effectively collaborate with infrastructure, security, operations and support teams to align with
the organization's DevOps strategy and ensure smooth transition into production.
Because agile IT teams move from one application/project to the next, they need more than just
guidance for the construction phase. To help teams efficiently ramp up to the next application/
project, DAD adds an explicit, lightweight "inception" phase. Similarly, DAD adds an explicit,
lightweight "transition" phase to support the release of the application/project into production.

What the Practitioner Needs to Know About DAD

Whether you are just starting agile or have been involved in agile development for years, your
starting place for understanding DAD at the team level is Scrum. DAD starts with Scrum and then
allows you to extend or replace it to enable support for a wider variety of real-world situations. Read
"The Scrum Guide" to better understand this evolution.
DAD attempts to explicate both the complexities of solution delivery and the choices you have for it.
DAD is a framework that requires you to evaluate your situation. It will disappoint anyone who just
wants to be told what to do. However, DAD does identify default strategies to help those seeking a
more prescriptive approach to get started.
The elements of DAD that are essential for agile practitioners to understand are:
■ Hybrid Framework. One of the key differentiating features of DAD is that it is a hybrid
framework that builds upon other methods and software process frameworks. This section
examines how DAD adopts practices and strategies from existing sources and provides advice
for successfully integrating them.
■ Roles and Responsibilities — DAD vs. Scrum. DAD redefines the roles delineated in the "The
Scrum Guide," giving them new or additional responsibilities. DAD also defines several new
roles to address the needs of your specific situation.
■ DAD Life Cycles. A full application or product life cycle goes from the initial idea for the
product, through delivery, to operations and support. This section looks at the four delivery life
cycles that allow agile teams to successfully adapt to stakeholder needs.
■ Goal-Driven Approach. By taking a goal-driven approach, DAD avoids being prescriptive, but it
also adds complexity. Anyone looking for a simple "just tell me what to do" strategy will be
disappointed. The goal-driven approach is the mechanism that will help you explore the
available options and practices to effectively tailor your agile development process.
■ Disciplined Agile Architecture. Common architecture enables agile teams to focus on value
creation. Common technical guidance enables greater consistency. Scaling agile to the
enterprise requires effective architecture planning, guidance and collaboration.
To learn more about the entire DAD framework, familiarize yourself with the "Disciplined Agile I.T."
diagram, found on the home page of the Disciplined Agile 2.X website. The diagram is clickable,
enabling you to drill down into any topic to learn about the framework at your own pace.
Hybrid Framework
Agile and lean software development provide a wealth of practices, techniques and strategies, but
also present a huge challenge. Without help, it is difficult to know what the options are and how to
integrate them. Proven strategies from many sources are incorporated into the DAD framework.
Highlighted below are a few of these sources, along with a brief description of what DAD leverages
from each:

■ Scrum is a project management framework for developing and sustaining complex products.
Scrum focuses on the implementation portion of the delivery life cycle. Scrum is the basis for
the DAD "agile/basic" delivery life cycle (see the DAD Life Cycles section).
■ XP is an agile methodology that focuses primarily on building in quality through practices such
as simple design, small releases, continuous integration (CI), test-driven development (TDD) and
pair programming. Teams can extend Scrum or kanban by incorporating XP practices into each
of the DAD life cycle models.
■ Lean software development is based on seven principles: eliminate waste, amplify learning,
decide as late as possible, deliver as fast as possible, empower the team, build integrity in and
see the whole. For example, AM's practices of initial requirements envisioning, iteration
modeling and just in time (JIT) model storming defer commitment to the last most responsible
moment. These practices also help to eliminate waste because you're only modeling what
needs to be built at that point in time. "The Disciplined Agile Manifesto," described in The
Details section below, extends the original "Manifesto for Agile Software Development" by
explicitly adding a new principle for lean development practices.
■ Kanban (Japanese for "visual signal" or "card") is a method for managing work with an
emphasis on JIT delivery. The entire process is visualized, and team members pull work from a
queue or work item pool. Kanban is the basis for the "lean/advanced" DAD life cycle (see the
DAD Life Cycles section).
■ UP is an iterative and incremental process framework for software development. DAD adopts
and enhances several critical governance strategies from UP.
■ AM is a practice-based methodology for effective modeling and documentation of software-
based systems. DAD adopts AM strategies like initial requirements and architecture envisioning,
JIT modeling, and continuous documentation.
■ The Agile Data (AD) method defines a collection of strategies that IT professionals can apply
when working on the data aspects of software systems. DAD incorporates AD practices for
evolutionary/agile database development, including database refactoring, database regression
testing, agile data modeling and continuous database integration.
■ Other methods and frameworks:
■ Strategies for EA, product management, portfolio management, operations and support,
and release management are taken from enterprise IT methods like SAFe and Enterprise
Unified Process (EUP).
■ DAD also leverages techniques and practices from other methods, such as dynamic
systems development method (DSDM), feature-driven development (FDD) and hypothesis-
driven development (HDD). In fact, HDD is the basis for the DAD "exploratory (lean startup)"
life cycle (see the DAD Life Cycles section).
DAD has researched the practices and techniques from these methods and frameworks, and
provides guidance to help you identify, adopt and integrate them.

Roles and Responsibilities: DAD vs. Scrum

If you are familiar with Scrum, then you already know that there are only three defined roles on a
Scrum team: product owner, Scrum master and developer. As Figure 2 shows, DAD has a much
larger set of roles for solution delivery. DAD defines 10 roles, which are divided into two categories:
■ Primary roles. These roles are commonly found on DAD teams, regardless of the scaling
factors (see Figure 1) that impact the team.
■ Secondary roles. These roles are filled, often on a temporary basis, to address needs caused
by the scaling factors.
Figure 2. Scrum Team vs. DAD Team
Source: Gartner (June 2017)
Why does DAD have so many roles? DAD has a larger scope than Scrum. Scrum is primarily
focused on the construction phase and provides no guidance for activities that precede or follow
construction. DAD is focused on supporting the full delivery life cycle (not just construction) and the
aspects of IT solution delivery that Scrum leaves out.
Note: DAD roles are not intended to be positions (i.e., job titles). Any person can serve in one or
more roles in a DAD project. This approach encourages team members to change roles over time.
The creators of DAD recognize that the best way to improve the agility of your team or organization
is by increasing the knowledge, skills and capabilities of the people.

Primary Roles
The first three roles are similar to, or the same as, their counterparts on a Scrum team:
■ Stakeholder. A stakeholder is analogous to a Scrum "customer." The creators of DAD felt that
the term "customer" was often interpreted to mean only "end user," thus leaving out everyone
else who has a vested interest, such as infrastructure, operations, marketing and support
personnel. The term "stakeholder" was chosen to represent the full range of customer types
that have a vested interest in the solution.
■ Product owner. The product owner is the person on the team who speaks as the "one voice of
the customer." The product owner represents the needs and desires of the stakeholder
community to the agile delivery team. As such, the product owner clarifies details and maintains
a prioritized list of work items needed for delivery. The product owner also works with the
architecture owner (see description below) to add and prioritize technical work items. Like a
Scrum team, each DAD team has a single product owner.
■ Team member. A DAD team member is the same as a Scrum "developer." A team member
focuses on producing the actual solution for stakeholders. A team member's duties include, but
are not limited to, testing, analysis, architecture, design, programming, planning and estimation.
The last two primary DAD roles are a departure from Scrum roles:
■ Team lead (TL). A team lead in DAD is an extension of the "Scrum master" role. In DAD, the TL
has additional responsibilities that were previously performed by project and resource
managers. Two of these responsibilities are most concerning, because they have the potential
to change a supposedly open role into a more permanent position. These responsibilities are:
■ Managing the project budget. While this task isn't terribly complicated, the biggest
component of the budget is usually team member compensation. The person filling this role
needs to have access to salary or contract rate information for all members of the team.
Organizations don't typically share such sensitive information with everyone in the
department, increasing the likelihood that the TL role will end up being a position and not a
role.
■ Assessing team member performance. "The Scrum Master is a servant-leader for the
2
Scrum Team." A primary responsibility of the Scrum master is to coach the agile
development team. Assessing team member performance is a responsibility that many
organizations would consider to be supervisory in nature. Therefore, in some
circumstances, the Scrum master/TL would need to be a position and not a role. This
responsibility also changes the entire dynamic of the agile team. Will team members feel
comfortable asking the TL for assistance? Will team members be willing to challenge the TL
when they think the TL is wrong? The potential to impact the trust between the TL and the
team members is very real.
Unfortunately, this is one of the more common adaptations that Scrum teams make on their
own, or that their organizations force upon them. Managers like it because they can hold
one person, the TL, accountable for the performance of the team. In practice, the TL rarely

changes, preventing opportunities for others on the team to grow. Teams that take this
approach tend to be less agile, because team members wait for the TL to make decisions
rather than make those decisions themselves. It is better for managers, not the TL, to own
budget and performance management responsibilities. This approach allows the TL role to
remain open to any qualified team member.
■ Architecture owner. "The best architectures, requirements, and designs emerge from self-
3
organizing teams." In Scrum, there is no architecture role, just developers with architecture
skills. Because architecture is a key source of project risk, DAD has explicitly included the
architecture owner role from AM. The architecture owner guides the architecture decisions for
the team, and facilitates the creation and evolution of the overall solution design. The
architecture owner must have not only a strong technical background, but also a solid
understanding of the business domain. A key advantage of DAD over Scrum is that the
architecture owner works with the product owner to identify technical work items, prioritize
them and then add them to the work item list. Although delivering business value is the highest
priority, mitigating technical risks is also critically important. Read "From Fragile to Agile
Software Architecture," which will help you realize the fundamental goal of all agile
methodologies — rapid feedback that enables development teams to quickly respond to
change.
Secondary Roles
As shown in Figure 2, DAD defines a set of secondary roles that support agile teams on a temporary
or as-needed basis. Often, these roles are needed to address scaling issues (see the Scaling Agile
With DAD section). DAD defines five secondary roles:
■ Specialist. Most agile team members should be generalizing specialists. However, there are
times when the work a team is doing requires someone with specific skills or knowledge (e.g., a
business analyst or a program manager).
■ Domain expert. While the product owner represents a wide range of stakeholders, expecting
that person to be an expert in every nuance of the domain is unreasonable. The team can, as
needed, bring in domain experts, such as tax or legal experts.
■ Technical expert. Technical experts, such as database administrators (DBAs), security experts
and UX experts, are brought in to help the team overcome a difficult problem and to transfer
their skills to one or more developers on the team. Technical experts often work on other teams
that are responsible for enterprise-level technical concerns. In other cases, they are simply
specialists on loan from other agile teams.
■ Independent tester. While the majority of the testing is performed by the members of the DAD
team, some teams are supported by an independent test team. This independent test team is
typically needed when dealing with complex domains, complex technology or regulatory
compliance issues.
■ Integrator. The integrator is responsible for building the entire system from its various
subsystems. Typically, the integrator role is needed only when working at scale with complex

technical solutions. On smaller teams, the integrator role is usually performed by the
architecture owner.
The people who fulfill these secondary roles play a critical part in the team's success. In the IT
organization, these roles tend to have fewer staff members (e.g., fewer DBAs, security experts, UX
experts and infrastructure specialists). This limited staff needs to support development teams while
simultaneously fulfilling production operations responsibilities. Traditionally, the people in these roles
are grouped into service or support teams, and typically work in a support desk type of model.
Thus, they often respond to development support requests with the following:
"Submit a ticket and we'll work on it when it bubbles to the top

of our priority list."
No agile team can effectively work with such a dependency on outside resources. Agile teams need
to be self-sufficient and accountable, and they must have all the resources necessary to complete
their work. The DAD documentation states only that these are temporary roles. Agile teams require
those in secondary roles to be fully accountable to the team, just like primary team members.
Otherwise, DAD teams have little chance of being accountable and self-sufficient. It is therefore
critical that these secondary roles participate in the agile ceremonies, like the sprint planning, sprint
reviews and backlog grooming. Even for part-time team members, participation in these activities
provides awareness of the project vision and roadmap while ensuring delivery of operational
requirements. Ideally, agile teams should have a "go-to" person for each role. These go-to people
are expected to:
■ Coach team members (i.e., share their skills and knowledge to support the personal growth of
others)
■ Do the work themselves when the team lacks the necessary skills
DAD Life Cycles

DAD promotes a full solution delivery life cycle. By comparison, Scrum focuses only on the
construction phase of the development life cycle. The following is a brief description of each of the
phases, as shown in Figure 3:
■ Inception. The purpose of this phase is to do just enough work to get a team started in the right
direction. In the DAD life cycle model, you will perform some initial requirements modeling, initial
architecture modeling, initial planning and other organizational activities during this phase. Be
careful! Don't get caught in the trap of "big design upfront" (aka "analysis paralysis"). Time box
the inception phase so that it takes no longer than two sprints/iterations.
■ Construction. In this phase, the team builds a solution that meets the needs of the
stakeholders. A DAD team will incrementally develop the solution using one of the four DAD
delivery cycles (shown in Figure 4).

■ Transition. This is sometimes called a deployment phase, a release phase or a hardening

sprint. The primary purpose of this phase is to successfully deploy your solution into production
and transition support to operations.
Figure 3. Three Phases of the DAD Delivery Life Cycle
This figure was derived from "Full Agile Delivery Lifecycles."
Unlike other agile methods or frameworks, such as Scrum, Large-Scale Scrum (LeSS) or Nexus,
DAD does not prescribe a single life cycle (see Figure 4). Agile teams get into trouble when they are
forced to follow a specific method, like Scrum, when kanban or lean startup might be the better
choice for the situation. Every agile team must deal with the situation at hand. Therefore, agile
teams require the flexibility to choose the development life cycle that best suits the circumstances.

Figure 4. Four DAD Delivery Life Cycles
This figure was derived from "Full Agile Delivery Lifecycles."
The following is a brief summary for each of the four DAD life cycles:
■ The agile/basic life cycle extends Scrum's construction life cycle. This is where most teams
new to DAD (or even to agile) will begin. DAD replaces some of the Scrum terminology. For
example, DAD uses:
■ "Consumable solution" instead of "working software"
■ "Iterations" instead of "sprints"
■ "Work item list" instead of "sprint backlog"
To understand why these nomenclature differences are significant, consider DAD's "work item
list" as compared to Scrum's "sprint backlog." The DAD work item list includes not only
requirements and defects, but also other schedulable events, such as training, vacations and
mentoring engagements (to assist other teams). In reality, all of these activities need to be
managed, prioritized and completed. In comparison, Scrum is only concerned with the
implementation of user stories and provides no guidance for managing all of the other "work."
■ The lean/advanced life cycle is based on lean/kanban and supports a continuous delivery
approach. Work is pulled into the team from the work item pool when capacity is available, not

on the regular heartbeat of an iteration. The solution is deployed as often as the business
chooses — continuous delivery. By contrast, many practices in the agile/basic approach, such
as detailed planning, retrospectives, demos and detailed modeling, are locked to the iteration
cadence. With a lean/advanced approach, you do something only when it makes sense. This
approach is ideal for teams with volatile priorities (e.g., support teams).
■ The continuous delivery life cycle is a leaner version of the lean/advanced life cycle in which
the product is shipped into production on a very regular basis. Note that the inception and
transition phases have almost disappeared. Combining practices like CI, TDD, acceptance test
automation and DevOps enables teams to achieve continuous deployment, making this an
excellent approach for a team developing microservices.
■ The exploratory (lean startup) life cycle is appropriate when you have a vision of what you
want to build, but you also have a lot of unknowns and uncertainty. Use this highly iterative
approach to execute a series of quick learning experiments: Release a feature, gather feedback
and use the feedback to decide what to do next. Once you have addressed the unknowns, your
team might choose to adopt one of the other DAD life cycles to build out the solution. In other
words, the exploratory life cycle can be an effective replacement for the inception phase of
other DAD life cycles.
Detailed information for all of the DAD life cycles can be found on the Disciplined Agile 2.X website
at "Full Agile Delivery Lifecycles." If you've read the book "Disciplined Agile Delivery: A Practitioner's
4
Guide to Agile Software Delivery in the Enterprise," you should note that, when the book was
published in 2012, DAD focused only on the agile/basic and the lean/advanced life cycles.
Goal-Driven Approach
The DAD framework takes a goal-driven approach, aligning process goals and their supporting
practices with each phase of the delivery life cycle (see Figure 5). As you tailor the delivery method
for your unique situation, the goal-driven approach enables you to make explicit decisions about the
processes and practices that your team will use. DAD provides a list of options with the risks and
benefits of each. For guidance on tailoring your agile process, consult the "Process Goals" page of
the Disciplined Agile 2.X website, which includes drill-down links to associated diagrams. Unless
your situation is completely unique (and yes, that is possible), you won't have to figure it out all on
your own.

Figure 5. DAD Process Goals
This figure was derived from "Process Goals."
Understanding how to use and apply these process goals is essential to successfully leveraging
DAD. An example of how one organization implemented DAD can be found in the case study
"Implementing Disciplined Agile Delivery (DAD) at Panera Bread: A Recipe for Success." This case
study describes how the new-to-agile teams used these process goals to set up their agile
processes and practices.
To highlight how you can use the DAD process goals, let's look at one specific example from this
case study. Figure 6 shows all of the DAD construction phase practices that support the
construction phase goals shown in Figure 5. DAD teams choose the appropriate practices to help
achieve the goals. The underlined practices are the practices that the team at Panera Bread chose
to adopt to begin its agile journey. (Note: It is not advisable for new agile teams to attempt to adopt
all of these practices on their first projects.)

Figure 6. DAD Construction Phase Practices
4
This figure was derived from "Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise."
Source: Adapted from "Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise"
After a few iterations, the team decided to adopt more of these practices to improve quality and
increase velocity. At the time the case study was published, the team recognized the need to
enhance the CI pipeline, and had already committed to doing the work. The team also recognized
the need to improve quality to increase velocity. Therefore, it planned to adopt TDD and continuous
deployment.
The process goals not only help you begin a new agile project, but also help your agile team
improve its delivery capabilities throughout the project. Use the process goals in team retrospective
meetings to help the team both understand the available options and select practices that will help
it improve.
Disciplined Agile Architecture

Traditional approaches to software architecture do not accommodate natural software evolution. Big
design upfront forces you to make decisions too early in the development life cycle, when you
haven't acquired the requisite knowledge. Additionally, architects and developers don't have
practices in place to ensure the implementation aligns with the architectural vision.

Gartner analyst Kirk Knoernschild offers this advice in "From Fragile to Agile Software Architecture":
"The tenet of agile software development — frequent feedback

so you can respond to change — is paramount to increasing
architectural agility. Tech professionals must rely on feedback
that addresses the social, process and structural pillars of
software architecture. There are six foundational practices that
will start the journey to architectural agility. These include
proving architectural vision with working code, architecting all
the way down, generating documentation, validating
architectural decisions, refactoring mercilessly to improve
architecture and starting with the simplest architectural vision
that will work."
"Clearly, some architecture decisions must be made early to

guide the development team, but this vision cannot remain
static throughout development. Instead, once the vision is
established, developers and architects must work very closely
with each other to identify areas where implementation is
highlighting potential flaws in the vision. To do this, architects
must be involved with the day-to-day activities of the
development team."
DAD adopts this same approach, which originated with AM. As discussed in the Primary Roles
section above, DAD extends Scrum and defines an architecture owner for each agile team. The
architecture owner guides the architecture decisions for the team, and facilitates the creation and
evolution of the overall solution design.
At an enterprise level, the architecture must be flexible, easily extended and easily evolved. Agile
enterprise architecture is a collaborative and evolutionary exploration and modeling of an
organization's ecosystem. Enterprise architects must be willing to work in a collaborative and
flexible manner with IT delivery teams and vice versa. One thing that is not clear from the DAD
4
book and website is that all architects (other than the architecture owner) are members of the EA
team. Therefore, the responsibilities of various disciplines, like solution, data, infrastructure and

security architecture, all reside in EA. To learn more about DAD's definition of EA, read "Enterprise
Architecture."
As you scale agile in your development organization, DAD identifies a chief architecture owner role
(see Figure 7). The chief architecture owner serves as the architectural lead for a program, and is
responsible for the following:
■ Mentoring and guiding the architecture owners working on the program

■ Guiding the architecture owners as they negotiate technical dependencies within a program
■ Working closely with the EA team
■ Taking on the role of architecture owner on one or more delivery teams, as needed
Figure 7. DAD Architecture Community of Practice
CoP = community of practice
DAD identifies practices throughout the delivery life cycle to ensure that the implementation and the
architecture remain in alignment. The process goals for the inception phase identify practices that

help the team establish the initial architecture and evolve the architecture throughout the other
phases of delivery. Such goals and practices include:
■ Align with the enterprise. The team adopts common tools and templates, coordinates with
enterprise teams, and determines which existing components (software and infrastructure) can
be reused.
■ Explore the initial scope. The team explores the system — the usage, domain, business
process, user interface and nonfunctional requirements. This exploration results in artifacts like
an initial data model, a prototype UI and an initial work item list.
■ Identify the initial technical strategy. The team explores both the business and the technical
architecture to create the initial business process definition, candidate architecture, UI flow and
delivery strategies.
■ Address changing stakeholder needs. The team supports emergent architecture with
practices like JIT modeling, look-ahead modeling, A/B testing frameworks and model-driven
development (MDD).
■ Prove architecture early. The team supports emergent architecture by employing practices like
architecture spikes and pilots, and by holding reviews with stakeholders.
■ Leverage and enhance existing infrastructure. The team adopts or evolves the enterprise
guidelines, consolidates or refactors databases, and reuses or adapts existing systems.
Scaling Agile With DAD

5
The 2016 Gartner Agile in the Enterprise Survey found that, while SAFe is the most considered
enterprise agile framework, DAD is marginally the most implemented framework (see Figure 8).

Figure 8. Enterprise Agile Framework Awareness
Strictly speaking, DAD is not specifically designed to be a scaling framework for agile delivery, like
Nexus, LeSS or SAFe. Those enterprise agile frameworks describe scaling in terms of the number of
teams (three to 12) working on a single application or value stream (a collection of applications that
produces customer value.) DAD can be used for single teams and provides guidance for when agile
at scale is required.
Before trying to scale your agile implementation, you should honestly answer the following question:
"Do you really need to have large projects?"
Just because you have a large organization does not necessarily mean that you must have large
development teams. Your first approach should be to "scale down" to whatever degree possible,
because large projects have a much greater risk of failure. If your agile teams do not have a solid
agile base, successfully adopting any scaling framework will be difficult. If you have a few small
agile teams that are struggling to succeed, what makes you think you will succeed with large agile
teams?
If you really need to scale up to support a project, DAD supports a "team of teams" concept for
scaling that is similar to the scaling concepts used in other enterprise agile frameworks, such as
Nexus, LeSS and SAFe. DAD breaks down this concept as follows:
■ A small agile team has up to 15 people and a medium agile team has 16 to 30 people working
in the structure shown in Figure 2. Smaller teams are better because coordinating the activities

of larger teams is more difficult. Gartner recommends that agile teams limit team size to seven
members (plus or minus two members).
■ A midsize team of teams can have 12 to 50 people, where each subteam coordinates its own
efforts via a daily stand-up meeting. The subteams coordinate with each other by sending one
person to a second daily stand-up meeting called a "Scrum of Scrums (SoS)." The purpose of
the SoS is for the representatives of each subteam to coordinate any issues that have arisen
within the overall team. DAD sets the limit at four or five subteams, because SoS starts to fall
apart when there are more than five subteams. Note that the other enterprise agile frameworks
provide guidance for supporting more teams. For example, Nexus supports up to nine teams,
LeSS up to eight teams and SAFe up to 12 teams working as a team of teams.
■ A large team of teams may have hundreds of people. The model at the agile team level is similar
to the model for a midsize team of teams. However, to provide the coordination required for a
large program, DAD explicitly adds a leadership team.
Disciplined DevOps
Although DevOps is not in scope for this document, we must point out that DevOps is a key to
scaling agile to meet the needs of the entire enterprise. "Disciplined DevOps" provides a list of both
general and specific DevOps strategies for team dynamics, development operations, support,
release management, data management and EA.
The following Gartner research is recommended to help you begin your own DevOps
implementation:
■ "Solution Path for Achieving Continuous Delivery With Agile and DevOps"
■ "A Guidance Framework for Continuous Integration: The Continuous Delivery 'Heartbeat'"
■ "Implement Agile Database Development to Support Your Continuous Delivery Initiative"
■ "Extending Agile With DevOps to Enable Continuous Delivery"
Scaling Factors
The first thing you should notice about DAD is that it defines agile scaling factors differently than
other enterprise agile frameworks, such as LeSS and SAFe. Other enterprise frameworks predicate
the need for scaling primarily on the number of people or the number of agile teams required to
work on a project or product.
"A lot of the mainstream agile advice is oriented towards small,

co-located teams developing relatively straightforward systems.
But once your team grows, or becomes distributed, or you find

yourself working on a system that isn't so straightforward, you

find that the mainstream agile advice doesn't work quite so well
— at least not without sometimes significant modification. Each
of the scaling factors introduces their own risks, and when
addressed effectively can actually reduce project risk, and for
your project team to succeed you will want to identify the
scaling factors applicable to the situation that you face and act
6
accordingly."
DAD strives to provide the processes and practices that agile teams need to master. This foundation
enables teams to scale successfully when necessary. Figure 9 summarizes each of the DAD scaling
factors and indicates the range for each.
Figure 9. Scaling Factors Impact Your Strategy
This figure was derived from "Document and Automate Processes With Rational Method Composer and Jazz: Part 1. The Value of
Methods in an Agile World."
Source: Adapted from IBM
The following is a brief look at each of these scaling factors:

■ Team size. Mainstream agile processes work well for small teams (seven members, plus or
minus two). However, what if the team is really a team of teams (e.g., 50 people, 100 people or
even 1,000 people)? Team size directly affects how you organize the team and what methods
you use to coordinate and collaborate.
■ Compliance requirements. What if regulatory issues are applicable, such as the Sarbanes-
Oxley Act, International Organization for Standardization (ISO) 9000, or the U.S. Food and Drug
Administration Code of Federal Regulations Title 21 (FDA CFR 21)? Compliance typically
requires additional documentation, additional reviews and, sometimes, a documented process.
■ Geographic distribution. What if the agile team is distributed in a building, or around the
world? Colocated teams are the best option. The problem of geographic distribution is similar to
that of large teams — coordination of team members becomes more difficult. Processes and
tools that support collaboration and communication are required to effectively coordinate
activities. You will need to invest more time in initiation phase activities, like initial modeling and
planning, to mitigate the communication risks associated with distribution.
■ Domain complexity. What if the problem domain is intricate (such as the Internet of Things
[IoT] or air traffic control)? Or, what if the problem domain is a rapidly changing one (such as
financial trading or electronic security assurance)? To address greater domain complexity, invest
more in upfront modeling and planning. Complex domains will also require more focus on your
agile testing strategy. Read "Use Layered Testing to Enable Continuous Delivery of Digital
Business Capabilities" to help develop your testing strategy.
■ Organizational distribution. Sometimes, a project team includes members from different
divisions, from different partner companies or from external agencies. Such teams face the
challenges associated with both large teams and geographically distributed teams. If
outsourcing is involved, then there are added risks associated with procurement and
governance of the outsourced effort. Read "Prepare for Outsourcing Agile Application
Development to Avoid Imminent Failure" to learn more about how you can mitigate such risks.
■ Technical complexity. Working with legacy systems, using multiple platforms or blending
disparate technologies can add technical complexity. As with domain complexity, the greater
the technical complexity, the greater the need for more upfront modeling and more
sophisticated testing throughout the life cycle. Greater technical complexity puts a burden on
the architecture owner, demanding greater agile architecture and design skills. Read the
following to help enhance your agile architecture skills:
■ "A Bimodal Approach to Agile Web Application Architecture"
■ "From Fragile to Agile Software Architecture"
■ "How to Design Microservices for Agile Architecture"
Extending SAFe With DAD

SAFe is an enterprise agile framework designed to handle truly complex systems, consisting of
multiple programs, in organizations that are composed of more than a few dozen teams developing

cyberphysical systems (e.g., automobiles, airplanes and satellites). The framework provides specific
and actionable guidance based on lean/agile development practices, enabling organizations to
address the inherent challenges of developing large-scale software solutions.
It is important to recognize that SAFe does not fit all situations. SAFe is best-suited for large agile
teams (50 to 130 members) in "traditional" organizations working in Mode 1. The Mode 1
development model is a systematic approach that emphasizes a slow pace of change to steadily
improve predictability and maintainability. SAFe is not suited for web-scale organizations, like
Amazon, Spotify or Facebook, working in Mode 2. The Mode 2 development model is an
opportunistic approach that supports a high pace of change to deliver exploratory, innovative web
applications that solve new problems and that optimize for managing uncertainty. If you are
unfamiliar with SAFe, read "Implementing Enterprise Agile Using the Scaled Agile Framework
(SAFe)."
Fortunately, DAD and SAFe are complementary. This should not really be a surprise, considering
both DAD and SAFe come from people with a solid background in UP. SAFe focuses on scaling
agile approaches across an organization, while DAD focuses on developing a solid foundation from
which to scale agile.
How does DAD work with SAFe? The SAFe framework comprises four levels: portfolio, value
stream, program and team (see the "Safe 4.0 for Lean Software and Systems Engineering" diagram
on the SAFe website). While SAFe recommends processes and practices for the program and team
levels, SAFe does not mandate that you use the supplied methodology. DAD can easily fit into the
team level in SAFe. SAFe shows ScrumXP and kanban as the development methodologies at the
team level. DAD fits very nicely because it not only extends Scrum, but also supports a lean/
advanced (kanban) approach.
In addition, DAD's goal-driven approach doesn't just complement SAFe — it also provides a much-
needed extension to SAFe. By adding the continuous delivery and exploratory (lean startup) life
cycles, DAD provides SAFe teams with development life cycle options that support the Mode 2
capabilities SAFe lacks. Because DAD provides rich and flexible guidance for the vast array of
situations that your teams face, using DAD will increase the probability of sustainable success as
you scale.
If your organization chooses to adopt SAFe, it is important to realize that you will still need another
framework. SAFe is not intended to apply to all of the situations you will encounter. DAD provides
knowledge to facilitate scaling agile when necessary. It helps you, your team and the other teams in
your organization understand how and when adaptations are required.
Strengths
■ Builds on proven architecture and development strategies. The DAD framework
incorporates proven strategies, describing the strengths and weaknesses of each and providing
guidance for when and when not to apply them.
■ Provides a goal-driven decision framework. This framework specifically articulates processes
and practices that agile IT delivery teams can adopt to fine-tune their agile implementation.

Even though Scrum focuses on product delivery teams, product delivery teams can also benefit
from the DAD framework. Scrum provides no guidance for activities like TDD, JIT modeling or
agile data modeling. DAD allows you to make informed decisions regarding the processes and
practices that will help you deliver quality solutions.
■ Enables you to choose the life cycle that best fits your needs. DAD identifies processes and
practices that enable agile development teams to choose the development life cycle that best
suits the situation at hand. By definition, Scrum teams are not able to use other development
life cycles, such as the lean/advanced or exploratory (lean startup) life cycles. Trying to force a
project to use Scrum when another approach is better-suited is a recipe for disaster.
■ Provides a foundation for scaling agile. Adopting the DAD methodology forces agile teams to
have a better understanding of the processes and practices. When all teams have a deep
understanding of why they do the things they do, scaling becomes easier because each team
already has experience in using the framework to adapt its individual team practices. Using the
framework, individual teams can look at the relevant scaling factors and make adjustments as
they begin to work as a team of teams. DAD is not a scaling framework per se. However, the
2016 Gartner Agile in the Enterprise Survey revealed that, while SAFe was the most considered
of the enterprise agile frameworks, DAD was marginally the most implemented.
■ Enables and extends SAFe. SAFe leaves the details of construction to you and, as a result,
can prove to be fragile in many organizations. DAD provides the solid process foundation
missing from SAFe. DAD not only complements SAFe, but also extends it.
Weaknesses
■ The framework is complex. DAD is indeed a complex framework, reflecting the inherent
complexity of software development. Explicitly exposing so many strategies and methodologies
can be overwhelming. However, the reality is that someone in your organization had to make the
choices about the development processes that you use. Does that process work for all
situations? If not, how do you currently determine what the available choices are and what the
best course of action is? Whether or not you choose to adopt DAD, the framework provides
value by helping you make those choices.
■ The renaming of accepted Scrum terminology is confusing. DAD chooses to change the
names of accepted Scrum roles and terminology. Are these nomenclature changes necessary?
Despite the reasoning behind these changes, teams experienced and trained in Scrum are likely
to continue to use those more familiar terms. Using the DAD terminology will likely cause
unnecessary confusion when collaborating with people performing Scrum.
■ DAD requires teams to evaluate, and have a clear vision of, their situation. DAD attempts to
make the complexities of solution delivery very explicit. Whether you recognize it or not, the
complexity exists in every organization. Because DAD is a framework that requires you to
evaluate your situation, it will overwhelm anyone looking for a simple "just tell me what to do"
strategy. However, if you are looking for a more prescriptive approach, DAD does provide some
default strategies to help you get started.

■ DAD lacks guidance for transitioning from waterfall. By itself, DAD might not provide enough
guidance for those who are transitioning from traditional models. Some would argue the same is
true for Scrum or XP. Training and consulting are available to help you and your organization
make this transition.
■ DAD documentation lacks coherence. The Disciplined Agile 2.X website and its mind map
diagrams can lack coherence, and they don't go deep enough. For example, as you navigate
from phase, to goal, to practices, you will discover that there is little to no information about the
4
practices or "how" to incorporate them. This information can be found in the DAD book and is
being gradually migrated to the website. The website is a work in progress. It can be frustrating
to use because of duplicated or incomplete information in several areas. There is a lot of useful
information in the articles within the DAD Blog section, but this information needs to be
incorporated into the appropriate areas of the website. DAD extends Scrum and relies heavily
on many other practices and methods, placing the onus on you to learn about them on your
own. Without some basic DAD training, it is easy to feel overwhelmed when trying to find
information on the site.
■ The TL role is overloaded. With its TL role, DAD elevates the Scrum master role to essentially
a project and resource manager. The extra project and resource management responsibilities
define a clear leadership role that will potentially be treated more like a titled position and less
like a role that anyone could fill.
■ The adoption rate is slow. Putting the Gartner Agile in the Enterprise Survey results aside for
the moment, we find that the marketplace recognition for DAD is slow compared with other
agile methods. Over the last two years, Scott Ambler + Associates and the Disciplined Agile
Consortium have been actively working to improve the websites and to gain greater market
visibility. Still, very few Gartner clients have heard of DAD.
■ DAD requires consulting. Due to the lack of specific guidance, experienced coaches and
consultants will be needed to successfully implement DAD. Finding consultants who can assist
you is also difficult; there aren't a lot of them due to DAD's lower visibility. There are only six
consultancies currently listed in the Services section of the DAD website.
Guidance
■ Get trained. Before transitioning to DAD, seek training for each level of your organization
(teams and leaders). Adoption is significantly more difficult when organizations fail to train their
people. Everyone needs to understand not only what they are doing, but more importantly, why
they are doing it in this way. Seek training for your business leaders, IT leaders, and agile teams.
In addition, seek role-specific training for technical leads and product owners/project managers.
Organizations that receive training are more successful with agile adoption.
■ Build in quality. If you are not already executing them, adopt agile technical practices like TDD,
CI and pair work to build in quality and reliability. You can start implementing these agile "best
practices" now. For more information, read "Building Continuous Delivery Confidence With Test-
Driven Development" and "A Guidance Framework for Continuous Integration: The Continuous
Delivery 'Heartbeat.'"

■ Scale only when necessary. If you find that you need to scale agile, it is critical that you
understand what is required to be successful. For more information on these frameworks, read
"Market Guide for Enterprise Agile Frameworks." For more specific analysis of SAFe, read
"Implementing Enterprise Agile Using the Scaled Agile Framework (SAFe)."
■ Adopt and adapt when necessary. If something doesn't work or provide value, then adapt it,
replace it with something else or eliminate it. Use the goal-driven framework to help you adapt
and change your process to improve outcomes.
■ Implement a DevOps practice. Automate builds, environment configuration, testing,
deployment and monitoring. Relying on manual processes will create process bottlenecks that
will impede team cadence. You can start implementing these practices now. For more
information, read "Extending Agile With DevOps to Enable Continuous Delivery."
■ Engage consultants for support. Select consulting vendors to assist with your implementation
and to provide the required training for your staff. A list of certified vendors that provide
consulting services can be found in the Services section of the Disciplined Agile 2.X website.
The Details
A Brief History of Disciplined Agile Delivery
The Disciplined Agile Delivery framework was originally developed at IBM Rational from early 2009
through June 2012 by a team led by Scott Ambler. The team worked closely with business partners,
including Mark Lines, to develop the initial version of the framework.
The DAD 1.0 release occurred in June 2012 with publication of the first DAD book, "Disciplined
4
Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise."
Disciplined Agile 2.0 was initially released in August 2015. Evolution of the DAD framework (now
labeled 2.X) continues at the Disciplined Agile 2.X website.
Ownership of the DAD framework intellectual property effectively passed over to the Disciplined
Agile Consortium in October 2012 and was legally recognized by IBM in June 2014.
"The Disciplined Agile Manifesto"

"The Disciplined Agile Manifesto" is an extension of the original "Manifesto for Agile Software
Development" written in 2001. The changes, as shown in Figure 10, reflect the philosophies behind
the DAD framework.

Figure 10. Disciplined Agile Values
This figure was derived from "The Disciplined Agile Manifesto."
By replacing "working software" with "consumable solutions" DAD recognizes all of the
components that compose successful solution delivery. Solutions are not just composed of
software. The software requires hardware that must be correctly configured, as well as a database
for maintaining information. The popularity of DevOps is a clear recognition that solutions are not
just about the software.
Replacing "customer" with "stakeholder" reinforces the fact that a project or application may have
many types of customers with very different needs. It's easy to forget all of the internal customers
as you are trying to meet the needs of your end users.
Similarly, these changes are also reflected in the principles of "The Disciplined Agile Manifesto" (see
Figure 11). DAD has also extended the original manifesto by adding three additional principles to:
■ Explicitly consider the entire IT ecosystem and its improvement (not just development teams)
■ Incorporate lean principles, systems thinking, workflow visualization and minimization of work in
progress (WIP)
■ Develop necessary governance to allow teams to choose the appropriate methods for delivering
solutions

Figure 11. The Principles Behind "The Disciplined Agile Manifesto"
This figure was derived from "The Disciplined Agile Manifesto."
Training and Certifications

The Disciplined Agile Consortium is for practitioners and supporters of the Disciplined Agile 2.0 (DA
2.0) process decision framework. It provides information on curriculum and certification, access to
certified members, and resources to support DAD activities. The site lists a community of 2,013
members worldwide and is updated regularly with training events (classroom and online).
The DAD certification program is a principled approach based on the Shu-Ha-Ri philosophy of
learning (see Figure 12).
■ Shu. Follow the rules. Disciplined agilists conform to the established principles and practices.
■ Ha. Know and bend the rules when necessary. Disciplined agilists know the rules, as well as the
logic behind them, well enough to deviate from a principle or practice when necessary.

■ Ri. Do what you need to do. DAD is second nature, and neither adherence to rules nor deviation
from rules is relevant. Ri is a level of mastery beyond principles and practices.
When you take a course or pass an online test, you're recognized as a beginner (Shu). Once you
demonstrate some experience and pass additional tests, you will be recognized as an intermediate
(Ha). If you prove that you have deep experience and are actively helping others to become better,
you could become recognized as an expert (Ri). As shown in Figure 12, there are currently five
certifications available for DAD practitioners.
Figure 12. Disciplined Agile Certifications
Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.
"Solution Path for Achieving Continuous Delivery With Agile and DevOps"
"Become an Agile Superhero: Eight Attributes for Success"
"Use Metrics to Drive Your Agile, DevOps and Continuous Delivery Initiatives"
"Use Layered Testing to Enable Continuous Delivery of Digital Business Capabilities"
"Building Continuous Delivery Confidence With Test-Driven Development"

"Implement Agile Database Development to Support Your Continuous Delivery Initiative"
"Implementing Enterprise Agile Using the Scaled Agile Framework (SAFe)"
"Survey Analysis: How Agile in the Enterprise Stumbles, Evolves, Then Succeeds"
"A Bimodal Approach to Agile Web Application Architecture"
"From Fragile to Agile Software Architecture"
"How to Design Microservices for Agile Architecture"
"Refactor Monolithic Software to Maximize Architectural and Delivery Agility"
"Use Agile and DevOps to Implement Lean IT and Improve Software Delivery"
"Market Guide for Enterprise Agile Frameworks"
"Scrum Is Not Enough: Essential Practices for Agile Success"
Evidence
1 "Introduction to DAD," Disciplined Agile 2.X.
2 "The Scrum Guide," Ken Schwaber and Jeff Sutherland.
3 "Principles Behind the Agile Manifesto," Manifesto for Agile Software Development.
4 S.W. Ambler. M. Lines. "Disciplined Agile Delivery: A Practitioner's Guide to Agile Software
Delivery in the Enterprise." IBM Press. 2012.
5 The 2016 Gartner Agile in the Enterprise Survey was conducted from 10 October to 24 October
2016. It was an online survey of Gartner Research Circle Members — a Gartner-managed panel
composed of CIOs, IT leaders, architects and agile practitioners/technical professionals. In total,
176 members participated. Qualified participants included business end users with either an IT or
an IT-business focus as a primary role. The survey was developed collaboratively by a team of
Gartner analysts and was reviewed, tested and administered by Gartner's Research Data and
Analytics team.
6 S. Ambler. "Introduction to the Agile Scaling Model." 2009.

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
© 2017 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.”

Adopt Disciplined Agile Deli 310317

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Adopt Disciplined Agile Deli 310317

Enviado por

Direitos autorais:

Formatos disponíveis

This research note is restricted to the personal use of jzuazoo@repsol.com.

Adopt Disciplined Agile Delivery for a

Analyst(s): Bill Holz

Success with agile development is important, but comes in different forms

This research note is restricted to the personal use of jzuazoo@repsol.com.

■ Implement technical practices like test-driven development, continuous integration, continuous

Figure 1. Software Development Context Framework............................................................................. 4

Page 2 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

Figure 8. Enterprise Agile Framework Awareness................................................................................. 20

"The Disciplined Agile Delivery (DAD) process decision

■ Providing contextual advice that shows when to use a specific strategy

Gartner, Inc. | G00310317 Page 3 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

■ Analyzing the trade-offs associated with these agile strategies

Figure 1. Software Development Context Framework

Page 4 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

By incorporating practices based on DAD advice, agile IT teams can:

■ Perform just enough strategic analysis to establish the initial:

Gartner, Inc. | G00310317 Page 5 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

What the Practitioner Needs to Know About DAD

Page 6 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

Gartner, Inc. | G00310317 Page 7 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

Roles and Responsibilities: DAD vs. Scrum

Source: Gartner (June 2017)

Page 8 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

Gartner, Inc. | G00310317 Page 9 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

Page 10 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

"Submit a ticket and we'll work on it when it bubbles to the top

DAD Life Cycles

Gartner, Inc. | G00310317 Page 11 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

■ Transition. This is sometimes called a deployment phase, a release phase or a hardening

This figure was derived from "Full Agile Delivery Lifecycles."

Page 12 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

Figure 4. Four DAD Delivery Life Cycles

This figure was derived from "Full Agile Delivery Lifecycles."

Gartner, Inc. | G00310317 Page 13 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

Page 14 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

Figure 5. DAD Process Goals

This figure was derived from "Process Goals."

Gartner, Inc. | G00310317 Page 15 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

Figure 6. DAD Construction Phase Practices

Disciplined Agile Architecture

Page 16 of 32 Gartner, Inc. | G00310317

This research note is restricted to the personal use of jzuazoo@repsol.com.

"The tenet of agile software development — frequent feedback

"Clearly, some architecture decisions must be made early to

Gartner, Inc. | G00310317 Page 17 of 32

This research note is restricted to the personal use of jzuazoo@repsol.com.

■ Mentoring and guiding the architecture owners working on the program

CoP = community of practice

Source: Gartner (June 2017)