DISCIPLINED AGILE

The Disciplined Agile® (DA™) Tool Kit ENTERPRISE (DAE)

24 Process Blades
Disciplined Agile Enterprise (DAE)
The Disciplined Agile® (DA™) Tool Kit
24 Process Blades (HEX)
The Disciplined Agile (DA) tool kit provides straightforward guidance to help
organizations streamline their processes in a context-sensitive manner,
providing a solid foundation for business agility. The following diagram
overviews the DA tool kit. Click on the diagram to learn more.
Process Blades
A process blade encompasses a cohesive part of your overall organizational
way of working (WoW). Each process blade addresses a specific
organizational capability, such as Data Management, Continuous
Improvement, or Vendor Management. Process blades are sometimes called
process areas, key process areas (KPAs), or business functions.
This page is organized into the following topics:

 The Disciplined Agile process blades

 The scope of a process blades
 Process blades and the architectural views
 Why “process blade”?
Process blades are represented as hexes in the Disciplined Agile® (DA™)
tool kit, overviewed in Figure 1. The blades appear in the top three layers:
Disciplined DevOps, Value Streams, Disciplined Agile Enterprise (DAE).
There is a fourth layer, Foundation, which captures non-blade aspects of DA.
The Disciplined Agile Process Blades
Process blades are represented as hexes in the Disciplined Agile (DA) tool kit,
overviewed in Figure 1. The blades appear in the top three layers: Disciplined
DevOps, Value Streams, Disciplined Agile Enterprise (DAE). There is a fourth
layer, Foundation, which captures non-blade aspects of DA.

Figure 1. The Disciplined Agile (DA) tool kit (click to enlarge)

The Scope of a Process Blade
The scope of a process blade is a business function, such as Finance, Asset
Management, or Data Management. Each of these functions have deep
histories, going back decades and in some cases centuries, in many cases
comprehensive bodies of knowledge and industry associations supporting
them. We’re not trying to repeat that good work.
The aim of a process blade is to:

1. Provide an overview for people unfamiliar with the topic. We

often find that we need to collaborate with people who have fill
different roles, yet we may know little about their job function. The
process blade descriptions provide an overview of a given business
function, why it’s important, how it fits in to the overall organization,
and what it focuses on. You can quickly gain a better
understanding of another group within your organization as a result.
2. Provide a range of options for experienced practitioners. The
agile and lean communities have been developing new ways of
working in a very wide range of areas for years. Experienced
practitioners may not know of these new techniques, nor realize
how their existing strategies can be modified for agile teams.
The process goal diagram for each blade provides a quick
reference to new and old techniques, pointing the way to
improvement opportunities.
3. Provide a starting point for a Disciplined Agile way of working
(WoW). Each blade is described in terms of mindset, flow, people
(roles), and practices, providing a basis from which to start
improving an existing business function or to initiate one if you don’t
already have it.
4. Put the blade into context. Your organization is a complex
adaptive system (CAS) of interacting people and teams. Teams
within your organization will provide supporting capabilities to
others. For example, finance professionals will collaborate with
vendor management people, solution delivery practitioners, legal
professionals, and many others. What services, what help, will they
provide? How will they do so? A process blade will put these
potential interactions into context.
 5. Point you to more detailed sources. While the content of a blade
doesn’t go deep, DA provides references to quality sources where
you can learn more if you so desire.
6. Enable people to improve cross-team ways of working
(WoW). Having a better understanding about what another team
does and what their priorities are enables you to have better
conversations with them as to how you’re going to work
together. Disciplined Agile Coaches (DACs) and Disciplined Agile
Value Stream Consultants (DAVSCs) focus on helping teams
improve their collaborations with other disparate teams.

Process Blades and the Architectural Views

Each process blade addresses the four architectural views:

1. Mindset. Each process blade extends the principles, promises, and

guidelines of the Disciplined Agile (DA) mindset with philosophies
that are specific to that blade. For example, the Sales process
blade explores concepts that are specific to being successful at
selling.
2. People. Each process blade addresses specialist roles, and
sometimes potential team structures, which are specific to that
blade. For example, the Sales process blade includes specialist
roles such as Sales Manager, Salesperson, and Sales Support
Engineer.
3. Flow. Each process blade describes the business process, or
business flow, that is a common starting point for organizations
new to agile WoW in that area.
4. Practices. DA provides a collection of process options, such as
practices and strategies, that should be chosen and then applied in
a context sensitive manner. These process options are overviewed
by process goal diagrams.
Why “Process Blade”?
Given our philosophies around terminology, in particular our preference for
existing terminology, it is admittedly strange that we created a new term rather
than stick with something like key process area (KPA), process area, or
business function. There are several reasons why we believe these existing
terms are insufficient for DA:

1. Scope. A process blade addresses all four architectural views -

mindset, people, flow, and practices - whereas that isn’t always true
of how the existing terms are usually addressed. Basically, terms
like KPA tend to imply a connotation that isn’t sufficient for our
needs.
2. Cohesion. You can think of a process blade as a cohesive slice of
way of working (WoW), that addresses a specific part of your
organizational process.
3. Straightforward updates. Our original thinking was that we
wanted to get across the idea that a blade could be updated or
even replaced, just like a server blade in your operational
infrastructure. As the situation that a team faces evolves, it should
be possible for the team to update their configuration of a process
blade, or even replace it entirely, with little or no impact to the
teams around them.
ENTERPRISE ARCHITECTURE

Process Blade #1
Disciplined Agile Enterprise (DAE) Layer
Enterprise Architecture
The Enterprise Architecture (EA) process
blade overviews how a disciplined agile EA team will
work. An effective enterprise architecture is flexible,
easily extended, and easily evolved collection of
structures and processes upon which your
organization is built. The act of disciplined agile
enterprise architecture is the collaborative and
evolutionary exploration and potential modelling of an
organization’s architectural ecosystem in a context-
sensitive manner. The implications are that enterprise architects must be
willing to work in a collaborative and flexible manner AND other teams must
be willing to work closely with enterprise architects.
Enterprise architecture, when performed in a disciplined agile manner, is an
important enabler of enterprise. This is true for several reasons:

1. Common architecture enables agile teams to focus on value

creation. A common enterprise architecture enables reuse across
delivery teams. When agile teams have high-quality
assets available to reuse they are able to focus on creating new
value for their stakeholders and not on reinventing new versions of
existing infrastructure.
2. Common guidance enables greater consistency. When teams
follow effective, common conventions and roadmaps it results in
greater quality. This makes it easier to learn about assets that are
new to them, and to evolve those assets as needed. Greater
consistency also makes it easier for people to move between
teams because it will be easier for them to come up to speed on
what the new team is doing and to share their skills with those team
members.
3. Agile architectures enable disaggregation. When your solutions
are built from loosely coupled, highly cohesive components it is
easier to spread work across smaller teams. This reduces overall
risk and organizational complexity, which in turn reduces time-to-
delivery.
4. Common infrastructure enables continuous delivery by value
streams. When there is a common technical infrastructure to
 delivery teams to deploy into it is easier to deploy. The easier it is
to deploy, the more often it makes sense to deploy.
5. Enterprise architecture scales agile. A disciplined agile approach
to enterprise architecture enables organizations to strategically
scale agile strategies across their entire enterprise.
Enterprise Architecture Mindset
Organizations face an increasingly competitive marketplace. To be
competitive, organizations must be able to react to environmental changes
and bring new offerings to market quickly. This requires an adaptive strategy,
which in turn requires a flexible and malleable approach to enterprise
architecture. Enterprise architects require a new mindset to succeed in this
new organizational climate, and new ways of working, that reflect the realities
that they now face. To capture the mindset for effective enterprise
architecture, we extend the principles, promises, and guidelines of
the Disciplined Agile® (DA™) mindset with philosophies.

Figure 1. The Disciplined Agile (DA) mindset for enterprise architecture.

To be effective at enterprise architecture, we embrace these philosophies:

 Work closely with others. First and foremost, disciplined agile

enterprise architects (EAs) collaborate closely with their
stakeholders. These stakeholders include senior leaders, business
teams, and of course solution delivery teams. Disciplined agile EAs
will spend the majority of their time working with stakeholders. The
aim is to guide people in leveraging the architectural vision, rather
than policing teams to force them to follow it.
 Transfer skills and knowledge. Disciplined agile EAs, and
disciplined agilists in general, constantly look for opportunities to
 share their skills and knowledge with others. An important part of an
EA’s job is to help those around them to get better at adding value.
 Balance domain and technology. Disciplined agile EAs must have
an understanding and appreciation of your organization’s domain
(the “business”) and the way that it operates to effectively interact
with, and support, senior leaders. Disciplined Agile EAs must have a
technical background so that they understand the implications of the
technologies in use (either now or in the future) within their
organization.
 Be multi-disciplinary. Enterprise architects will often start their
architecture career as a solution architect, a data architect, a
business architect, or some other architecture specialty. Although
these are good starting points, enterprise architects need to consider
a wider range of issues than those focused on by each of these
specialties. Just as enterprise architecture frameworks such as
TOGAF, Zachman, DODAF and others all take a multi-view
approach, disciplined agile EAs must have the skills, or be in the
process of gaining them, to address a wide range of views.
 Architects also implement. An important part of working closely
with others is to actually work with them, not just tell them what to
do. The implication is that if you’re working with solution delivery
teams, perhaps in the role of architecture owner (AO) on the team,
that you would be prepared to be involved with the development
effort. This enables better collaboration with the team, improved
learning for everyone involved (including the EAs), and it provides
concrete experience for the EAs to bring back into their architectural
artifacts.
 Provide concrete examples. Not everyone likes to read, and not
everyone thinks abstractly. Many people prefer real-world, concrete
examples rather than detailed documents. For example, many
people will want to hear stories about how other organizations are
doing something similar to what the EAs are proposing. Software
developers tend to be even more demanding, preferring to work with
(and then copy) high-quality working code than they are to read a
detailed white paper or detailed model.
 Think about the future, but wait to act. Disciplined Agile EAs will
think through the future needs and direction of their organization, but
realizing that strategies and their environment evolves over time they
will wait until the last-most responsible moment to commit to
 acting. Furthermore, effective EAs know when to trade-off short and
long-term gains and more importantly can help guide their
stakeholders through these decisions while coaching them on the
implications of what they’re doing.
 Flexibly evolve the architecture. Disciplined agile EAs work in an
evolutionary and context-sensitive manner. They recognize that
details will emerge, that they cannot work through everything up front
and that even if they could that their strategies must change with the
times. Because teams work in unique manners, and because they
interact with many teams, effective enterprise architects are
sufficiently flexible and skilled to work in a manner that reflects the
needs of the teams that they work with.
 Relentlessly address technical debt. Disciplined agile EAs should
be a driving force within your organization for addressing technical
debt. They will guide and coach solution delivery teams on both
avoiding new debt and on removing existing debt. In parallel they will
work with business leaders to understand the implications of
technical debt and help guide them in supporting solution delivery
teams in addressing it.
Enterprise Architecture Roles and
Responsibilities
There are several roles that are pertinent to enterprise architecture, as well as
to architecture at the team/program level. Remember that these are roles, not
positions. Small organizations may have a single person taking on every one
of these roles whereas a large organization could have dozens of fine-grained
positions. Remember, context counts. We define the following roles for
Disciplined Agile® (DA™) enterprise architecture:

 Enterprise architect (EA). Enterprise architects are responsible for

envisioning, communicating, and evolving an organization’s
enterprise architecture. The enterprise architecture addresses key
enterprise aspects – including organizational structure, business
processes and strategies, value streams, data and information, and
supporting technologies – and how they fit together and are
expected to evolve over time.
 Chief enterprise architect. The chief enterprise architect, or chief
EA, leads the enterprise architecture team within your organization.
This person is typically an enterprise architect with additional
leadership responsibilities.
 Architecture owner (AO). An AO guides teams, in particular
solution delivery teams, in architecture/solutioning decisions. AOs
will work closely with enterprise architects and may even be in both
roles. AO is a team-level role and are sometimes called agile
solution architects or simply agile architects.
 Chief architecture owner (CAO). A CAO is a program-level role,
leading the architecture efforts across a program (a team of teams).
CAOs are typically senior AOs with leadership responsibilities. CAOs
work closely with EAs, and may also be an EA.
 Specialized architect. This is a “meta role” for architects who focus
on a specific aspect of the enterprise architecture. Table 1 lists
potential specialized architects that may exist within your
organization.
Table 1. Types of specialized architects.

Type of Architectural Focus

Specialized
Architect

Business architect  Organizational business processes

 Aligning business strategy with value
stream and product strategies
 Organizational structure
 Enterprise data

Information/data  Artificial intelligence (AI)

architect
 Data/information security
 Enterprise data
 Information flows

Domain architect  Business architect who is further

specialized into one aspect of your
business domain, such a brokerage
within a financial institution or hydrology
within civil engineering.

Infrastructure  IT network and systems

architect
 Physical equipment
 Physical infrastructure (buildings, …)
 Robotics

Information  Artificial intelligence (AI)

Technology (IT)
 Data/information
architect
 IT network and systems
 IT security
 Robotics
  System integration

Network architect  Cloud-based computing

 IT systems
 Telecommunications

Product/service  All aspects of a single product or

architect service

Security architect  Cyber/info security

 Physical security

Value stream  All aspects of a value stream

architect
 Process flow

Web architect  System integration

 User experience
Enterprise Architecture Team Structures
There is no one right way to organize an enterprise architecture (EA) team,
your approach must be driven by the context of the situation that you find
yourself in. We present three strategies that we’ve seen work in practice.
Each of them describe a potential starting point from which you can tailor an
approach that makes sense for your context. The three strategies are:

1. Collaborative enterprise architecture team

2. Enterprise architecture service team
3. Large enterprise architecture team

Collaborative Enterprise Architecture Team

Structure
This structure is used to collaboratively support Disciplined Agile® Delivery
(DAD) solution teams. Every DAD team has someone in the role
of architecture owner (AO), sometimes called an agile solution architect or
simply an agile architect. This person is responsible for guiding the team
through architectural decisions and for mentoring and coaching other team
members in architecture and design skills. An AO should have a solid
understanding of your organization’s enterprise architecture and be willing to
collaborate closely with the enterprise architecture team. With the
collaborative EA team structure, AOs are members of the enterprise
architecture team. Figure 1 shows how an AO is a member of a delivery team
and a member of the enterprise architecture team at the same time.

Figure 1. A collaborative enterprise architecture team.

A few important observations about this team structure:

 The team is led by someone in the role of Chief Enterprise Architect.

This person may or may be working as a member of a delivery team.
They often spend much of their time collaborating with senior
stakeholders across your organization.
 Sometimes a given person performs the role of AO on several
teams, often due to lack of staff with agile architecture skills. Note
 that this is generally believed to be poor practice as the person will
quickly become a bottleneck.
 There may be enterprise architects who are not currently working
with solution delivery teams. This occurs in organizations where the
architecture work is sufficiently complex to require people focused on
that or because there are more architecture-skilled people available
than are currently needed by solution delivery teams.
 Some teams may not have someone in the role of AO, once again
due to a shortage of skilled people.
The AO will spend most of their time (90-95%) working with one or more
delivery teams and the remainder working performing enterprise architecture
activities. There are several strategies that you can consider for determining
who will be on EA team:

1. Delivery teams nominate their own architecture owners. This

person must then become part of the EA team. The primary
advantage is that this person will already be a respected member
of the delivery team. The potential downside is that they may not
yet have the skills required to be an effective enterprise architect.
2. The enterprise architecture team nominates someone to be an
architecture owner. The advantage of this approach is that the
person will have enterprise architecture knowledge and experience.
The potential disadvantages are that the person may not fit well on
the delivery team, the team may already feel that it has someone in
this role, and that the enterprise architect may not yet have the
skills required to be a productive member of the delivery team. This
top-down approach only works well with agile teams when the
person being added to the team is both known and respected by
them.
3. Each team nominates someone to work with the other team.
With a holocracy-based approach, when there is a need for two
teams to collaborate with one another over a period of time each
team nominates someone to work with that other team. This helps
to ensure that the priorities of both teams are addressed and
ensures more effective communication between the teams,
although has the drawback of requiring more people split across
teams.
This collaborative team structure is typically used by:
  Architecture-oriented organizations. This strategy is common in
organizations willing to make a significant investment in enterprise
architecture.
 Large programs. In this case it ends up being an architecture owner
team for the program, or a program architecture team, and not a true
enterprise architecture team.

Enterprise Architecture as a Service Team

Figure 2 depicts what we call the “EA service team structure.” In this case
stakeholders from external teams will submit a request for the EA team to do
some work. These are typically requests to review their work or to provide
some guidance on an architectural issue. The enterprise architect(s) will
address the requests in priority order, often working in a Kanban-style
manner.
Figure 2. Enterprise architecture as a service team.
The EA service team approach is common when EA teams are starting out or
when they aren’t adequately funded to fully support the teams they are tasked
to serve. Although it is possible to keep this lightweight, and that is often a
necessity due to funding constraints, it can sometimes devolve into a review-
based, documentation heavy approach. Furthermore, due to understaffing the
enterprise architects rarely have the time to coach others in architectural
skills. In extreme situations the EA team becomes a bottleneck for the solution
delivery teams waiting for help from them.

Large Enterprise Architecture Team Structure

Very large organizations, often those with thousands and sometimes tens of
thousands of people in solution delivery teams, need a more sophisticated
approach to organizing their EA team. In these situations, they tend to have a
multi-level approach. For example, we worked with one organization that is
taking a three-level approach to the collaborative team strategy described
earlier. The first level is enterprise architecture for the line of business within a
specific geographic region (e.g. retail banking in Europe), the second level for
the geographic region (e.g. Europe), and the third level for the overall
organization.

With this strategy someone is an AO on a delivery team and a member of the

first level EA team. The chief EA of the first level team is a member of the
second level team for their geographic region, and the chief EA of that team is
a member of the organization-level EA team. In short, this multi-level EA team
structure reflects the overall organization’s structure.

Context Counts
Each EA team structure described above has advantages and disadvantages.
No one approach fits all situations, and as the context of the situation that you
face evolves over time so will the structure of your enterprise architecture
team.
Enterprise Architecture Workflow - External
Figure 1 depicts the major workflows that your disciplined agile enterprise
architecture activities are associated. Note that feedback is implied in the
diagram. For example, where you see the Roadmaps & Models flow from
Enterprise Architecture to Asset Management there is an implied feedback
loop from the asset engineers to the enterprise architects. Also note that the
workflows do not necessarily imply that artifacts exist. For example, some of
the models provided by enterprise architects may be communicated via
discussions rather than diagrams or documents.

Figure 1. Enterprise Architecture Disciplined Agile Workflow

The following table summarizes the workflows depicted in the diagram.

Process Blade Workflow with EA

Asset Enterprise architecture will provide the roadmaps and

Management models to the asset management efforts so that they can
better identify potentially valuable assets. The asset
management team may have assets that the enterprise
architects can use in their work.

Continuous The continuous improvement activities will provide

Improvement potential improvement suggestions for improving
enterprise architecture efforts. Similarly, the EA team
may have insights to share with the rest of the
organization.

Data Enterprise architecture will provide guidance to the data

Management management activities. Operational intelligence
pertaining to production data sources and data activities
will be made available to the EA team to support their
long-term planning efforts.

Disciplined Enterprise architecture provides the roadmaps and

DevOps models to all process blades within the Disciplined
DevOps layer. This information is used to guide the
architecture-oriented decisions made by the teams
performing these activities.

Governance The Governance efforts will provide guidance to the EA

team.

Portfolio Enterprise architecture provides the roadmaps and

Management models to portfolio management. The roadmap is used as
input into identifying potential business value and into
prioritization decisions.

Product Enterprise architecture will provide the roadmaps and

Management models to product management which is an input into
 evolving the vision for a product and identifying new
potential features for products. Product management
provides the business roadmap and stakeholder priorities
to enterprise architecture which is used as input into
evolve the enterprise architecture.

Program Enterprise architecture will provide guidance to large

Management solution delivery teams (programs) in the form of
coaching and mentoring the teams in architectural issues,
providing the technology roadmap, and providing
development guidelines (such as coding conventions,
security conventions, database guidelines, and so on).

Teams Enterprise architects will provide architecture coaching

and guidance to teams throughout your organization. The
aim is to improve architectural decisions within the
teams and to spread architecture knowledge and skills
throughout your organization.

The activities associated with these process blades are often very highly
related. For example, in some organizations the activities associated with
enterprise architecture and asset management are fulfilled by a single group.
In other organizations some product management activities are performed by
the portfolio management team and some by the enterprise architecture team.
Some organizations may choose to have a separate group for each process
blade. Note that the organizational structure will evolve over time as your
various teams learn how to work with one another. Every organization is
different.
Enterprise Architecture Workflow - Internal
The workflow within a Disciplined Agile® enterprise architecture team is
depicted in Figure 1.

Figure 1. The workflow within a disciplined agile enterprise architecture team

There are four major activities:

1. Envision initial architecture. The enterprise architects will spend

several days developing initial, high-level models of the enterprise
architecture. Ideally this will be a face-to-face, initial architecture
envisioning session where the scope is the entire organization, not
just a single solution or value stream. Ideally this is done in an agile
modelling room , also called an Obeya room, so as to streamline
the communication and collaborative modelling efforts. Such a
room is large with lots of whiteboard space, enabling the team to
work on several models in parallel (each of which has its own
section of wall space). The primary purpose of this session is for
the EA team to develop a common understanding, at least a high
level, of the current state of the enterprise architecture and a vision
for how the team would like to see it evolve. Secondary outcomes
 include creating some initial artifacts which the enterprise architects
will evolve over time, (potentially) meeting one another for the first
time, and building bonds between the team members. Potential
challenges to this activity include getting an agile modeling room
(you may have to convert an existing room or accept lower
productivity if you can’t get access to such a room) and the logistics
of getting the right people together at the same time.
2. Collaborate with business stakeholders. On a regular basis
enterprise architects work with business stakeholders to
understand their needs, work with them to envision the future, and
help educate them on the possibilities and constraints of
technology. This collaboration may be in the form of working
sessions, presentations, or one-on-one conversations. These
sessions occur as needed and at times it can be difficult to gain
access to stakeholders as they are often very busy people. See the
process goal Coordinate Activities for potential collaboration
strategies.
3. Collaborate with IT stakeholders. Disciplined agile EAs will spend
the majority of their time, 80 to 90% of it typically, working as
members of solution delivery teams. By doing this they bring their
knowledge, vision, and skills to the team in a pragmatic, hands-on
manner. On Disciplined Agile Delivery (DAD) teams they will often
take on the role of architecture owner (AO) . Enterprise architects
will also work with other IT stakeholders, including operations
engineers, support staff, the data management team and so on so
as to understand their needs.
4. Evolve architecture assets. The enterprise architecture team, or
at least the portion of the team who is currently available, will meet
on a regular basis to evolve the enterprise architecture assets
based on their learnings. A common pattern we’ve seen it for the
team to meet once a week for two hours where they discuss what
they’ve learned that week from working on delivery teams and
working with their various stakeholders. As the result of the meeting
several of the enterprise architects may take on action items to
update existing EA artifacts. These artifacts may include EA
models, reference architectures, development guidelines, white
papers, and so on. When a new major topic arises, such as the
potential adoption of a new platform or a merger with another
organization, the EA may choose to schedule agile modelling
sessions to explore the topic.
Enterprise Architecture Practices
Some methods will choose to prescribe a single approach, such as capturing
architectural requirements in the form of epics or pre-building “architectural
runways,” but the Disciplined Agile® (DA™) tool kit promotes an adaptive,
context-sensitive strategy. DA does this via its goal-driven approach that
indicates the process decision points you need to consider, a range of
techniques or strategies for you to address each decision point, and the
advantages and disadvantages of each technique. Figure 1 depicts the goal
diagram for the Enterprise Architecture process blade.

Figure 1. The enterprise architecture goal diagram (click to enlarge)

The process decision points that you need to consider for enterprise
architecture are:

1. Support stakeholders. Enterprise architects will work with their

stakeholders on a regular basis to understand their needs and to
help them develop a vision for the organization.
2. Support delivery teams. Enterprise architects will work with
solution delivery teams, and ideally be active members of solution
delivery teams, on a regular basis. They may guide the teams in
the business and technical roadmaps, help them to identify
potentially reusable assets, to identify technical debt, and transfer
their skills and knowledge to team members.
3. Negotiate technical dependencies. Like it or not, there are
dependencies between the solutions that we create. For example, if
your system invokes a web service, or calls an API, provided by
another system then you have a dependency on that system.
Enterprise architects will often find that they need to negotiate
these dependencies with other teams, either at a high-level in their
role of Enterprise Architect or sometimes at a detailed level in their
role of Architecture Owner on a delivery team.
4. Explore architectural views. Organizations are complex and as a
result they must be understood from a variety of view points. It’s not
just a matter of writing “architectural epics” on a collection of index
cards. Please refer to the process goal Identify Architecture
Strategy for potential artifacts you may wish to consider using to
capture these views.
5. Tailor architectural framework. The enterprise architecture team
may choose to adopt, and likely tailor, an existing enterprise
architecture framework. These frameworks typically suggest a
multi-view collection of artifacts to create and techniques for doing
so.
6. Evolve roadmap(s). An important output of your enterprise
architecture effort will be one or more roadmaps describing your
business and technology architectural strategies. In agile
organizations this roadmapping occurs in a rolling wave approach
where the roadmap(s) are updated regularly.
7. Evolve enterprise architecture. Enterprise architects will
collaborate with one another, and with their stakeholders, in a
 variety of ways. They may choose to hold architecture
envisioning/modeling sessions or regular meetings where they
share learnings with one another. They will often work together, or
with solution delivery teams, to investigate new technologies or
identify candidate architecture strategies.
8. Capture enterprise architecture. There are two broad categories
for how enterprise architects can capture their work: as documents
or as working/executable examples. High-level models work well
for documentation, although sometimes you may find the need for
detailed documentation as well. Executable artifacts, such as
executable reference architectures or architectural runways, are
usually preferred over documentation by delivery teams.
9. Govern architecture. Architectural activities within your
organization should be governed in a lightweight, collaborative
manner. This is an important activity for enterprise architects as
well as for your governance team.
Enterprise Architecture Strategies for
DevOps
There are several enterprise architecture strategies that support Disciplined
DevOps:

 Reuse mindset. An important thing that your enterprise architecture

efforts will accomplish is the promotion of a reuse mindset
throughout your organization. Delivery teams with a reuse mindset
strive to leverage various types of assets such as data sources,
components, templates, and many others. This reuse mindset is
enabled through education, coaching and mentoring by your
enterprise architects (who are ideally active members of delivery
teams in the role of Architecture Owner). It is also enabled by
roadmaps that indicate the technologies that delivery teams should,
and shouldn’t, be working with. And of course, having high-quality
assets that are easy to discover, to understand, and to apply in the
course of providing real value to your customers enables reuse.
 Technical-debt mindset. Your enterprise architecture effort should
promote strategies that motivate delivery teams to pay down
technical debt when they find it and more important do what they can
to avoid it in the first place. Many technical debt strategies are
embedded right in DAD, but without a technical-debt mindset this
often comes to naught. Enterprise architects, often acting as
Architecture Owners on delivery teams, should coach and mentor
developers around the issues associated with technical debt.
Similarly they should help to educate the senior managers and
stakeholders whom they collaborate with in technical debt as well. It
requires investment to avoid and remove technical debt, and
investment decisions are typically in the hands of these people.
 Development guidelines. An important aspect of enterprise
architecture is the development of guidelines for addressing common
concerns across delivery teams. Your organization may develop
security guidelines, connectivity guidelines, coding standards, and
many others. By following common development guidelines your
delivery teams produce more consistent solutions which in turn
makes them easier to operate and support once in production,
thereby supporting your DevOps strategy. A potential drawback of
 common development guidelines is that developers may feel
constrained by them. To counteract this problem the guidelines
should be developed and evolved in a collaborative manner with the
delivery teams, not imposed from above.
 Roadmaps. Your enterprise architecture efforts include the
definition, support, and evolution of roadmaps that guide the efforts
of the rest of the organization. This in turn supports the creation of a
common and consistent technical infrastructure within your
production environments, enabling common DevOps practices such
as continuous deployment, automated end-to-end regression testing,
and operational monitoring amongst others.
An important aspect of your roadmap is to capture both the existing
operational infrastructure and the future vision for that infrastructure. Your
operational infrastructure potentially includes your network, software services,
servers, middleware, and data sources to name a few elements. As you can
see in Figure 1, when developing your infrastructure vision there are two
issues to consider:

 Ownership. Does your organization own and operate its own

infrastructure or does it outsource some or all of it to external
experts. Outsourcing options include traditional strategies such as
having another organization (such as HP or IBM) run your data
centers to using cloud-technologies hosted by external organizations
(such as Amazon or Google). The advantage of owning your own
infrastructure is the greater level of control that it provides you,
something that is critical when you must guarantee the security and
integrity of your IT solutions. Outsourcing potentially offers greater
flexibility in managing your IT infrastructure and cost savings from
economies of scale. However, outsourcing requires more
sophisticated governance and in the case of traditional strategies is
a potential bottleneck when the outsourcer cannot respond in a
timely manner to your requests.
 Virtualization. Are the elements of your IT infrastructure built to
meet the needs of specific solutions or are they softwarized to
provide malleability and ease of evolution? With softwarization, also
known as software-defined infrastructure (SDI), the elements of your
IT infrastructure are fully virtualized. Softwarization includes IT
infrastructure models such as a software defined data center
(SDDC), software defined storage (SDS), and software defined
network (SDN). Softwarization is typically implemented using cloud-
 based technologies on either side of your firewall. Greater
virtualization offers to increase flexibility and programmability of your
IT infrastructure, and thereby enabling you to optimize resources.
However, the greater flexibility of virtualization can increase the
complexity of your testing efforts and make operational incident
simulation more difficult.

Figure 1. Martin Fowler’s technical debt quadrant.

PEOPLE MANAGEMENT

Process Blade #2
Disciplined Agile Enterprise (DAE) Layer
 People Management
People management goes by many names, including
human resource (HR) management, talent management,
staff management, people operations, and work force
management to name a few. The fundamental goal of the
People Management process blade is to attract and retain
great people who work on awesome teams.

There are several reasons why people management is important for your
organization:

1. People and the way they work together are your primary
determinant of success. Organizations are a collection of teams
working together to support the rest of your enterprise. The
implication is that you need to attract and retain the right people
and build awesome teams comprised of these people.
2. You want to support people’s career aspirations. To retain top
talent your organization needs to help these people remain so by
providing opportunities for fulfilling work, training and coaching in
new skills and new ways of thinking, and in mentoring.
3. Greater employment flexibility attracts a wider range of people.
To what extent will your organization support flexible working
hours, flexible working locations (e.g. allowing people to work from
home), flexible device options (e.g. BYOD), job sharing strategies,
and many more strategies? Greater flexibility increases the
attractiveness of your organization at the cost of requiring more
robust collaboration, management and governance strategies. One
employment strategy does not fit all.
4. Many people-oriented activities fall outside the scope of what
occurs on your work team(s). The hiring of people, people
leaving the company, moving between teams, getting trained in
skills not directly related to their current team efforts, and many
more activities partially or fully land outside the scope of a team.
Yes, a team should be actively involved in the decisions
surrounding who is on the team but that doesn’t imply that they do
all of the work surrounding the hiring process.
5. Legal requirements. Every organization must conform to the laws
of the territories in which they operate, and there are always laws
around how organizations can treat the people that work for them.
These laws vary by country, and sometimes even by territories
within countries, and evolve constantly. The laws pertaining to how
you hire, reward, and fire someone in San Francisco are different
than the laws for someone in Toronto which are different again than
the laws for someone in Moscow.
6. Organizational sustainment. Your organization has long-term
staffing needs, including succession and capacity planning.
Succession planning focuses on identifying and supporting the
people who are being groomed to fill key positions in the
future. Capacity planning focuses on ensuring you will have enough
people with the right skills in the right places at the right times to
get the work done in the future.
7. You need to manage your staffing mix. There are several
employment options available to people: They may be full-time
employees (FTEs) of your organization, they may be independent
contractors working for a defined period of time with your
organization, employees of external service providers who are
assigned to work on your teams, or they may be consultants
working with your organization on more of as-needed, ad-hoc
basis. Each of these employment options have advantages and
disadvantages and your organization needs to actively manage
their overall staffing portfolio to ensure that they are meeting their
long-term needs. This is an aspect of capacity planning.
A Disciplined Agile® Mindset for People
Management
To capture the mindset for effective people management, we extend the
principles, promises, and guidelines of the Disciplined Agile (DA™) mindset
with philosophies.

Figure 1. The Disciplined Agile (DA) mindset for people management.

There is all sorts of great advice out there for how human resource (HR)
professionals can become more agile, including Pia-Maria Thoren’s
book Agile People and the Agile HR Manifesto. Here are what we believe to
be the critical philosophies that underpin a Disciplined Agile mindset for
people management:

1. People aren’t resources. This was certainly a lament as long ago

as the early 1990s and we suspect even earlier than that. Calling
someone a resource is insulting at best and agilists simply don’t
tolerate it. Step one on your agile journey is to jettison the term
resource once and for all, an implication being that “human
resources” must be dropped too. We prefer People Management,
 although others suggest pretty much any combination of
Talent/People/Human and Management/Coordination/Operations.
Pick what works best for your organization, but please abandon the
term HR. Enough is enough.
2. Enable team agility. We need to enable teams to organize
themselves, manage their work, and evolve their own process or
“way of working.” The concept that a team owns their own process,
that it isn’t inflicted upon them by “all seeing management,” is a
fundamental of agile. Having said that, in the Disciplined Agile (DA)
toolkit we recognize that teams must still be governed
appropriately.
3. Energize people. People who are energized, who are happy, who
love their work are far more productive than people who are not.
4. Enable people. We need to help teams get the funding and time
required for training and coaching, to help set up communities of
practice (CoPs)/guilds where people can help each other to learn
their craft, and to help set up centers of excellence (CoEs) that
offer explicit learning support to people. We also need to help
leaders to push decision making authority to the people who do the
work and help these people to accept this authority and
responsibility.
5. Inspire leadership. We want to inspire the leadership within our
organization to be agile themselves, to move away from command-
and-control management and become true leaders who motivate
and enable our staff.
6. Reward for agile behaviors. If we want to have an agile
organization then we need to reward staff for behaviors that lead to
this. The implication is that we need to reward people for delighting
customers, for effective teamwork, for collaboration, and for
learning.
7. Enable cultural and structural fit. When culture and structure
become misaligned we effectively throw sand into the gears of our
organization, reducing our ability to delight our customers. Our
People Management efforts must actively strive to monitor this fit
and then work with teams to help them become better aligned.
8. Be flexible. Our organizations are complex adaptive systems
(CASs) where teams will work together in an evolving, context-
 sensitive manner. One People Management strategy does not fit
all, and any strategy we adopt must adapt as the situation evolves.
9. Reduce cycle time. People managers must be able to move fast
to support people when they need it, to hire good people when they
become available, and to support the evolution of teams and their
way of working when required. The implication is that People
Management professionals need to perform key activities such as
recruitment and supporting learning in a continuous manner, rather
than the episodic efforts of traditional HR that are often motivated
by the needs of a specific project or budget.
10. Govern lightly. Yes, there are still legal requirements and
financial constraints that we must operate under. But, it’s important
to recognize that we often have significant leeway in how we
choose to respond to those requirements and constraints. So
respond lightly. Effective governance is based on educating and
motivating people to “do the right thing” and then making it as easy
as possible for them to do so. Wording this as an agile value –
Motivation and enablement over command and control.
People Management Practices
The following process goal diagram overviews the potential activities
associated with disciplined agile people management. These activities are
performed by, or at least supported by, your people management (often called
a human resource, or HR) team.
Figure 1. The process goal diagram for People Management (click to enlarge).
The process factors that you need to consider for people management are:

1. Build agile culture. An important aim for your people management

efforts is to enhance the agile facets of your organizational culture.
2. Guide careers. Your organization should support the career
aspirations of its staff, providing opportunities to people and
supporting their efforts to achieve their goals.
3. Reward staff. There are many ways that people and teams can be
rewarded, including base pay, bonuses, and non-monetary
rewards. For some people in some organizations their pay is
publicly known (for example, in Canada public employees who
 make over a certain amount have their salaries published
annually) whereas for most people their remuneration strategy is
private.
4. Manage staff changes. Your organization needs to perform basic
functions such as hiring (onboarding) staff, letting people go
(offboarding), promoting, demoting, transferring them and providing
benefits to people.
5. Ensure diversity. Diversity strengthens your organization by
providing the opportunity for better ideas and processes due to a
greater range of skills, perspectives, and experiences.
6. Ensure inclusion. When you include a range of diverse voices in
your decision making you will prove to be more innovative and
more likely to delight your customers.
7. Organize groups. What is your strategy for organizing your IT
department? Your Marketing department? Your Finance
department? For example, for IT do you do it by job function (e.g.
have a business analyst group, a project management group, and
so on), by geography (e.g. a North American IT department, a
European IT department, and so on), by business division (e.g. an
IT group to support Retail banking, an IT group to support
brokerage, and so on), or by value creation (e.g. an IT group to
support a specific product line). Or combinations thereof?
8. Staff groups. You need to identify, and plan for, your
organization’s staffing needs. This includes succession planning for
senior people, critical technical positions (yes, that includes all
those legacy COBOL programmer positions), and other critical
roles such as product owners. This also includes staff capacity
planning/forecasting as well as determining your mix of full time
employees (FTEs) and contractors.
9. Form teams. There are different types of teams that can be formed
to address IT functions, each of which are (self) organized
differently.
10. Evolve teams. Team membership and structure evolve over time,
and there are several common strategies that enable this. Some
teams are ad-hoc, forming when their needed and disbanding when
they’re not, with little or no management intervention. Sometimes
people are assigned to teams and sometimes people volunteer to
 be on a team. Some organizations are holacracies where teams
are self-organizing and have defined strategies for enabling
collaboration and communication between teams.
11. Govern people management. Your people management
activities, just like all other activities, should be governed
effectively. An important aspect of people management governance
is the definition of roles and responsibilities (see Roles on DAD
Teams and DA™ Roles at Scale for suggestions), as is the usual
measurement and monitoring activities. Governance of your People
Management effort is an aspect of your
overall Governance strategy.
12. Measure diversity & inclusion. You need to measure how
diverse and inclusive you are if you are to improve.
People Management: Internal Workflow
This article addresses several topics:

 Internal workflow
o Day to day
o Projects

Internal Workflow
A people management team may be a single person within a small
organization, a small group or department within a medium-sized
organization, and a large group or collection of teams within a large
organization. In many organizations the people management team is still
being called the human resources (HR) team or the HR department, although
some organizations use terms such as Talent Management team or even
People Operations team.
Figure 1 depicts the high-level workflow for a people management team. A
customer of the team, perhaps an employee somewhere in your organization
asking for career guidance or a manager asking for help with their staff,
submits a request to the team. This request is triaged. Straightforward
requests that you address on a regular basis are handled via your day-to-day
workflow. Requests that are unusual, perhaps because they require a large
effort to address or because they are the result of a unique event for your
organization, are either handled via a project lifecycle or are organized into
smaller pieces of work and handled by your day-to-day workflow.
Figure 1. The high-level workflow for a business team (click to enlarge).

Internal Workflow: Day-to-Day (Continuous Flow)

We find that a lean approach where the work is performed in continuous

manner is the most appropriate for the day-to-day work of people
management teams. The fundamental idea is that people management
professionals face a constant stream of requests for help, each of which
should be prioritized and worked appropriately. The lean lifecycle of Figure 2
addresses this situation well.
Figure 2. A lean lifecycle for business teams (click to enlarge).
Let’s work through Figure 2 one aspect at a time:

 New requests. Other teams within your organization will make

requests of a people management team on a regular basis.
Examples of new requests may include onboarding someone,
offboarding someone, helping someone identify a mentor,
addressing behavioural issues of an employee, consulting with a
team or manager to help them to understand people management
issues surrounding a decision, executing on a communication
strategy, addressing a minor regulatory change, and many more.
Sometimes the work for a project (see below) comes in as a large
batch of requests. Each new request captured as a work item and
put into the work item pool for the team.
 Work items. The work items for the team are often maintained via a
Kanban board. For a team working at the same location this is very
likely sticky notes on a whiteboard or wall that is easily accessible by
the team. For a team that is geographically distributed it very likely
be a digital tool such as Jile or Trello. The aim is for the team to self
organize and manage their own work.
 Prioritize the work. Someone within the team, or collaboratively by
the team itself, will need to prioritize the work items. On a software
development team there is often someone in the role of Product
Owner who would do this work. On a People Management team this
role typically doesn’t exist, so this responsibility tends to fall either on
 the Team Lead/Manager. Prioritization is typically performed on a
just-in-time (JIT) basis when the work is pulled into a team, although
it can be done any time at the discretion of the person responsible.
The more frequent that new requests for work come in, the greater
the need to prioritize JIT.
 Pulling work into the team. The team pulls a single work item into
their process when they have the capacity to do more work. You
want to pull in the highest-priority work that can be performed by the
person(s) with the ability to do that sort of work.
 Performing work. The team, or typically a subset of the team,
performs the work to be done to fulfill the given work item.
 Obtain feedback. As the work progresses the people doing it should
obtain feedback from others, in particular the person(s) from which
the request came from, to ensure that they are on the right track.
Feedback can come from informal demonstrations (“hey, can you
come look at this”), formal demonstrations, requests for feedback,
reviews, and so on.
 Coordinate. The team should regularly coordinate the work that they
are doing. A common practice is to have a short (10-15 minute)
huddle/stand-up meeting each day to do so, although we’ve seen
teams coordinate twice a day and other teams as little as once a
week – we find daily to be effective in most situations. During these
coordination sessions the team will typically discuss their priorities
for the day, their expected capacity to do work that day, and any
bottlenecks they foresee or are currently experiencing. Each team
will discover a coordination strategy that works for them – when to
hold the sessions, what to discuss in them, and most importantly
how to keep them short and focussed.
 Replenishment sessions. This is a working session where team
members identify work that they believe should be performed. This
may be to address team-health issues (perhaps to receive training or
have an team-building exercise), to address long-term strategic
goals, or to run experiments with new ways of working (WoW)
amongst other things.
 Finish. When a work item is complete the appropriate customer(s) of
that work item are notified and the team now has capacity to pull
more work in.
Internal Workflow: Projects

A project is a piece of planned work or activity that is performed over a period

of time to achieve a particular outcome. Projects are large pieces of work,
typically taking many days or weeks to accomplish, that require a significant
(for your team/organization) budget. Common projects that a people
management team may experience:

 Review and rework of organizational policies due to regulatory

changes.
 A layoff/downsizing event.
 An acquisition/large onboarding event.
 Annual reviews (yes, this is a questionable practice but many
organizations still do this).
 Organizing a hackathon or college recruiting event.
 Large learning events such as conferences or team-building
exercises.
Figure 3 depicts an agile project lifecycle that a people management team
may choose to follow to implement a project. This lifecycle is based on the
Scrum method and has been extended to address the full lifecycle from
beginning to end.

Figure 3. An agile project lifecycle for a business team (click to enlarge).

Let’s work through Figure 3 one aspect at a time:
1. Initial vision and funding. Someone within your organization will
identify this new project, the outcomes they would like to achieve
from it, and initial funding to do the detailed inception work to get it
going.
2. Organizational roadmaps and guidance. Your organization very
likely has guidance (standards, principles, guidelines, …) that it
expects teams to follow as well as business roadmaps that your
team should work towards. These things should be known to to
team and will guide and constrain the decisions that you make.
3. Project inception/initiation. This should be a short period of time,
typically hours or days. The aim is to perform fundamental project
initiation activities such as putting the project team together, identify
and understand what work needs to be performed, and plan how
you intend to do the work. You want to do just enough
organizational work so that your project will be successful. For
large or complex projects you may find that you want to have an
executive review of your strategy before the rest of the effort
receives funding.
4. Work backlog. The backlog will first be identified during Inception
but then allowed to evolve over time based on feedback and
evolving needs. It is very common, and should be expected, that
your understanding of what work needs to be performed will evolve
as the project progresses. The work backlog is typically ordered by
business value so that your team will focus on the most valuable
work at all times. It is also common to consider dependencies
between work items as well – sometimes if you do X first then Y
and Z are much easier to perform.
5. Iterations/sprints. We have found that a one-week sprint tends to
work best for typical people management projects. At the beginning
of the sprint the team identifies the work the believe they can
complete during that period, they plan what they need to do and
how they’re do it, and then they do it.
6. Iteration/sprint planning. At the beginning of each sprint the team
gets together, they identify the work items they believe they can
accomplish during the sprint and they collaboratively identify what
needs to be done and who will do it. Agile teams are self organizing
in that the people doing the work are the ones who plan the work –
the manager or team lead may facilitate this planning work but they
 don’t tell people what to do. This is an important nuance that is
critical for agile culture.
7. Daily work. People on the team collaborate to accomplish the
work. Hopefully team members are able to work with the customer,
or at least someone who can fairly represent the customer, so that
they can get input into their work to ensure that what they’re doing
reflects the actual needs of the customer.
8. Iteration/sprint wrap up. At the end of each sprint the team should
seek feedback on what they have done, which is particularly
important when they have not had access to their customer(s)
earlier in the sprint. This feedback session is often a “show and tell”
or a demonstration. The team should also consider taking some
time to reflect on how well they’ve been working together so as to
identify potential improvements.
9. New ideas. Customers/stakeholders will often generate new ideas
for your team when they’re given the opportunity to see what
you’ve done. These ideas can come in at any time although it is
common to generate ideas during demo/feedback sessions.
10. Transition. Once the work is complete, or at least a valuable
portion of the work is complete, it should be delivered or
transitioned to the customers.
We find that an agile approach tends to work best for most business-related
projects due to the regular cadence provided by iterations/sprints. Having said
that, there is nothing wrong with taking a lean approach instead if your team is
more comfortable with that. See Figure 4 for this sort of lifecycle. However, in
practice we’ve found that when a people management team prefers a lean
project approach over an agile one the more common strategy is to simply
organize the project work into a collection of tasks and then feed it into your
normal day-to-day workflow.
Figure 4. A lean project lifecycle for a business team (click to enlarge).
Information Technology

Process Blade #3
Disciplined Agile Enterprise (DAE) Layer
Information Technology
Share

The aim of the information technology (IT) process

blade is to guide, administer, and coordinate
investment in IT-based solutions for your
organization. This process blade ties together the
management and governance activities required to
coordinate and integrate the Disciplined
DevOps efforts across your organization.
There are several reasons why organizations need a
Disciplined Agile® approach to IT:

1. IT is critical to the operations of modern organizations. There are very

few business processes that do not involve some form of software-based
automation. To survive, and more importantly to thrive, modern
organizations need an effective IT infrastructure to run their business
processes, ready access to digital intelligence upon which to make better
decisions, and the ability to evolve their IT assets such as software and
data to reflect new ways of working (WoW).
2. IT is a key factor in your ability to innovate. Your organization faces a
complex and constantly evolving environment, requiring you to be able to
innovate quickly. Because your organization runs on software, you require
IT excellence to be able to respond rapidly and execute on your
organizational strategy.
3. IT is complex, and growing more so. Your organization has been
building, buying, integrating, and evolving IT-based solutions for years, and
in some cases decades. Individual IT systems are complex, let alone the
combination of them that your organization has. This complexity has to be
managed, and better yet reduced, otherwise it will grow out of control and
put your organization at risk.
4. You want common IT infrastructure and capability. A DA™ approach
to IT will provide common IT capabilities and supporting infrastructure
across your value streams and organizational units. This requires a careful
balancing act between your short-term need to respond quickly to market
changes and your long-term enterprise operation.
5. IT-based solutions vary. There is a myriad of technologies available to
you, all of which are evolving, and new ones appear every day. The
challenges that your organization faces also vary, often widely, requiring an
appropriate approach to address each one. From an IT point of view,
sometimes you need to purchase and integrate a commercial package, or
work with a cloud-based external platform, or evolve existing legacy
systems, or create a business-led Citizen Development (CD) solution, or
create a bespoke IT solution, or combinations thereof. These efforts need
to be managed and governed well.
6. Undisciplined IT leads to growing technical debt. Technical debt refers
to any quality issues within the implementation of an IT solution that
hampers your ability to work with or evolve that solution. Technical debt is
often thought of as a source code problem, but it also occurs in your user
interface design, in your data sources, in your network architecture, and in
many other places. The greater your technical debt, the more expensive it
is to evolve your IT-based solutions and the slower it is to do so, reducing
your organizational competitiveness.
The information technology (IT) process blade is part of the Disciplined Agile
Enterprise (DAE) layer.
Asset Management

Process Blade #4
Disciplined Agile Enterprise (DAE) Layer
Asset Management
The Asset Management process blade addresses the
purposeful creation (or rescue), management, support,
and governance of potentially usable and reusable
assets across your organization. This is sometimes
referred to as enterprise asset management (EAM) or
the more narrowly focused IT Asset Management
(ITAM). Without ongoing support many people, agile or
otherwise, will take an ad-hoc approach to asset
use/reuse within an organization. Assets are used
when they are applied in serial, such as a photocopier
that is used by people one at a time. Assets are reused when they are
applied in parallel, potentially as the result of copying in the case of intangible
assets such as documents. Assets are also reused when they are
repurposed, such as when a laptop of a former employee is reassigned to a
new employee.
There are several reasons why your organization should consider investing in
explicit asset management:

1. Quicker time to market. The more assets that a team has at its
disposal, either for use or reuse, then the less the team will have to
buy or build, thereby enabling them to focus on producing value for
their customers.
2. Improved quality. When assets are (re)used by multiple people or
teams you are motivated to invest in their quality – high quality
assets are easier to reuse and are thus more likely to be reused
and kept in working order.
3. Improved return on investment (ROI). Asset management
supports your teams to avoid building or buying something that
your organization already has. This leads to greater ROI which in
turn leads to greater value being delivered to your stakeholders.
4. Improved consistency. When teams use the same templates,
services, tools, and other assets this increases the consistency
across teams. This makes them more predictable and easier to
understand.
5. Easier updates to common assets. When assets are
implemented in one place and then reused where needed it is very
easy to update that functionality and then deploy the updated
version. This is particularly true for intangible assets such as
software, documentation, documentation templates, and common
guidance. It can also be for tangible assets too, such as shared
tools and machinery on a work site, common classes of vehicles
(such as delivery trucks), and common computer equipment for
staff.
An important philosophy for succeeding at asset management is to
understand that you have more than one option at your disposal. There are
many types of assets that you can reuse, as you see in Figure 1. First, assets
fall into one of two categories: Tangible assets and intangible assets. Tangible
assets are physical in nature and are made from atoms. Intangible assets are
virtual in nature and are made from bits. Second, we distinguish between five
levels of asset: Personal, templates & examples, components, large-scale
components, and ways of working (WoW).
The left-hand arrow indicates the relative effectiveness of each category –
component reuse is generally more valuable than template/example or
personal reuse in practice. Similarly, the right-hand arrow indicates the
relative difficulty of succeeding at each type of reuse. Personal and
template/example reuse are relatively easy to achieve because you simply
need to find the asset and work with it. Other forms of reuse become hard to
achieve; with large-scale component reuse you need to procure or build the
assets, both of which take time and money.

Potential asset types

The asset categories, from most effective to least effective, are:

1. Way of working (WoW). This includes descriptions of procedures

and guidelines as well as automated processes such as regression
test suites or even robotics.
2. Large-scale components. A large-scale component is an
assemblage of smaller components, where both scales of
component are of interest to you. Where the individual
components bring potential value to your organization, the
assemblage brings greater value than the sum of the values
provided by the individual components.
3. Components. The use of pre-built, fully encapsulated
“components” that your teams employ in their work. Whether
something is considered a component or a large-scale component
depends on your context. For a car manufacturing a vehicle is a
large-scale component build from smaller components, whereas a
car rental agency considers a vehicle to be a component that is
part of their larger fleet.
4. Templates & examples. This is the practice of using a common
set of layouts, or examples of, common artifacts such as
documents or slide decks that people create. When it comes to
tangible assets, this includes casts and dies.
5. Personal. Individuals have their own cache of assets that they use
regularly. This may include example documents that they copy
then update, their own horde of sticky notes or markers, their
favorite tools, and so on.
Your organization may have assets in all ten combinations of asset type and
category simultaneously or it may take advantage of only a subset.
Asset Management Roles and
Responsibilities
There are two primary roles that are pertinent to asset management.
Remember that these are roles, not positions. Small organizations may have
a single person taking on both of these roles whereas a large organization
could have dozens of fine-grained positions. Remember, context counts. We
define the following roles for Disciplined Agile® (DA™) asset management:

1. Asset engineer. Works closely with teams to harvest potentially

reusable assets and to integrate existing assets into their work.
May also develop, evolve, support, and retire assets. Also known
as a reuse engineer.
2. Asset manager. Asset managers lead, manage, and govern the
acquisition and application of assets within your organization.
Asset Management Practices
The process goal diagram of Figure 1 overviews the potential activities
associated with Disciplined Agile® asset management.

Figure 1. The Asset Management goal diagram.

The process decision points that you need to consider for asset management
are:

1. Obtain assets. There are several ways that you can obtain
potential assets. The least effective is to try to build them to be
reusable from the very beginning but this strategy often proves
problematic in practice because it’s hard to predict what other
teams will actually want and as a result you tend to overbuild the
asset. A better approach is to obtain an asset from external
sources, either free (as in the case of open source assets) or
through purchase. In this case the assets are often both under and
 over built – some features you want are missing and many that you
do not want are there. The most effective strategy, in general, is to
harvest an existing asset that is already in use within your
organization and to generalize it so that others will want to reuse it.
2. Publish assets. An asset won’t be (re)used if people don’t know
that it exists. When a new intangible assets are made available
they must put into your organizational reuse repository, described
appropriately, and announced to any interested parties. When
tangible assets are made available for use a similar process is
followed where assets are made available to the appropriate
people and people are informed about how to obtain them.
3. Support asset usage. When it comes to tangible assets, this is
mostly a matter of supporting usage – how do we convince people
to take advantage of the organization’s existing assets, when we
have them and when appropriate, rather than procuring new ones?
When it comes to intangible assets, it’s a matter of reuse. There
are many ways for an asset management team, and better yet the
reuse engineers if they exist, to support Disciplined Agile (DA)
teams. Training, educating, coaching, and mentoring team
members in reuse are fairly straightforward to understand. Some of
the more interesting strategies include working with a delivery team
to configure and even integrate an asset into their work. Reuse
engineers, often working with a team’s architecture owner , will
identify potentially reusable assets that can be harvested and
generalized for reuse.
4. Evolve assets. Your assets will need to be evolved or replaced
over time. For tangible assets this could include regular
maintenance of the asset, repairs to the asset, or upgrades to it.
For intangible assets this includes any work required to generalize
the asset to make it reusable, configuration management of the
asset’s constituent parts, to update an existing asset to support its
evolving purpose, to tailor an asset so that it can be reused in a
new situation, and to eventually retire the asset when it is no longer
needed.
5. Fund usage. There are several ways fund asset usage efforts, as
you can see in Figure 1. The least effective, and often debilitating,
strategy is to put a chargeback strategy in place. The basic idea is
that if someone reuses an asset then they should pay for it (some
organizations will even charge a team for downloading intangible
 assets from their reuse repository, regardless of whether they use it
or not). The problem with this approach is that it in effect punishes
teams for reusing things, thereby motivating them to buy or build
things from scratch in the future. In some organizations it proves
better to not fund the usage effort at all, which typically results in
ad-hoc reuse at best, than it is to put a chargeback scheme in
place. The most effective approach that we’ve seen is to directly
fund the usage support/reuse team, thereby taking cost
considerations out of the equation when people choose to (re)use
an asset.
6. Govern assets. The asset management effort, as with all other
efforts, should be governed in a streamlined, collaborative manner.
This is part of your overall organizational governance/oversight
efforts.
Asset Management Workflow – External
The following diagram overviews the major workflows that a Disciplined
Agile® (DA™) asset management team is associated with. Note that feedback
is implied in the diagram. For example, where you see the Roadmaps &
Models flow from enterprise architecture to asset management there is an
implied feedback loop back to the enterprise architects. Also note that the
workflows do not necessarily imply that artifacts exist. For example, the
Guidance workflow from governance could be a conversation with a
governance person, it could be a concise description of organizational
standards, or it could be a combination of the two.

Figure 1. The external workflow of Asset Management.

The following table summarizes the workflows depicted in the diagram.

Process Blade Workflow with Asset Management

Business There are many assets that business operations may potentially take advantage
operations of to support your organization’s customers.

Continuous As with all other activities within your organization, as people perform them
Improvement they may identify potential improvement suggestions that they or others may
be able to take advantage of. Similarly, others may identify potential
improvements that can be applied to your asset management efforts.

Data Your asset management activities should generate data that can be shared
management with data management, who then store the data, combine it with other data,
and provide valuable intelligence to all areas of the organization. This
intelligence/information is in turn used to provide insight and improve
decision making.

Enterprise The enterprise architects will produce roadmaps and models that teams should
architecture follow. These roadmaps will be used to help drive asset prioritization and
investment decisions.

Finance The Finance team provides funding for your asset management activities.

Governance The Governance team will provide guidance for all aspects of your
organization, including asset management. This guidance typically focuses on
financial and quality goals as well as any regulatory constraints where
appropriate.

IT operations There are many assets that IT operations may potentially take advantage of to
support your organization.

Product The Product Management team will provide product roadmaps and
management stakeholder priorities. These roadmaps will be used to help drive asset
prioritization and investment decisions.
Teams Teams throughout your organization may create potentially reusable assets
and may leverage existing assets.

Vendor Purchase agreements Some assets will need to be purchased or leased from
management external vendors. Vendor management will help negotiating agreements with
these vendors.
Asset Management Workflow – Internal
Figure 1 overviews the internal workflow performed by an asset management
team. Much, but not all, of their work is focused on working with and
supporting teams.

Figure 1. The internal workflow of Asset Management.

Let’s work through the primary activities performed by an asset management
team:

1. Guide teams in application of asset. An important activity for

asset engineers is to provide guidance to teams regarding what
assets are available for (re)use, how to go about accessing and
applying the assets, and educating teams in why doing so is
important to both the team and to your organization. In the case of
a solution delivery team, their architecture owner will collaborate
 with the asset management team to bring an asset engineer into
the team at the right time to help.
2. Obtain assets. Asset engineers will obtain potential assets from a
variety of sources, including from the marketplace and from internal
teams. Based on the various organizational roadmaps, and the
needs of the teams that they’re working with, the asset
management team will often work with teams to identify and obtain
the appropriate assets from the marketplace via your vendor
management team. The goal is to find assets that fit the needs of
individual teams in a way that aligns with the direction of the
organization. Furthermore, asset engineers tend to monitor what
teams are doing, often by working closely with your
organization’s enterprise architecture team and the architecture
owners on delivery teams, to help them identify potentially reusable
assets. When a team believes it has built something that is
potentially reusable by others, or when the asset engineers believe
they have done so, then the asset engineers work with the team to
understand and harvest that asset.
3. Publish assets. An asset is potentially reusable when it is of high
quality, it is appropriately documented, one or more examples exist
of how to use it, and it is findable by others. The publishing process
ensures that all of these criteria are true. The asset engineers will
do the work to publish the asset, refactoring and documenting it as
needed and harvesting any usage examples if available (and
creating some when not). After doing so, they will save the asset
and its related supporting artifacts into your organization’s asset
repository, announcing the availability of the new asset after doing
so.
4. Configure asset for specific use. Asset engineers will often work
with a team to help them to configure an asset for specific use. The
goal is to make it as easy as possible for others to (re)use existing
assets.
5. Integrate asset(s) into a solution. Asset engineers will often work
with delivery teams to integrate a reusable asset into their solution,
once again to make it as easy as possible for teams to reuse
existing assets. Interestingly, an important aspect of harvesting an
asset for reuse is to help the source team to integrate the improved
version of the asset back into their solution. This helps to increase
 the likelihood that teams will offer up potential assets for harvesting
and publishing.
6. Evolve assets. Assets need to evolve over time to reflect changing
requirements and implementation technologies. The implication is
that the owners of the assets, often the asset management team,
will need to evolve their assets, publish new versions, and
deprecate old versions. This is work that must be funded and
supported properly.
Funding Reuse
Your approach to funding is a critical success factor for your asset
management strategy. As you see in Figure 1, the funding strategies, from
most to least desirable, are:

1. Funded reuse/usage team. A team of one or more people in the

role of asset engineer is provided explicit funding to support and
enhance the reuse efforts within your teams
2. Asset-level funding. Funding for a specific asset, such as a
security framework or collection of physical tools, is explicitly
budgeted for. This funding should cover the development,
enhancement, and long-term support and maintenance of the
asset.
3. Team-based funding. Funding for the use, development, and
enhancement of assets is included in the budget individual teams.
Such funding is often accompanied by mandates along the lines of
“The team will achieve X% levels of reuse” (although teams are
rarely measured against these mandates in practice).
4. No funding. With this approach (re)use occurs on an ad-hoc basis
within teams, often driven by tactical decisions at the team level as
opposed to strategic decisions at the organizational level.
5. Chargeback. Teams are charged for usage of an asset. In some
extreme cases teams are charged to download an intangible asset
from the asset repository, typically because that’s easier to than
charging for actual usage.
Figure 1. The Asset Management goal diagram.
Table 1 compares and contrasts these funding strategies. Combinations of
these strategies can of course be implemented.
Table 1. Comparing the reuse funding strategies.

Strategy Advantages Disadvantages Considerations

Funded  Reuse is  Value  Supports a

reuse/usage actively provided by robust,
team supported asset organization-
across all management wide, asset
teams must be management
measured to strategy
 Long-term
justify
support  Significant
continued,
activities, discipline
such as required:
 evolution of year-over- Executives
assets and the year funding must
asset understand
 Asset
repository, and be
management
are directly prepared to
team becomes
funded execute an
a target for
explicit asset
 Cost of asset financial cuts
engineering
management because the
strategy
is easily cost is easily
measured measured but
the value
provided is
difficult to
measure

Asset-level  Development  Typically  Useful first-

funding of potentially used for step towards
reusable initial the funding
assets are development of an asset-
funded in a of an asset, engineering
targeted but long-term team
manner support and
 Can be made
enhancement
 Cost of to work in
is often
individual organizations
neglected
assets easily with a
measured  Can result in project-based
development funding,
of similar although
assets by long-term
disparate support and
teams enhancement
of the asset
can be a
struggle in
such
situations

Team-based  Development  Difficult to  This strategy

funding of potentially fund ongoing may be your
 reusable enhancement only option in
assets are and support organizations
funded of your with strict
reusable project-based
assets with funding
this strategy,
unless the
team is stable
over the long
term and
willing to
support the
assets that
they create
 Funds
earmarked for
asset
development
often
diverted
 Many
“potentially
reusable
assets” are
created yet
few are
(re)used by
other teams
due to lack of
infrastructure
to support
wide-scale
asset
management

No funding  Some teams,  Reuse will be  The only way

particularly inconsistent reuse will
 very at the happen in this
disciplined organization situation is
ones, will still level through the
choose to maturity
have high and enterprise
levels of awareness of
reuse even your teams
when no
organizational
support is
provided

Chargeback  Potential  Teams are  Chargeback

exists to fund punished for strategies will
ongoing reusing undermine if
support and assets, not destroy
enhancement motivating your asset
of assets them to create management
their own efforts
versions
 Complexity
of chargeback
added to
overall
organizational
bureaucracy,
effectively
adding waste
to your
processes
Why is Asset Management Hard?
There are some aspects of asset management that are reasonably
straightforward, although a fair amount of work at times, such keeping track of
assets. Other aspects are inherently difficult, in particular supporting the use
or reuse of assets. For example, it is much more convenient to have my own
desk at the office rather than to use one of a common set of desks in a
“hoteling” arrangement. It can be more challenging, and even fun, for a
software team to create a new data source rather than reuse an existing
database that is shared across dozens or even hundreds of other systems in
your organization. Disciplined asset (re)use takes a bit of effort for the
individual, so it can be challenging to nurture and support.
One of the great things about intangible assets – such as documents,
procedures, videos, and software – is that they can be reused repeatedly. To
a lesser extent some physical assets can also be reused or shared. Existing
office furniture is often passed on to the next employee, equipment is shared
amongst people, and of course buildings are shared. In both cases the
primary issue is whether the asset is appropriate for use in a potentially
different situation. As you can see in Figure 1, there is a very wide range of
potential assets that can be (re)used.

Potential asset types

Unfortunately, reuse is a lot easier to talk about than it is to implement in
practice, at least beyond the personal level. There are several reasons why
reuse engineering is difficult to achieve:

1. There is a greater impact when shared assets break. When an

asset is used in only one place and it breaks, then the impact of
that breakage is limited to that one place. When an asset is reused
in dozens or hundreds of places, and it breaks, then the impact is
significantly larger. This is reusable assets need to be of high
quality.
2. We must go beyond personal reuse. Reuse is often described as
not “reinventing the wheel,” and an important step for succeeding at
reuse is to understand that you have more than one option at your
disposal (as you see in Figure 1).
3. Reuse/sharing requires enterprise awareness. For (re)use to
succeed teams must understand that the assets exist, how these
assets fit into your overall ecosystem and way of working (WoW),
and what the benefits of working with the assets are for them and
for your organization. In Disciplined Agile® we promote the
philosophy that teams should work closely with enterprise
architects and asset managers, if any exist, so that they will better
understand and appreciate these issues.
4. Asset management requires investment. To get beyond ad-hoc
reuse your organization will need to invest in an asset management
program. Particularly for intangible assets this may include
investment in a reuse engineering team, in a reuse repository, in
the development/rescue of potentially reusable assets, and the
long-term maintenance and support of those assets.
5. Fund asset management wisely. A critical success factor for
asset management is your approach to funding it. If it is less
expensive for a team to buy or build an asset than it is to (re)use an
existing enterprise asset then they are motivated to do exactly that.
Although it can be challenging, it is very possible and highly desirable for your
organization to succeed at asset management.
Asset Management Terminology
We use the following definitions for common asset management terminology:

 Asset. An artifact that is retained after its initial purpose is fulfilled.

Assets may be tangible (made from atoms) or intangible (made from
bits). For example, a chair is a tangible asset that can be used by
different people over time. Working source code is an intangible
asset because it is retained and potentially updated in the future to
address new stakeholder needs.
 Asset management. The purposeful creation (or rescue),
management, support, and governance of potentially reusable
assets across your organization.
 Asset usage.The utilization or application of an asset that cannot be
reproduced and therefore must be used in a serial manner. For
example, a specific hammer can be used by one person at a time,
you cannot use the hammer while I am using it but you could use it
after I’m done with it. Similarly, an electronic book with strict digital
rights management (DRM) licensing rules can be read by one
person at a time, but two or more people wouldn’t be allowed to copy
that single license to read the book in parallel. Yes, you could buy
another copy of that hammer or that e-book but they would be
different instances that you needed to pay for.
 Asset reuse. First, the utilization of an intangible asset that can be
easily reproduced so that it is effectively used in parallel by multiple
people or things. Second, the continued usage of a non-reproducible
asset for a new purpose. Examples: A template for a slide deck can
be copied as many times as needed and applied in numerous
presentations; a web service can be invoked by a multitude of
software programs, enabling those programs to reuse the existing
functionality rather than redeveloping it from scratch; and the office
furniture that was previously used by the person who had “your”
cubicle before you.
 Robust asset. An asset that is appropriately documented,
generalized beyond the needs of a single team, thoroughly tested, is
of high quality, and ideally has several examples to show how to
work with it where appropriate. Robust assets are much more likely
to be (re)used than items without these characteristics.
 Reusable asset. A robust asset that has been used at least three
separate times by at least three separate teams. You can claim that
something is reusable, but it isn’t truly reusable until it’s actually
been reused; reusability is in the eye of the reuser, not in the eye of
the creator.
 Ad-hoc reuse. An informal approach to reuse where individuals or
teams reuse whatever they can find on their own. Ad-hoc reuse is
often a good start.
 Engineered reuse. A formalized approach to reuse where an
organization actively supports the creation/purchase and
management of reusable assets.
TRANSFORMATION

Process Blade #5
Disciplined Agile Enterprise (DAE) Layer
Transformation
The aim of the transformation process blade is to
guide and govern your efforts towards becoming a
learning organization. Your transformation journey
Isn’t just about adopting Disciplined Agile® (DA™),
and it certainly isn’t about adopting a specific agile
framework. The Disciplined Agile (DA) transformation
strategy is to improve in place. As you see in Figure 1,
you start where you are and identify the transformation
path(s) that are right for you given your current
situation. An organization that has never attempted an agile transformation, or
who has had several failed attempts, should follow a different improvement
path than an organization that has successfully adopted an agile framework
such as Scrum or SAFe. The transformation of a business area such as
Marketing, Finance, or People Management (Human Resources) requires a
different approach than the transformation of a software development team. In
all cases you will apply the DA tool kit to help evolve into a learning
organization.

Figure 1. Improve in place to become a learning organization.

There are several reasons why organizations need a Disciplined Agile
approach to transformation:

1. Transformations are difficult. Successful transformations require

the adoption of new ways of thinking, new ways of working, and
new technologies. That’s the easy part. Successful transformations
also require the abandonment of some, but not all, of your current
ways of thinking, your current ways of working, and your current
technologies. It’s never obvious what you need to keep, what you
need to drop, and what you need to adopt – and the answers
evolve over time as your situation evolves.
2. Agile framework adoption is only a good start. Assuming you
choose the right framework, and you adopt it successfully, that’s
still only a good start. Each agile framework addresses a certain
problem space, but once that problem is solved where do you go
from there? Don’t you want to continue improving, moving beyond
the framework to address the new problems that you face?
3. Transformations require significant
investment. Transformations are journeys, not destinations. It will
take time, in most cases years rather than months, and effort to
succeed.
4. Your transformation strategy is context dependent. There is no
one right way to transform an organization. Because your
organization is unique, with your own priorities and challenges, you
want a fit-for-purpose and flexible strategy that reflects your actual
situations. That is why the strategy overviewed in Figure 1 shows
several paths to get from where you are today to get to becoming a
learning organization in the future.
5. One transformation strategy is not sufficient. Different parts of
your organize improve at different rates, in different ways, and at
different times. Context counts. The way that your project
management office (PMO) transforms will differ from the way that
your data management group transforms, which will differ yet again
from how your marketing team will transform. And these are all just
parts of your overall organizational transformation.
6. The real goal is to become a learning organization. We cannot
say this enough.
This process blade is part of the Disciplined Agile Enterprise (DAE) layer.
FINANCE

Process Blade #6
Disciplined Agile Enterprise (DAE) Layer
Finance
Your Disciplined Agile® Finance efforts will focus on a
collection of potentially competing goals, such as
ensuring cash flow within your organization, ensuring
your money is being spent well, taxes are minimized,
spending is properly tracked and recorded, and legal
financial reporting is being performed properly. All of
this will be performed in a manner that is compliant with
applicable financial regulations, such as Financial
Accounting Standards Board (FASB) and International
Accounting Standards Board (IASB) guidelines.

Finance Mindset
A Disciplined Agile® approach to finance is based on the following
philosophies:

1. Spend the money wisely. Your true goal should be to help your
organization invest your revenue well, not just to set and monitor
budgets. In other words, finance people must help others to make
important decisions, not just “count the beans.”
2. Constrain teams with budgets, but don’t hobble them. A budget
is the total sum of funds set aside for a given purpose, it is a ceiling
on how much you’re willing to spend on an idea. Financial
constraints can motivate teams to be more creative and to focus on
just the key aspects of a value stream. However, when teams have
insufficient funding their ability to react to new opportunities will be
greatly diminished.
3. Distinguish between financial reporting and financial
budgeting. Financial reporting is often quarterly and annual, as per
common legal requirements of publicly traded companies. Financial
budgeting, on the other hand, can be on a schedule of your own
choosing and does not need to be tied to the calendar.
4. Prefer rolling wave budgeting over annual budgeting.
A Disciplined Agile Enterprise (DAE) must be able to respond
 rapidly to new opportunities and unpredictable events, but the
annual budgeting approach was never designed to enable that. In
the book Beyond Budgeting Jeremy Hope and Robin Fraser
describe how to take a continuous approach to budgeting that
enables you to invest revenue, control costs, and ensure you are
moving in the right direction more effectively than traditional annual
budgeting strategies ever did. The basic idea is to think through
current expenditures in detail and future expenditures in less detail,
monitoring both opportunities and challenges so that you can
flexibly and sensibly direct funds where they are most needed
today.
5. Provide financial guidance to others. Your financial staff will
regularly help teams and people within your organization to
understand the financial implications of their decisions. They will
also help to educate people in the fundamentals of finance to
enable them to make more informed decisions.
6. Monitor the cash flow of value streams. Finance people will
collaborate with value stream leaders to provide guidance into their
go-forward strategies. Sometimes a value stream needs to pivot,
sell off the business, or simply end it before it goes too far into loss
territory. You want to ensure that your incoming revenues are
sufficient to fund the enterprise and to identify which of your value
streams are healthy “going concerns.”
7. Prefer activity-based accounting over resource-based
accounting. With an activity-based approach you allocate the total
costs to the value stream that drives those costs (and generates
the revenue) so that you have a true picture of the financial benefits
provided by the value stream. With resource-based accounting you
allocate costs to functional areas such as IT or marketing, often
treating them as an overhead instead of as a key part to your value
stream(s).
8. Prefer team-based accounting over individual time
tracking. Tracking individuals’ time with time tracking software can
be very time consuming, and the data collected is usually not
accurate. It can be incredibly difficult for team members to track
how they spend their day in today’s modern collaborative team
environments. If the goal is to separate CapEx from OpEx there are
much simpler ways to track this at the team level, such as setting
 reasonable ratios for how time is being spent, rather than individual
timesheets.
9. Automate, automate, automate. As long as someone is typing
financial data into a spreadsheet there is room for greater
automation. In recent years great strides have been made in real-
time financial reporting via business intelligence (BI) technologies
feeding automated dashboards. Particularly important is cash-flow
trend analysis to enable timely, fact-based discussions.
10. Fund three growth horizons. An important focus of your Finance
efforts should be to enable the growth of value streams. Figure 1
depicts the Three Horizon Growth Model, each of which requires its
own approach to finance. Horizon 1 requires an operational
mindset because the value streams in this horizon are mature and
self-funding, requiring financial monitoring and perhaps guidance
when important changes are made. Horizon 2 requires an
entrepreneurial mindset and the value streams here may require
investment funding to enable them to grow into Horizon 1. Value
streams in the Horizon 2 state will require robust financial
governance to keep them on track and in some cases to cull value
streams that do not appear to be working out. Horizon 3 requires a
venture capital mindset, requiring seed funding to initiate new value
streams.
Figure 1. The Three-Horizon Growth Model.
An important observation of the Three-Horizon Growth Model of Figure 1 is
that the time frames for all three horizons are shrinking. The implication is that
you need to prove your value streams of Horizon 3 quicker, ideally via the
Lean Startup-based Exploratory lifecycle. When in Horizon 2 your value
streams need to become self-funding quicker, hence the need for the
continuous delivery lifecycles.
VENDOR MANAGEMENT

Process Blade #7
Disciplined Agile Enterprise (DAE) Layer
Vendor Management
The aim of the Vendor Management process blade,
sometimes called procurement, is to:

 Help source/identify and procure the right

products and services from other organizations.
 To negotiate and then manage contracts with
partner organizations.
 To oversee relationships and partnerships so as
to ensure partner excellence and increase overall
value of partnerships.
 To address the risk associated with external partnerships.
To do this your vendor management team will collaborate with other parts of
the organization to help them understand their needs (if any), identify potential
vendors that can fulfill those needs, and work with Legal to develop
appropriate contracts. Organizationally your vendor management team is part
of, or at least closely related to, your legal team.
There are several reasons why organizations require a Disciplined Agile®
(DA™) approach to vendor management:

1. Complexity and competition are increasing. Simply put, we can't

do it alone anymore.
2. Effective partnering reduces overall risk. Effective vendor
management can help our organizations to reduce risk several
ways. First, we address skills-related and capacity-related risks
through hiring contractors or outsourcing some aspects of our work
to organizations with greater expertise in it. Second, by partnering
with other organizations to bring a new offering to market we
spread the risk of that venture across organizations. Yes, there are
inherent risks to working with partners, risks that are mitigated
through effective governance strategies and adoption of the DA
mindset for vendor management. Third, by purchasing big-ticket or
specialized items via sourcing specialists we reduce the risk of
making inappropriate purchases.
 3. We deliver more, and do so quicker, to our customers. By
working with external organizations we extend our ability to deliver
new or enhanced offerings to our customers, thereby providing
greater value to them. As you see in Figure 1, working with external
partners expands the potential number of people we can
collaborate with.
4. We can expand our market reach and impact. By working with
vendors, either via a customer-supplier relationship or through a
true partnering relationship, we can expand our value streams or
even create new ones. We do this through building more robust
offerings – products and services

Figure 1. The expanding scope of agility.

Vendor Management Mindset
To capture the mindset for effective vendor management, we extend the
principles, promises, and guidelines of the Disciplined Agile® (DA™) mindset
with philosophies.

Figure 1. The Disciplined Agile (DA) mindset for vendor management.

To be effective at vendor management, we embrace these philosophies:

1. Value through partnerships. We increase value through

partnerships with other organizations.
2. Collaborative partnerships. We seek to build collaborative
partnerships with other organizations, even when those
organizations are our competitors or competitors to each other.
3. Mutually beneficial partnerships. We seek to build, maintain, and
evolve mutually beneficial relationships with our suppliers and
partners.
4. We co-create with our partners. We co-create throughout the
entire vendor management life cycle, including procurement. This
 means that we may even have both our own experts and vendor
experts actively involved in the procurement process.
5. We are trusted advisors. We are a trusted advisor inside the
organization to present and guide both supplier and partnering
options.
6. Organizational outcomes come first. We pursue organizational
outcomes over local process conveniences, working in an
enterprise aware manner.
7. We protect our organization. We have a fiduciary responsibility to
protect the organization.
8. We address risk holistically. We address risk in an appropriate,
proactive, and holistic manner.
Vendor Management Roles and
Responsibilities
There are several roles that are pertinent to vendor management. Remember
that these are roles, not positions. Small organizations may have a single
person taking on every one of these roles whereas a large organization could
have dozens of fine-grained positions. Remember, context counts. We define
the following key roles for Disciplined Agile® (DA™) vendor management:

1. Vendor manager. Vendor managers facilitate and maintain

relationships between your organization and vendors/partners,
negotiating contracts, creating standards for the vendors, and
finding the best available vendors. Vendor managers also cultivate
and maintain relationships with vendors, and they have fiduciary
responsibility and signing authority for your organization. Vendor
managers may choose to delegate signing authority to others, and
if so will may impose signing limits and scope.
2. Procurement manager. The procurement manager leads the
procurement team. They hold overall responsibility for the
procurement process from the initial requisition, to selecting
vendors, to negotiations, to invoice payment.
3. Procurement specialist. Procurement specialists perform a suite
of potential tasks: analyzing procurement objectives and needs,
researching the market and assessing the options for meeting the
procurement need, analyzing the cost structure of the vendors’
bids, and seeing to the fulfillment of the agreement. In large
organizations procurement specialists may focus on the
procurement of a certain category of service or product, or on a
certain geographic locale. Procurement specialists report to the
procurement manager and are sometimes called a Purchasing
Agent or Purchasing Clerk.
Vendor Management Workflow – External
Vendor management is an important part of any organization and it plays a
key supporting role for many aspects of your overall organizational
process. Figure 1 depicts the high-level workflow that vendor management is
involved with, showing how your vendor management efforts support teams in
engaging with vendors.

Figure 1. The external workflow of vendor management.

Vendor Management Practices
Some methods or frameworks will choose to prescribe a single approach, but
the Disciplined Agile® (DA™) tool kit instead promotes an adaptive, context-
sensitive strategy. DA does this via its goal-driven approach that indicates the
process decision points you need to consider, a range of techniques or
strategies for you to address each decision point, and the advantages and
disadvantages of each technique. Figure 1 presents the process goal diagram
for the Vendor Management process blade.
Figure 1. The process goal diagram for vendor management.
The process decision points that you need to consider for vendor
management are:

1. Intake requests. How do you prioritize and then manage

procurement requests?
2. Select procurement strategy. Choose the appropriate approach
to procurement given the nature of the potential offerings to be
obtained. Staff are often empowered to make simple, low-risk
purchases at their own discretion, whereas some purchases are
better suited for a traditional approach and very complex purchases
for a lean/agile strategy. Context counts.
3. Identify potential partners. Choose the most appropriate
approach to identifying the potential provider of an offering (service
or product) to partner with. This decision will be driven by the
complexity and uniqueness of the product(s)/service(s) to be
procured as well as the capabilities and capacities of our existing
partners.
4. Identify partner strategy. What is your approach to identify
potential vendor(s) to partner with for a given procurement request?
Do you prefer to work with large vendors that have a broad range
of offerings or smaller vendors with deep expertise in a specialized
area?
5. Select potential partners. The strategy that you choose to select
potential partners to work with will have a significant impact on both
your ability to find a good fit with them and on the relationship you
will have going forward.
6. Choose collaboration model. How will you work with a partner to
fulfill a given agreement?
7. Develop working agreement. What strategy will you apply to
develop a working agreement with a partner(s)? Are you able to
work with them collaboratively, perhaps even with their potential
competitors/partners involved too, or will it be more of a formal
negotiation? The way that you develop the working agreement with
your partner(s) will help set the tone of your relationship moving
forward.
8. Capture working agreement. How will you document a working
agreement, if at all, with a partner(s)? In general, the greater the
 risk involved with the partnership the more robust the
documentation will need to be.
9. Choose commercial model. What approach will you take to pay a
partner for their products or services? The commercial model that
you agree upon will motivate the way that both you and your
partner behaves when you're working together, and will motivate
your willingness to evolve your relationship over time.
10. Grow partner relationship. How will you work with organizations
over time to nurture and grow your partnership? Is your
relationship simply transactional or do you strive to grow your
businesses together?
11. End partner relationship. Eventually all good things come to an
end. There are several different strategies that you can employ to
end a relationship with a partner organization.
12. Govern partners. The collaborations that you have with
vendor/partner organizations need to be governed effectively. This
will include validating that you've received what you've paid for, that
partners are behaving as you expect them to, and monitoring and
acting on your overall risk working with partners.
Vendor Management Strategies
The following strategies enable a Disciplined Agile® approach to working with
partners:

1. Collaborate closely with the actual people you procure

for. Very often the team that requires a product or service to be
procured for them will have a very good understanding of good
options, and sometimes the best option, available. Listen to them,
trust them, and better yet explicitly involve them up-front in the
procurement process.
2. Work with the right vendors. Many organizations make the
mistake of working with a limited number of vendors, often to
simplify procurement. But, if you want the best fit, then you really
need to work with a range of vendors. Larger companies tend to
offer commodity services and products and are often willing to work
with you to gain the specific expertise they are currently missing
(this is called “learning on your dime”). Smaller companies are
more leading edge but may not have the capacity for larger service
engagements or large product orders. Independent contractors are
often experts in a specific topic, providing the expert advice or
service you require but not at the scale that you may need.
3. Build partnerships. When it comes to procured services, vendor
staff will often be a critical part of your value stream. So treat them
as such and embed them as closely as you can. Ideally, the
integration of full-time employees (FTEs) and contractors should be
so good that it’s impossible to identify which company directly
employs a given person on a team. Note that some countries,
particularly the US, have specific laws that limit how you are able to
treat contractors and consultants and may even put an upper limit
on how long they may work for you. With respect to purchased
products, you may choose to co-develop and even co-produce the
offerings with one or more partner firms, sharing the resulting risks
and revenues of doing so.
The following strategies lead to more effective contracting:

1. Prefer context-sensitive contracts. The point is that a

multimillion-dollar services contract will be a bit more detailed than
a contract for two-day workshop. A contract for Agile services
 should reflect how an agile team works whereas a contract for
traditional services should reflect how a traditional team works. Use
the right contract for what you are trying to procure – Context
counts.
2. Beware the extremes. When it comes to comparing vendors
based on cost, which is a questionable strategy at best, our advice
is that the vendors in the middle are often your best option. Our
experience is that lowest bidder will likely produce low quality or will
nickle-and-dime you via their change management strategy
whereas the highest bidder either doesn’t want your business to
begin with, aren’t streamlined in the way that they work and are
thus higher cost, or in some cases really are the very best and
know what they’re worth.
3. Prefer flexible funding contracts over fixed-bid
contracts. Fixed-bid tends to focus on initial price, thus promoting
a lowest-bid mindset which leads to trouble. Systems thinking tells
us to end the practice of awarding business based on price tag and
instead minimize the total cost (or better yet maximize the net value
received). Fixed price contracts tend to be a worst case scenario
for all parties involved.
4. Prefer incremental delivery contracts over big-bang
contracts. The larger the contract, the greater the risk. To remove
that risk, when it's possible, organize a large contract into small
incremental deliverables. You reduce the cost of delay by doing so,
introduce opportunities for learning and adjusting your strategy, and
increase overall transparency (hence improving your ability to
govern the contract).
5. Prefer outcome-based contracts over feature-based
contracts. Just like your internal metrics should be outcome-
focused so should your contracts. There is no guarantee that the
features you defined up front will be what customers want, an
unfortunate outcome of the traditional “big requirements up front
(BRUF)” strategy. Instead define contracts in terms of outcomes –
increased sales, increased customer retention, customer growth,
and so on. Effective contracts define a set of outcomes to achieve,
a set of constraints, and give the team the freedom to work within
that sandbox.
6. Avoid detailed contractual processes. Large amounts of up-front
planning tend to increase risk in complex situations. Worse yet,
 detailed contractual processes tend to favor incumbents and large
service providers (as opposed to the right vendors), they inhibit
transparency (rarely exploring the implications of how a vendor will
provide a service), they are inaccurate (everyone tends to be overly
optimistic), and they usually ignore outcomes in favor of outputs.
7. Monitor fulfillment of contracts. Past performance is critical input
into determining whether to award new work to a vendor, which is a
significant motivator to act as a good partner right now. Just like
regular retrospectives to identify potential improvements works well
for solution delivery teams, the same technique can be applied to
identify how well a contract is being fulfilled and more importantly
how to address any problems you’re currently experiencing.
Vendor Management Terminology
The following terms are pertinent to vendor management:

 Offering. A product, service, or combination thereof.

 Vendor. A vendor is an external organization or person that provides
offerings that are of potential interest to your organization. Also
referred to as a supplier.
 Partner. A vendor with which you currently have a relationship with.
 Vendor management. The goal of vendor management is to help
source/identify and procure the right offerings from vendors; to
negotiate and then manage contracts with partner organizations; to
oversee relationships and partnerships to ensure partner excellence
and increase overall value of partnerships; and to address the risk
associated with external partnerships.
 Sourcing. Sourcing is that act of identify the potential source(s) of
an offering, evaluating the choice(s), and choosing the best fit for
your organization. Sourcing is an aspect of procurement.
 Procurement. The act of sourcing, developing an agreement with,
and potentially purchasing offerings from vendors.
LEGAL

Process Blade #8
Disciplined Agile Enterprise (DAE) Layer
Legal
The aim of your Legal processes is to ensure that
your organization works within the parameters of the
law of any legal territory in which you operate. Your
legal team will work closely with your procurement
people, in many organizations Procurement is part of
your overall legal efforts, on (Agile) contracts. They
will also assist your people management team to
ensure that their strategies reflect the local statutes
and with your marketing team to guide what they’re
legally able to promise.
There is a very wide range of activities that your legal team will be involved
with:

1. Guide intellectual property (IP) management. This includes the

creation of patents, the filing of copyrights, and helping to navigate
the international issues pertaining to such.
2. Assist with organizational evolution. In addition to organic
evolution by creating and growing value streams, organizations
may choose to evolve through merging with other organizations,
acquiring other organizations, and selling portions of themselves
that no longer fit in their enterprise portfolio. All of these activities
require significant legal work.
3. Provide legal guidance to others. Your legal staff will regularly
help teams and people within your organization to understand and
navigate regulations in a pragmatic manner. They will also help to
educate people in fundamental legal and ethical issues to enable
them to make better-informed decisions.
4. Automate legal bureaucracy. A 2016 study by Deloitteclaims that
artificial intelligence (AI) technologies are now being applied to
automate a significant portion of legal work. Increased automation
help your legal team to Optimize Flow and to focus on leadership
and coaching activities.
5. Monitor the regulatory environment. Your legal team will actively
monitor the environment for new regulations and changes to
 existing regulations. They will work closely with your Control efforts
to help keep them abreast of changes.
6. Collaborate with regulators. Large companies frequently work
with regulators and legislators to explain their intentions and clear
the way for work they want to do.
RESEARCH AND DEVELOPMENT

Process Blade #9
Value Stream Layer works with DAE Layer
Research & Development
The aim of the research & development (R&D)
process blade is to support innovation and the
exploration of potential new or improved products
and services (offerings) within an organization. R&D
is sometimes called research and technological
development (RTD) or simply research. R&D typically
focuses on monitoring the market for, identifying, and
experimenting with potential innovations. These
innovations may include new offerings to bring to
your customers, new technologies to work with, new ways of working (WoW),
and new ways of thinking.
There are several reasons why organizations need a Disciplined Agile®
approach to R&D:

1. Improved market innovation. One aim of R&D should be to

identify potential new offerings to delight your customers, working
closely with your strategy and product management groups to do
so. Successful new offerings enable your organization to gain and
retain competitive advantage.
2. Process innovation. R&D should also look for opportunities to
improve existing ways of working (WoW) within your organization.
This could be through physical process automation/robotics. It may
also be via virtual process automation through better software-
based systems, such as artificial intelligence (AI), machine
learning, and cloud-based services.
3. Better strategic decisions. Effective R&D efforts will provide
powerful knowledge and insight for your strategy, product
management, enterprise architecture efforts and other areas. This
supports the long-term success of your organization.
4. Improved trend matching. Other organizations are innovating too,
and sometimes you find that you’re a follower and not a leader.
R&D can help you to catch up and better yet exceed the
competition, thereby closing a competitive disadvantage.
This process blade is part of the Value Streams and Disciplined Agile
Enterprise (DAE) layers.
Research & Development Workflow –
External
Research & development (R&D) is an important endeavor within most
organizations, exploring ideas and technologies from a wide range of sources
to identify potential new innovations to be applied within your organization.
Figure 1 depicts the high-level workflow that R&D is involved with.

Figure 1. The external workflow of Research & Development.

BUSINESS OPERATIONS

Process Blade #10

Value Stream Layer works with DAE Layer
Business Operations
Business operations is one of the process blades
of Disciplined DevOps and Disciplined Agile®
Enterprise (DAE). The Business Operations process
blade focuses on the activities required to provide
services to customers and to support your products.
The implementation of business operations will vary
by value stream, in a bank retail account services is
implemented in a very different manner than
brokerage services for example. Business operations
includes help desk and support services (integrated in with IT
support where appropriate) as well as any technical sales support
activities such as training, product installation, and product
customization. As you can imagine close collaboration with both
your Sales and Marketing efforts is required to successfully Delight
Customers.
STRATEGY

Process Blade #11

Value Stream Layer works with DAE Layer
Strategy
The aim of the strategy process blade is to support strategic planning, to
provide strategic leadership to your organization, and to provide oversight of
your overall strategy. Strategic planning is what you hope you are going to do,
whereas strategy is what you actually do.
Your strategy efforts will focus on both the organizational level for overall
vision and at the value stream level to ensure success for each specific
endeavor, as we show in Figure 1. Your enterprise strategy will influence and
guide the strategies for each of the value streams supported by your
organization, and the value stream strategies will provide feedback up to the
enterprise.

Figure 1. Strategy occurs at multiple levels within your organization.

There are several reasons why organizations need a Disciplined Agile®
approach to strategy:

1. To decrease ambiguity. An important aspect of strategy is the

identification, evolution, and communication of an overall guiding
vision. This vision addresses questions such as: What is your
purpose? Where are you going? What do you not do? What are
your values? What outcomes do you hope to achieve? How do
the various components of your organization fit together?
2. To reduce overall volatility. Your organization likely offers a
portfolio of value streams to your customers. You do this to serve
your customers well, and ideally to delight them. You also want to
generate a consistent, and hopefully growing, stream of revenue so
as to fund your enterprise. The strategy of having a portfolio of
value streams, and in many cases a portfolio of offerings within
each value stream, reduces your overall business volatility.
3. To address uncertainty. Leadership within your organization, and
your value streams, will guide and monitor the execution of your
strategy. They will continuously explore issues such as what is
actually being achieved, what is happening in the marketplace,
what we need to do better, and many more. Answers to these
questions will provide insights that both reduce your operational
uncertainty and motivate changes to your strategy to better target
the needs of your customers.
4. To handle complexity. Complexity is inherent in everything that
our organizations do. One important aspect of our strategy is to
reduce complexity whenever we can, a primary aim of
our continuous improvement efforts. A second aim is to embrace
the complexity we have and find ways to work with it and turn this
ability into a competitive advantage for our organization. Arguably
the purpose of value stream management is both to improve our
own ability to deal with complexity as well as address the
complexities our customers face in a better way than they
themselves are capable of addressing.
In short, a DA™ approach to strategy enables organizations to continuously
address volatility, uncertainty, complexity, and ambiguity (VUCA).
This process blade is part of the Value Streams and Disciplined Agile
Enterprise (DAE) layers.
Strategy Workflow – External
Strategy is an important part of any organization. Figure 1 depicts the high-
level workflow that strategy is involved with, showing how it provides vision
and direction to critical components of your organization.

Figure 1. The external workflow of strategy.

GOVERNANCE

Process Blade #12

Value Stream Layer works with DAE Layer
Governance
Your governance team - which may be called an
oversight, audit, or control
team/tribe/group/function - will monitor and guide
teams throughout your organization. The aim is to
enable them to succeed by removing or at least
reducing any barriers that they may experience, to
motivate them to do “the right thing” for your
organization and your customers, and to ensure
that they remain compliant with appropriate legal
regulations and guidance.
Governance typically addresses areas such as:

 The evolution and support of roles and responsibilities to streamline

how people work together
 Definition of decision rights and decision-making processes to
streamline interactions between people
 The evolution and support of common procedures and guidelines to
ensure appropriate commonality of activities and artifacts
 The evolution and support of common guidance to motivate the
efforts of teams across your organization
 Promotion of ethics and social responsibility
 Effective and timely investment to sustain and extend the
organization over the long term
 The monitoring of activities to provide insight into their effectiveness
 Formation of a governing body that is responsible for guiding
governance activities
 Definition of exceptions and escalation processes to streamline
critical interactions
 Creation of a knowledge sharing strategy to grow individuals, teams,
and the organization as a whole
 The support and monitoring of risk mitigation strategies across your
organization
  Adoption of a reward and compensation structure to support the
attraction and retention of excellent staff
 Strategies to share information throughout the organization
Disciplined Agile® (DA™) promotes a lean approach to governance. Lean
governance is the leadership, organizational structures and streamlined
processes to enable everyone to work together effectively in sustaining and
extending the organization’s ability to produce meaningful value for its
customers. There are several reasons why a lean governance strategy is
important for your organization’s success. Lean governance strives to ensure
that:

1. Your organization’s investment is spent wisely. Organizations

make investments in their people, in their infrastructure, and in their
processes to enable them to better serve their customers (or in the
case of government agencies, their citizens). From a financial point
of view, your goals should be to regularly and consistently create
real business value and to provide appropriate return on investment
(ROI). To do this you must determine how you will execute your
strategy by selecting and prioritizing the most valuable initiatives to
undertake. You must also monitor these initiatives to ensure that
they fulfill their promise, and if not then remediate them
appropriately.
2. Your teams are empowered to carry out their work. An
important aspect of lean governance is to ensure that people and
teams have the authority to fulfill their responsibilities. Many agile
transformations run into trouble when the roles and responsibilities
of people are not agreed upon, or when they are they are not
properly supported by senior management. Another important
strategy is to empower teams to choose their own way of working
(WoW), to self-determine how they will work together, enabling
them to tailor their approach to meet the needs of the situation that
they face.
3. People are motivated to work together effectively. There are
two aspects to this. First, teams need to work effectively with their
stakeholders. Second, teams also need to work effectively with
their colleagues. To do this you must adopt processes and
organizational structures that encourage people to collaborate
together and to learn from one another.
 4. Risks are monitored and mitigated at appropriate
organizational levels. Although addressing risk at the team-
level is a good start it isn’t sufficient from an organizational point of
view. Many small risks that are acceptable individually can add up
to a very large risk for your organization. For example, one team
using a new technology platform is an experiment. Fifty teams
adopting that new platform at the same time is a significant risk if
the platform proves to be problematic. Someone must be looking at
risks from a portfolio perspective and guide teams accordingly.
5. Your organizational ecosystem is sound. Your organization isn’t
just a collection of teams. It is an ecosystem of teams working
together, supported by culture, ways of working, organizational
structures, and technologies. All aspects of your ecosystem need to
be healthy for your organization to thrive.
6. Everyone works in an open and collaborative manner. There
are several ways that the DA™ tool kit promotes this. First, work is
performed in an agile manner that is inherently open and
collaborative. Second, all teams should present accurate and timely
information to their stakeholders. For example, enterprise architects
can make their work available to everyone, as can your portfolio
management team, your data management team, and so on. Third,
everyone should be motivated to learn more about your
organization, its strategy, its values, and how you intend to work
together to achieve the outcomes you’ve set out for yourselves.
7. All of these things will continue to be true now and in the
future. Lean governance balances your short-term and long-term
needs. Too many organizations have allowed technical debt to
grow in recent years, for the skills of their staff to stagnate, and to
continue to tolerate traditional strategies that are well past their
prime.
There are two fundamental reasons why individuals should be interested in
lean governance:

1. You’re being governed, like it or not. Regardless of the size or

your organization, the length of time it’s been in operation, or the
sector(s) in which you work, someone is keeping an eye on and
guiding your overall efforts.
2. You deserve to be governed effectively. Sadly, many
governance strategies prove to be ineffective in practice due to
application of traditional strategies and ways of thinking.
Governance Mindset
The mindset required to govern in a lean manner is very different than the
traditional mindset. The following are key aspects of a lean governance
mindset:

1. Holistic governance. You want to enable lean, appropriate

governance across all aspects of your organization. Rather than
addressing individual functional governance areas, such as security
governance, data governance, financial governance, and others
separately you instead want to address them holistically. When
you address governance areas separately the individual
governance strategies may be inconsistent and at odds with one
another and they very often prove to be overly burdensome in total.
Furthermore, the way that you govern an individual team or group
must reflect their way of working (WoW) – an agile team should be
governed in an agile manner, a serial team in a serial manner, and
so on.
2. Short- and long-term balance. Governance must balance short-
term needs of enabling teams to achieve their outcomes with the
long-term strategy of growing, enhancing, and protecting your
organization.
3. Protect the organization. An important aim of governance is to
keep your organization safe, to address enterprise risks effectively.
4. Motivation over management. Many of the people working for
your organization are intellectual or highly-skilled workers, and as
such generally don’t respond well to being told what to do. But they
can be motivated, and once motivated will actively work on what
they’ve been motivated to do. An aim of lean governance is to
motivate people to do the “right thing”. One way to do this is to
communicate very clearly what your organization is trying to
achieve. Another way to motivate people is to ask tough questions
such as: What value is there in doing that? What can we do to
increase value? How can we eliminate waste in what we’re doing?
and What will we learn by doing that?
5. Enablement over audit. Psychology shows that people, when
given the choice, will usually take the easy path. This tells us that if
we want people to do something, or to work in a given manner,
 then if we make it very easy to do so then they likely will. For
example, if you want software developers to follow common coding
conventions then provide easy to understand and straightforward
guidelines. Better yet, provide code analysis tools that they can
include in the continuous integration (CI) tooling that provides
feedback that they can act on. The traditional approach would be to
rely on code inspections or code audits to ensure that conventions
were being followed. This approach is not onerous and thus less
likely to be followed. Yes, you may still need to run the occasional
audit, particularly when you’re working in a regulatory environment,
but you should do so only as a last resort.
6. Trust but verify. Agile is based on trust, but you still need to verify
that the right thing is happening within your organization.
Verification is enabled via radical transparency, which is the result
of the DA™ mindset promise “Make all work and workflow visible.”
7. Enable continual improvement.
Governance Work Flow – Internal
Your governance team - which may be called an oversight, audit, or control
team/tribe/group/function - will monitor and guide teams throughout your
organization. The goal is to enable them to succeed by removing or at least
reducing any barriers that they may experience, to motivate them to do “the
right thing” for your organization and your customers, and to ensure that they
remain compliant with appropriate legal regulations and guidance. To
accomplish this your governance team will:

 Coordinate organizational governance efforts. In short, someone

needs to govern the governors to ensure that
your architectural governance, financial governance, people
management/human resource (HR) governance
strategies, security governance, and others are consistent, coherent,
and pragmatic.
 Identify mandatory regulations. Your governance team will work
closely with Legal to identify applicable industry regulations. Note
that regulations will vary by geographic territory and will evolve over
time, so be prepared to do this work on an ongoing basis.
 Identify voluntary regulations. Your organization may choose to
willingly adopt Capability Maturity Model Integration
(CMMI) guidance and even some of the International Organization
for Standardization (ISO) regulations due to marketing reasons.
Many customer organizations will only do business with companies
who are compliant with certain industry regulations, insisting that
their vendors are ISO 9003 or CMMI-3 compliant for example.
 Facilitate the development of compliancy strategies. A key to the
DA™ governance process blade is that your governance team
actively collaborates with the target audience to evolve your
enterprise guidance, it doesn’t dictate procedures from their ivory
tower.
 Ensure regulatory compliancy. This should be kept as streamlined
as possible. A significant portion of regulatory compliancy can often
be automated, particularly in the software/IT realm. For example,
automated regression testing often satisfies verification
requirements; a combination of behavior-driven development (BDD)
and test-driven development (TDD) provide traceability from
 requirements to design to code to tests; and continuous deployment
(CD) strategies can provide evidence of separation of concerns.
 Educate people in compliance. An important enabler of
compliance is the education and coaching of people so that they
understand the compliancy strategy in the first place.
 Run internal audits. The control team will be responsible for
running internal audits to ensure compliancy, the goal being to
ensure that a value stream or even a corporate division will pass an
external audit.
Governance Practices

The following process goal diagram overviews the potential activities

associated with a disciplined approach to governance. These activities are
typically performed by a variety of people within your organization. In the
Disciplined Agile (DA) tool kit each of the process blades includes activities
around governing the activities encapsulated by that blade. For example,
the Enterprise Architecture blade includes architectural governance activities
and the Data Management blade includes data/information governance
activities.
Figure 1. The process goal diagram for governance.
The process decision points that you need to consider for governance are:

1. Coordinate governance views. There are many individual

functional governance area, including financial governance,
security governance, data governance, IT governance, and more.
Too many organizations make the mistake of treating each of these
issues separately, which is easy enough to do given the different
focus of each one. The DA tool kit promotes a more holistic,
integrated view that results in a streamlined, consistent, and
effective governance strategy.
2. Guide measurement program. Metrics identify the measurements
that you will take to gain insight into what has happened, what is
happening, and hopefully what may happen in the future. The least
effective approach to metrics is to have a standard set that all
teams are expected to collect whereas the most effective is a
context-sensitive approach such as an agile implementation of goal
question metric (GQM). The measures themselves can be collected
either manually or automatically (usually as the result of tool or
system usage). We have found that a combination of the two is
required—although automated metrics are inexpensive, accurate,
and real-time you cannot always automate all of the measurements
that you need to collect.
3. Govern governance. If your governance efforts aren’t being
governed, how do you know whether they’re effective? Or worst
yet, are they causing more harm than good? In DA we believe that
all aspects of your organization should be well governed, including
your governance efforts.
4. Monitor teams. Information radiators and visual controls are
sufficient in smaller organizations, but automated dashboards in
combination with direct interaction with teams are also needed in
modern enterprises. Traditional strategies, such as status reports
or status meetings, do not prove to be effective in practice nor do
they always provide an honest assessment of what is actually
occurring.
5. Develop guidance. An easy and important way to support
governance within your organization is to have commonly accepted
guidance, including standards and guidelines, for teams to follow.
Guidance is ideally developed collaboratively with a combination of
practitioners and experienced enterprise professionals who
 understand the bigger picture. Guidance should be written so that it
defines enabling constraints wherever possible.
6. Document guidance. We suggest that you keep this guidance
concise and consumable, starting with high-level rules but aiming
towards principles whenever possible.
7. Define roles and responsibilities. The definition of roles and
responsibilities is an important aspect of your overall governance
strategy as they describe what is expected of people. The DA tool
kit describes general team-level roles and responsibilities as well
as specialized ones that are specific to a given process blade.
8. Address enterprise risk. Small risks on individual teams can add
up to a large risk across your organization. For example, if many
teams adopt a new and relatively unproven technology and that
technology is then abandoned by its creators then you have a
serious problem. Similarly, when multiple teams start addressing a
similar business opportunity and that line of business dries up or is
legislated away you have a serious problem. Although risk is
addressed at the team level via the Address Risk process goal, the
focus here is on organization-level risk.
Leading Lean Governance
There are many behaviors and that leaders may choose to adopt to enable
successful governance:

1. Lead by example. People take their cues from their leadership

teams. If your governance strategy is streamlined then whatever it
governs will inevitably become streamlined. Conversely, an
onerous and heavy governance strategy will lead to onerous and
heavy strategies by those being governed.
2. Be a servant leader. The primary function of governance people
should be to prevent roadblocks, and better yet to eradicate them
as soon as they arise. You should strive to get teams the resources
that they need and then get out of the way. Wait a minute, isn’t that
the job of the Team Lead on a Disciplined Agile® team? Yes, but
who do you think that they work with to actually get that done?
3. Be a great host. People who have fun at work, who enjoy what
they do, are much more productive than people who don’t. In this
respect being an effective governor is like being a good host at a
party — as host it’s your job to see that everyone has a good time
and gets along well with each other, and to swiftly deal with any
problems that arise.
4. Learn continually. Good governors learn as much as they can
about what they’re governing so that they can make better
decisions and can make effective suggestions to the people being
governed.
5. Communicate continually. Effective governors communicate what
the priorities of your organization are and what is expected of
people. It is crucial to set realistic expectations in an open, honest,
consistent, and regular manner.
6. Streamline collaboration. Governors should help teams
collaborate effectively with others. This not only helps them to
achieve their goals but also supports enterprise awareness.
7. Ensure personal safety and experimentation. Senior leadership
needs to promote a “can do” and “no blame” culture where it is not
only safe but highly desirable to learn via experimentation. Senior
 leadership should be there to help when things don’t work out and
to celebrate the learnings from both successes and failures. Create
psychological safety and ensure diversity is an important promise
of the DA™ Mindset.
8. Promote self-organizing teams. Senior leadership should push
decision making authority down to the execution level, with teams
being responsible for customer outcomes. An implication is that
teams need fast access to resources and must be able to grow or
shrink as needed, with senior leadership playing an enabling role in
doing so. In a DAE, teams are not only allowed to self-organize
they are pushed to do so. Leaders should challenge local strategies
and plans, motivating teams to improve and excel and to ensure
risks are properly considered. Create semi-autonomous self-
organizing teams is one of the guidelines of the DA Mindset.
9. Prefer guidelines over edicts. Plans and procedures don’t hold
organizations together – clear purpose and values do. People are
not going to read detailed procedures, and even if they do it’s
unlikely that they will follow them to the letter. With self-organizing
teams, leaders may fear that teams will get creative in some way
and cause trouble, and to ease that fear you need to create clear
and pragmatic guidelines within which people should operate.
10. Create sandboxes. Sandboxes are safe places for people to
play, that have clear and reasonable boundaries within which
teams can operate. Because sandbox boundaries can be hard to
anticipate you will find that teams will often stumble across a
prohibition or across another team’s boundary and will then have to
work through what the boundaries and interfaces actually are.
11. Mission command over rigid instructions. There is a style of
military leadership called “mission command” that defines the
operational goals that a team is to achieve and then puts as much
responsibility and authority into the hands of the team as possible.
Mission command is based on several principles: Do not command
more than necessary, or plan beyond foreseeable circumstances;
Communicate to every team as much of the higher intent as is
necessary to achieve the purpose; and ensure that everyone
retains freedom of decision within bounds (their sandboxes).
12. Collect actionable metrics. A good metric provides insight, it
motivates you to change your behavior. If you don’t use a metric to
 improve or make better decisions then it is a vanity metric and
therefore overhead. BUT, at the same time you can’t manage
solely by the numbers. Instead use metrics to identify where you
need to have conversations about what is(n’t) happening. Adopt
measures to improve outcomes is a guideline of the DA Mindset.
13. Prefer real-time automated intelligence. The real goal of course
is self-service business intelligence (BI) where you can quickly
identify emerging trends, make predictions, and take prompt action
in an informed manner. Effective BI can also provide an “early
warning” strategy for identifying potential marketplace changes. Will
you always get it right? No, but you will make better decisions more
often than if you didn’t have BI. An important nuance is that the
purpose of measurement is to reduce uncertainty, it isn’t to gain
certainty.
14. Measure customer outcomes. A DAE measures outcomes, not
outputs, because you cannot guide effectively without confronting
the facts. Potential measures such as total customer profitability,
cycle time, attrition, and market share are all outcome based.
Because it is difficult to forecast accurately, your predictive metrics
should be quoted in ranges that reflect the uncertainty of the base
data.
15. Manage for throughput, not utilization. As Tom DeMarco
recommends in his book Slack, if you want to maximize the
throughput of a team (and thereby reduce time to respond to
opportunities) you need to have slack time built into the way that
you work. When people are fully utilized they are more likely to
become bottlenecks for the people they are supposed to
collaborate with, and they have no capacity to quickly respond to a
new opportunity when it arises. The DA principles are to Optimize
Flow and Be Awesome, not Fully Utilize Staff and Be Busy.
16. Transparency for everyone enables control. Allowing everyone
to see the same information at the same time will enable people to
ask the right questions and make the right decisions. This includes
giving people access to strategic, competitive, and market
information that would have only been available to executives in
traditional organizations. How can keeping people ignorant be a
good idea? Furthermore, keep numbers in their raw state – when
you “fudge them” or modify them to look good you reduce the
opportunity to have open and honest discussions about what is
 really going on. The good news is that when everyone sees the
numbers at the same time there is little opportunity for people to
fudge the numbers. Make all work and workflow visible is
a principle of the DA Mindset.
17. Provide audit guidance to teams. People fear being audited,
rightly or wrongly. Although audits can be a great learning
opportunity for teams to identify where they’ve missed addressing
important risks this is often overshadowed by the threat that they
will get in trouble and may even be punished. A Disciplined Agile
governance team will provide pragmatic advice to teams about
what they need to do to pass audits, ideally providing real-world
examples of how teams passed audits within your organization in
the past.
18. Govern by exception. Executives should look for exceptions or
unusual patterns and trends that might reflect changes in customer
behavior or poor behavior on the part of teams.
Strategies that Support Lean Governance
The Disciplined Agile® (DA™) tool kit supports a wide range of “governance
friendly” strategies, which include:

1. Empowered teams. Teams should have both the authority and

responsibility to fulfill their mission. Agile teams should be allowed
to be self-organizing, the implication being that the team itself
determines who will do what work (the team doesn’t have a
manager telling them what to do). Any of course, teams should be
enabled to choose their own way of working (WoW).
2. Enterprise awareness. One of the principles of the Disciplined
Agile (DA) toolkit is that you should work in an enterprise
aware manner. It is based on the observation that your team is only
one of many teams, so therefore you need to consider the bigger
picture when you’re working and do what is best for your
organization, not just what is convenient for you. Promoting
enterprise awareness throughout your organization is a
fundamental enabler of lean governance.
3. High-level roadmaps. High-level architecture and product
roadmaps, produced by your Enterprise Architecture and Product
Management efforts respectively, will provide important guidance to
your teams. These roadmaps capture the vision as to where your
organization is heading, helping teams to understand what the
overall vision is, to focus on what is important to your organization,
and to help guide and constrain their decisions.
4. Collaborative professionals. Many process blades are focused
on providing services and guidance to other teams. This includes
process blades such as Vendor Management, Security, Strategy,
People Management, Asset Management, Finance, and of course
Governance. The enterprise professionals performing these
activities should work closely with their customers, who are typically
teams and individuals within your organization, in a collaborative
and evolutionary manner. This promotes better governance for two
reasons. First, by getting the vision, knowledge, and skills of the
enterprise professionals into the hands of their customers it
increases the chance that they work in a manner that is consistent
to the needs of your organization. Second, the enterprise
 professionals want to get feedback from their customers and learn
more about what their customers need from them. This enables
them to be more effective at serving the enterprise and guiding
their customers.
5. Enterprise knowledge in teams. Although roadmaps and
enterprise professionals collaborating with other teams help, it is far
more effective to have people with enterprise knowledge
embedded within the teams. This is why we promote the idea
that Architecture Owners (AOs) should not only work closely with
the enterprise architects but should preferably be a member of the
EA team. Similarly, Product Owners (POs) should either work
closely with the product management group or preferably be a
member of that group. And it’s possible to do better than that — if
team members are truly enterprise aware and are continuous
learners, then it is reasonable to expect them to pick up enterprise
knowledge over time. The more knowledgeable people are about
their organization and its goals the less supervision/governance
they will need.
6. Automated dashboards. Automated dashboards are a scalable
form of information radiator. With just a bit of work you can take the
information being generated by your tools and, using business
intelligence (BI) technologies, populate team and even portfolio
dashboards in real time. These dashboards provide important
information that teams can use to manage themselves as well as
governors to monitor what is happening within your organization.
This enhances governance because when you get better quality
information into people’s hands and they are more likely make
better decisions.
7. Defined roles and responsibilities. Defined roles and
responsibilities help people to understand who does what, what are
they are responsible for and when they need to collaborate with
others. This is an important aspect of governance because critical
guidance about how people will need to interact with one another.
8. Defined organizational structure. You may choose to have a
hierarchy of teams, a network of teams, a collection of circles
(along the lines of holocracy), or combinations thereof. This is
important to your governance efforts because people need to know
what teams exist and how do they interrelate within your
organization.
9. Common guidance. Guidance—standards and guidelines—is
important to your governance effort because it helps people to
understand how they can develop consistent assets which in turn
are easier to understand and evolve. This guidance should be
straightforward, ideally be supported through automation, and
collaboratively developed.
10. Governance team. People, typically senior leaders, are
responsible for governance. The team, who is on it and what they
do, should be defined and publicly known by those being governed.
Everyone knows who the governors are and what they do, so that
your governance strategy is open and transparent.
11. Risk-based milestones. A risk-based milestone is a point in time
where you determine whether a team has addressed a specific risk,
for example have they achieved stakeholder agreement around the
scope of a project, have the proven that their architectural strategy
works, or whether they’ve shown developed sufficient functionality
to deploy to their customers. This differs from an artifact-based
milestone where you determine whether a team has appropriately
produced a specific artifact, such as a scope document, an
architecture model, or test results. Risk-based milestones ensure
that the team has addressed risk, artifact-based milestones verify
that an artifact has been created, reviewed, and accepted. This is a
very important nuance.
MARKETING

Process Blade #13

Value Stream Layer works with DAE Layer
Marketing
Marketing is a process blade of a Disciplined Agile
Enterprise (DAE). The raison d’être for Marketing,
sometimes called brand management, is to ensure
successful interactions between your organization
and the outside world. Your Marketing efforts will
represent your organization and your offerings,
both products and services, to the outside world
and conversely will represent customers, and
potential customers, to the rest of the
organization. In conjunction with Product
Management, Marketing will be actively involved
with long-term visioning for your organization’s offerings.
A good definition of Agile Marketing comes from McKinsey – “[Agile
marketing] means using data and analytics to continuously source promising
opportunities or solutions to problems in real time, deploying tests quickly,
evaluating the results, and rapidly iterating. At scale, a high-functioning agile
marketing organization can run hundreds of campaigns simultaneously and
multiple new ideas every week.” The Agile Marketing Manifesto, first
developed in 2012, also provides significant insights about how to apply an
agile approach to your marketing efforts. This includes taking a validated
learning approach, being customer focused, working in a collaborative and
flexible manner, and working in an evolutionary (iterative and incremental)
manner.
Marketing Strategies
Our experience from working with dozens of organizations worldwide is that
Marketing by its very nature tends to be agile and that most organizations find
they just need to make a few improvements to their current approach. These
changes potentially include:

1. Sell the sizzle, not the steak. This is an old marketing adage that
is particularly pertinent for DAEs. You want to move away from
marketing products and features, both of which may have very
short lifecycles in today’s marketplace, and towards campaigns
built on brand and the benefits provided by your offerings. For
example, many car advertisements on television focus on how you
can get out into the wilderness and enjoy life, or go to the beach to
surf, or go out with your friends. They may tell you a few key facts
such as gas mileage or horsepower, but they never go into details
about the gearing of the transmission, the size of the gas tank, or
the cleaning capability of the windshield wipers.
2. Prefer marketplace experiments over focus groups. Taking a
validated learning approach with test campaigns and then
quantifying the impact has been common practice within marketing
for years. Your goal is to use sophisticated experiments to measure
the overall impact of your marketing strategies and then apply
these insights to improving both your offerings and the marketing of
those offerings.
3. Market marketing. Many marketing teams find that they need to
market themselves to the rest of the organization, particularly to the
delivery teams to whom marketers are a key stakeholder. Your
marketing efforts must be fully integrated into the value stream
teams that they support.
4. Customer discovery over static prediction. This is one of the
values of the Agile Marketing Manifesto, promoting the observation
that you must observe and interact with your (potential) customers
to determine what they want. Traditional marketing strategies
involve far too much detailed guessing or prediction of what people
want, increasing both the cost of delay and the risk of missing the
mark entirely.
5. Gain insights through targeted analytics. In addition to the
insights provided by validated learning you also want to leverage
the wealth of information provided by analytics. You want to
integrate data generated in-house with acquired data from external
sources (often the result of “big data” analytics). The aim of these
insights should be to identify anomalies, pain points, issues, or
customer opportunities. Better yet, use predictive analytics to
identify the potentially most profitable customers through analysis
of the lifecycle of customer purchases and behavior. It’s important
to note that your existing marketing campaigns, such as your
loyalty program, can be important sources of data. Similarly,
marketing via social media platforms such as Facebook and
LinkedIn will also produce a wealth of information about customer
behaviors.
6. Provide stakeholders to solution delivery teams. Your
marketing team can be a critical source of stakeholders for solution
delivery teams, including themselves, actual customers, and
perhaps even potential customers. Active stakeholder
participation is vital to the success of your value streams.
CONTINUOUS IMPROVEMENT

Process Blade #14

Value Stream Layer works with DAE Layer
Continuous Improvement
The purpose of the Continuous Improvement process
blade is to enable people within your organization to
easily share their improvement learnings with one
another in a systematic way.
There are several reasons why you want to have a
continuous improvement program within your
organization:

 Shorten the time from idea to implementation. Improvement

ideas can come from anyone, at any time, from anywhere in your
organization. As a result, you want to have organizational
mechanisms to identify and explore those ideas so that they get to
the person(s) most suitable to implement them quickly.
 Increase skills and knowledge sharing. The high-collaboration
environments that are typical of agile teams are wonderful for
sharing skills and knowledge within each team, but fellow team
members aren’t the only people within your organization that you can
learn from. An important goal of a continuous improvement program
is to motivate and enable people to share their skills and knowledge
outside of their immediate team. You can do this through strategies
such as communities of practice, online discussion forums,
practitioner presentations and many others.
 Maximize your “failure ROI.” A fundamental of lean thinking is to
learn from your failures, to treat each “failure” as an opportunity to
improve. Having said that, every team doesn’t need to experience all
of the same failures. One team, or a handful of teams in some
cases, can fail in similar ways and then share those learnings with
others. This way other teams can avoid that type of failure and
thereby increase the value of the learnings to your organization. But
we can only do that when it’s safe to fail and better yet recognize
that failures should be celebrated and the learnings shared with
others.
 Increase the opportunity for radical improvements. The
challenge with the Japanese concept of kaizen, which is to
 continuously make small incremental improvements, is that you can
get on an improvement path that will never lead to a quantum leap in
your process. Yes, things are getting better, but you may be missing
opportunities to make things a lot better. For example, a team
following the Agile lifecycle may never identify the strategy of
continuous deployment (CD) on their own because having a two-
week iteration may preclude the idea of releasing several times a
day into production. Yet, if people on your team were to hear about
other teams in your organization working that way, they might soon
choose to start experimenting with CD techniques. This in turn could
lead to the “radical” process improvement of abandoning the idea of
time-boxed iterations and moving to something much closer to
DA’s Continuous Delivery: Lean lifecycle.
In short, your organization needs a strategy for communicating potential
improvements across teams. Ideally the flow of work should be streamlined to
make it as easy as possible for teams to learn from one another.
Continuous Improvement Practices
The following process goal diagram overviews the potential activities
associated with disciplined agile continuous improvement. These activities
may be performed by, or at least supported by, a process improvement team.
Some of these practices will be performed by Centers of Excellence
(CoEs) and supported by your Communities of Practice (CoPs) (if any).
Figure 1. The process goal diagram for Continuous Improvement (click on image
to expand).
The process decision points that you need to consider for continuous
improvement are:

 Identify improvements. There are several ways that your process

improvement group can support the identify of potential
improvements within your organization. One of the more effective
strategies is to help teams adopt the practice of holding regular
retrospectives. Although it is common for disciplined agile delivery
teams to hold retrospectives this is often a new concept for
enterprise architecture teams, governance teams, data management
teams, and so on. We also get very good traction with value stream
mapping and brainstorming sessions, which invariably proves to be
far more effective than the traditional approach of creating current
and proposed (business) process models that rarely seem to result
in lasting acceptance of the proposed new way of working.
 Share improvements. As you can see there are multiple ways that
you can share improvement ideas between teams, many of them
being free or at least very inexpensive to implement. We’ve had very
 good experiences with internal discussion forums, practitioner
presentations (often called lunch and learns) where someone
presents their learnings to others, lean coffee sessions where people
voluntarily meet at a regular time to share ideas, and communities of
practice (sometimes called guilds) who purposely collaborate to
educate themselves in a given topic.
 Capture improvements. There are various ways that identified
improvements may be captured to retain them over time. Possible
strategies include describing each learning in a document and then
managing that document in a documentation repository or more
simply in a shared folder; capturing the learnings in a shared wiki;
describing your evolving process using a process repository; or via
an expert system.
 Support teams. Your process improvement team can help others to
adopt process improvement techniques through training, education,
and coaching. They can also facilitate team assessments and
retrospectives (a great idea is to co-facilitate a few retrospectives
with someone on the team to transfer those skills to them). A very
effective strategy is to help a team run a process improvement
experiment or two, particularly in situations where the team isn’t
being supported by a coach. This helps them see that they can
safely try new ideas within their environment for a few iterations to
determine whether it works for them or not. Many teams, particularly
those new to agile, often do not feel empowered to run such
experiments and thus need help to do so.
 Organize Communities of Practice (CoPs)/Guilds. A Community
of Practice (CoP), or Guild, is a collection of people who share a
craft or profession who have banded together to ‘learn’ from each
other to develop themselves and often even the organization. We’ve
seen CoPs for testing, architecture, agile/lean, business analysis,
technical debt, and many others. CoPs will often perform the
activities called out by the Identify Improvements, Share
Improvements, Capture Improvements, and Support Teams process
decision points. A CoP will often start up when one or more
practitioners within your organization recognize the need for it,
although sometimes it may also start to support the efforts of a
corresponding Center of Excellence (CoE). Participation in a CoP is
typically voluntary.
 Organize Centers of Excellence (CoEs). A Center of Excellence
(CoE) is a group of people with specialized skills and expertise
 whose job is to provide leadership and purposely disseminate that
knowledge within your organization. CoEs are often created by an
organization to support the adoption of a new technology or
technique, and in fact the creation of an Agile CoE is often a key
component of your organization’s overall Agile transformation efforts.
Over the years we’ve seen CoEs for object technology (particularly
in the 90s when it was new to most companies), solution
architecture, testing automation, and of course agile/lean.
Participation as a member of a CoE will be part of, or the entire job
for someone.
 Govern improvement. It is very common for senior management to
want to know whether or not the organization is benefiting from your
investment in adopting agile and lean techniques (or other potential
improvements for that matter), how much things are improving, and
how widespread the adoption is. The implication is that there needs
to be some way to monitor and report on, preferably in a lightweight
and streamlined manner, the improvement activities.
SALES

Process Blade #15

Value Stream Layer works with DAE Layer
Sales
Sales is a process blade of a Disciplined Agile®
Enterprise (DAE). The aim of your Sales efforts is
to, you guessed it, sell your organization’s offerings
(both products and services) to customers. Your
sales people, if any, will work very closely with your
Marketing team to ensure they are focused on
selling offerings that reflect your organizations’
overall strategy. They will also work closely
with Product Management to ensure that what
they’re selling is available or can be built in a timely
manner. Organizationally Sales is often combined with Marketing or may even
be matrixed into Business Operations.
Even when your direct sales processes are fully automated, such as with
online sales at sites such as Amazon, eBay, Etsy, or many more, you still
need to understand and optimize your sales processes over time. For
example, e-commerce firms are constantly experimenting with new ways to
sell their wares, occasionally even identifying patentable techniques. They are
actively analyzing sales data, looking for patterns in customer behavior and
new opportunities. The goal is to learn, often in real time, what people want
and perhaps even to hypothesize on why they want these things.
Sales Strategies
Disciplined Agile® sales teams will consider the following strategies:

1. Reward sales people for long-term, delighted customers. Sales

should be more consultative, measured by delivering great
customer service rather than revenue generated. One option is to
give sales people a base salary plus bonus based on customer
reviews or a similar measure of customer delightedness. Another
option is to also factor in the long-term profitability of the customer
and more importantly how the sales person is contributing to
growing business with that customer. This motivates sales people
to focus on customer experience, which is much healthier for the
long-term success of your DAE.
2. Do away with sales commissions and sales quotas. Although
many sales people will not like this strategy, the fact is that sales
commissions, and worse yet quarterly or annual sales quotas, will
motivate dysfunctional behavior by your sales people. This includes
selling customers things they may not need, selling them more than
they need, or even selling them things that you don’t actually have
(yet). If you want to Delight Customers then your sales efforts
should focus on doing what’s right for the customer instead of
what’s profitable for the sales person.
3. Sell what’s on the truck. This is an old sales adage that advises
sales people to focus on selling what is actually available right now.
When sales people promise new features that don’t yet exist, or
may not be viable, this can create havoc within the team(s) building
the offering. Schedules may be impacted to the point where
previous promises to customers are put at risk due to refocusing on
the new “fire drill” and you may discover that “simple features” that
have been promised to a customer are significantly more expensive
than you initially thought. If sales people are going to sell new
things that don’t yet exist, and it will occasionally happen, then they
should first work with the appropriate Product Management people
to ensure that what they’re selling is both desirable and viable.
4. Enable salespeople to maximize time with customers. You
can’t support your customers when you’re at your desk doing
 paperwork. Automate away the non-value-added work as much as
possible.
5. Apply advanced analytics to establish prices in real time. Your
goal should be to obtain the highest yield possible from each
transaction. A perfect example of this is the way that Uber prices a
fare – when demand goes up, perhaps due to poor weather or
because it’s rush hour, the price of a ride goes up. Uber sets prices
in real time based on the current supply of drivers available in a
given area and the demand of potential passengers.
6. Tailor offerings to profitable customers. An important way that
you can Delight Customers is to tailor your offerings to better suit
their needs. For example airlines regularly do this via their loyalty
programs, offering “perks” such as seat upgrades, better food and
drinks, valet parking, concierge services at the airport, and many
other options to their frequent flyers in an effort to motivate them to
continue flying regularly with the airline. Tailoring offerings to
specific customers can require significant analytics to identify what
the customer would potentially like as well as an understanding of
the total cost structure of your value stream.
7. Demand continuous delivery from IT. When organizations are
still taking a big release approach to their product line, think the
quasi-annual Microsoft Office updates (such as Office 2013) of a
few years ago, then customers will slow down and even stop
buying just before a major release because they would often prefer
to get the new release. When the IT delivery team takes a
continuous delivery approach, think Microsoft Office 365 which
currently has weekly updates, then customers will not be motivated
to wait for an upcoming release, thereby providing you with a
steadier stream of incoming revenue. Continuous delivery
approaches also tend to be easier on salespeople because they
don’t need to learn about, and track, the features provided by each
major release.
PORTFOLIO MANAGEMENT

Process Blade #16

Value Stream Layer
Portfolio Management
The Portfolio Management process blade addresses how
an organization goes about identifying, prioritizing,
organizing, and governing their various endeavors.
Disciplined Agile Portfolio Management seeks to do this
in a effective and streamlined manner that maximizes
the creation of business value in a long-term sustainable
manner. Endeavors typically include solution delivery
projects, stable product development teams, business
experiments (along the lines of a lean startup strategy), and the operation of
existing customer offerings (products and services).

Portfolio Management Mindset

To capture the mindset for effective portfolio management, we extend the
principles, promises, and guidelines of the Disciplined Agile® Mindset with
philosophies. These philosophies are:

1. Value first, cost second. Shifting your mindset from “what is this
going to cost?” to “what value will this generate?” is critical to your
success because it helps you to focus making better investments.
You want to invest in endeavors that enhance your organization’s
ability to produce value for your customers. This in turn provides
the profits required for further investment.
2. Minimize the cost of delay. One of the strategies for maximizing
stakeholder value is to invest in developing functionality that will
provide value to the organization soonest. For example, if you
delay developing functionality that will generate annual revenue of
$10 million for six months you have an effective cost of delay of $5
million because you missed out on half a year of revenue.
Disciplined agile portfolio managers consider the cost of developing
a solution, the cost of delay that results from putting off said
development, and the revenue generated (or cost savings) when
calculating the overall value of a solution.
3. Invest in streamlining value creation. Not only do we want to
produce value for our customers, we also want to be good at doing
so. The implication is that we sometimes need to invest in
ourselves through process or environment improvements.
4. Prefer stable teams over project teams. Although portfolio
management is often believed to be the oversight of project teams,
it really is more about the coordination and oversight of initiatives in
general. In Disciplined Agile we recognize that an initiative is
seldom finished at the end of a “project.” There are usually
subsequent changes required over time requiring future releases of
the solution. The agile community has discovered that long-lived
stable teams , whose membership evolves over time, have
significant advantages over short-lived project teams in many
situations.
5. Align teams to value streams. These stable teams should be
aligned long-term to value streams or lines of business (LOBs).
High performing agile teams reliably deliver value frequently to their
business stakeholders. As a result, the business learns to trust the
teams aligned to their areas. This positive feedback cycle
maximizes the effectiveness of your agile teams. Additionally, over
time they learn more about the business adding to their
effectiveness.
6. Govern by risk, not by artifacts. Traditional governance often
focuses on the review of common artifacts such as requirement
documents, architecture models, and test results. Because it is
relatively easy for teams to create the documentation that you want
to see, in practice there is very little governance value in reviewing
these artifacts. Disciplined Agile governance instead focuses on
addressing common risks such as ensuring there is an agree to
vision for what the team should accomplish, that the architectural
strategy has been proven to be viable early in the lifecycle, and that
the team has produced sufficient business value for their
stakeholders.
7. Rolling wave over annual planning. Annual planning often begins
in earnest mid-year which means that prioritized initiatives may not
be actually delivered for up to 18 months in the following year. This
is not enterprise agility. Make your planning a continuous “rolling
wave” activity year round with more detail devoted to planning
 initiatives no longer than 6 months out. Initiatives planned beyond 6
months should be described at a very high level.
8. Prefer small initiatives over large initiatives. The larger the
initiative the greater the chance of failure. Smaller initiatives are
easier to plan and are lower risk to execute. Keep your initiatives
small to allow for more frequent delivery of value with less
investment in work in process (WIP).
9. Invest in quality. Ensuring that teams produce new business value
for your organization is clearly important. But so is ensuring that
you will still be able to continue doing so a few years from now. To
ensure the long-term sustainability of your teams you must allow
them to make investments in quality. These investments include
building high quality assets in the first place but also fixing low
quality assets, what agilists refer to as paying down technical debt.
Our experience is that the philosophies described above – in addition to the
principles, promises, and guidelines of the DA™ mindset – enable portfolio
managers to be more effective in practice.
Portfolio Management Workflow – External
Portfolio management is an important part of any organization, playing a key
guiding role for many aspects of your overall organizational process. Figure 1
depicts the high-level workflow that portfolio management is involved with,
showing the major information flows between the process blades – as always,
feedback loops are assumed and not shown.

Figure 1. The external workflow of portfolio management (Click to enlarge)

As you can see in Figure 1, there are several process blades related to
portfolio management:

 Continuous improvement. As with all other activities within your

organization, as people perform them they may identify potential
improvement suggestions that they or others may be able to take
advantage of. Similarly, others may identify potential improvements
that can be applied to your portfolio management efforts.
 Data management. Your portfolio management activities should
generate data that can be shared with data management, who then
store the data, combine it with other data, and provide valuable
 intelligence to all areas of the organization. This
intelligence/information is in turn used to provide insight and improve
decision making.
 Enterprise Architecture. The enterprise architects will produce
roadmaps and models that teams should follow. These roadmaps
will be used to help drive prioritization and investment decisions.
 Finance. The Finance team provides budget and funding for your
portfolio.
 Governance. The governance team will provide guidance for all
aspects of your organization, portfolio asset management. This
guidance typically focuses on financial and quality goals as well as
any regulatory constraints where appropriate.
 Product Management. Product roadmaps & priorities, funded
initiatives. The Product Management team will provide product
roadmaps and stakeholder priorities, which will help guide
prioritization decisions related to existing endeavors. Portfolio
management provides initial vision and an initial tranche of funding
for new initiatives.
 Strategy. The strategy process blade provides the enterprise
strategies, high-level ideas for potential initiatives, and desired
outcomes and measures of them. This direction will drive the efforts
of portfolio management and other activities within your organization.
 Teams. Endeavors, such as projects, service support, and
operational activities are addressed by teams. Portfolio management
provides the teams with the initial funding and vision for the
endeavor they are embarking upon.
The activities associated with these process blades are often highly related.
For example, in some organizations the activities associated with portfolio
management and governance are fulfilled by a single group. In other
organizations some product management activities are performed by the
portfolio management team and some by the enterprise architecture team.
Some organizations may choose to have a separate group for each process
blade. And your organizational structure will evolve over time as your various
teams learn how to work with one another.
Portfolio Management Practices
Figure 1 overviews the potential activities associated with disciplined agile
portfolio management.

Figure 1. The portfolio management process goal diagram (click to enlarge)

The process decision points that you need to consider for portfolio management
are:

1. Identify potential value. Working closely with your product

management team (if you have one), your portfolio management
team will identify potential new ideas and products to develop. You
will do this through monitoring the business environment to see
what your competitors are doing, through obtaining feedback from
your existing customers, and by envisioning the future needs of
your customers through agile modeling and brainstorming
sessions.
2. Plan capability. Your teams must have the resources, both in
terms of finance and people, to fulfill its responsibilities. You must
have the right people, with the right skills, at the right time, to do the
work and this takes a bit of coordination with your people
management team to do so.
3. Explore potential endeavors. The portfolio management team will
invest time in understanding a potential endeavor. They may
choose to consider the business case for the endeavor, perhaps
creating high-level guesses at the potential market potential or
return on investment (ROI) of the endeavor. The team may also
consider alternative approaches to the endeavor and may even
choose to run a focus group or small experiment to better
understand it.
4. Prioritize potential endeavors. Because few organizations have
unlimited budgets to work from you will need to prioritize potential
endeavors and then invest in the ones that are most important to
you. There are several factors to consider when prioritizing, there is
no one approach that works for all situations.
5. Manage portfolio budget. Your portfolio budget needs to be
managed, and you will need to work with Finance to do so.
Traditional firms tend to follow an annual budgeting process which
tends to inject significant overhead and risk into their efforts. More
effective strategies are to move away from project-based financing
to funding stable teams and to take a rolling wave approach to
planning the budget that evolves as your needs and means evolve.
6. Initiate endeavors. New products may be developed by either a
product team or a project team. In the case of products that are
radically new to your organization you may decide to first take an
 exploratory (lean startup) approach where you first validate the
market potential of the product via a series of learning experiments.
You will also find that you need to initiate service teams that
support internal customers within your organization as well as
external customers. And of course operational teams are also
initiated from time to time.
7. Finance endeavors. Endeavors need to be funded. This includes
both the initial funding for new project/product teams for their
Inception efforts as well as ongoing funding once they get going.
Additionally, how the funding is applied will be monitored regularly
to ensure that it is being spent wisely.
8. End endeavors. Eventually things come to an end. Some projects
are cancelled partway through, some projects go to completion,
some offerings are retracted from the marketplace, some service
teams are disbanded as the result of automation, and so on. In
some cases the ending of an existing endeavor is treated as a full-
fledged project and in other cases it is simply part of the ongoing
operations of that endeavor.
9. Govern the portfolio. Someone will govern the overall portfolio,
including in-progress development endeavors as well as
operational solutions. Portfolio governance is a subset of your
overall strategy.
PRODUCT MANAGEMENT

Process Blade #17

Value Stream Layer
Product Management
The Product Management process blade includes
the acts of identifying and prioritizing potential
products and services (offerings) to support your
organization’s strategy; of formulating the vision for
each of these offerings; of working with customers
to understand their high-level needs; of identifying,
prioritizing, and allocating minimum business
increments (MBIs) for the offerings under
development; of identifying and managing
functional dependencies between offerings; of
marketing those offerings to their potential customers; and of monitoring the
marketplace to identify future customer needs. Disciplined agile product
management is product management performed in a collaborative and
evolutionary manner that reflects the context of your organization.
You need an effective approach to product management because you want:

1. To build the right product(s). You will always have many more
ideas for products than you can possibly fund. Your product
management team will need to prioritize the ideas for potential
products so that they can focus on the ones that will provide the
most value to your organization.
2. To stop building the wrong product(s). Product managers will
monitor the work of development teams, ongoing experiments, and
even existing solutions running in production to determine their
effectiveness. Products that aren’t effective must either be evolved
or cancelled to enable you to focus on high-value products.
3. The right product features at the right time. When there are
many delivery teams working in parallel there will be functional
dependencies between the solutions/products being worked on.
These functional dependencies need to be taken into account when
the work is being prioritized so that the right functionality is
available when it is needed.
4. To ensure that people use the product. Part of product
management is marketing to potential end users/customers. If
people don’t know that functionality is available to them then they
are unlikely to use/buy it.
Product Management Mindset
Building on the ideas captured by the Disciplined Agile® Principles and
the Disciplined Agile Manifesto, there are several agile/lean philosophies that
are critical to success in Product Management. These philosophies are:

1. Be customer driven. The needs of customers, and more

importantly the potential desires of customers that they are not
even be aware of, should drive your Product Management
decisions. The implication is that Product Managers must work
closely with existing customers, and furthermore must invest time
to identify and understand potential customers so as to grow the
market for their product.
2. Address the full value stream. An important part of being
customer driven is to understand that it is the full customer
experience with your organization, not just the “products,” that must
be addressed. You need to understand the full value stream(s) that
your product(s) are part of from beginning to end from the
customer’s point of view — Product Management is about solutions
and not just software.
3. Take an experimental approach. People often don’t know what
they want, will struggle to describe what they want, often won’t tell
you what they want, and will change their minds anyway. The point
is that you need to go beyond asking people for their requirements
if you want to identify what to offer your customers. Modern thinking
is to take an experimental approach via creation of minimal viable
products (MVPs) to get something in front of potential customers to
determine what they actually want — you do this through observing
the features of your MVP that they use, how they use them, and the
features that they don’t use. This strategy was popularized by Eric
Ries via his Lean Startup work and is captured in
DAD’s Exploratory lifecycle.
4. Release incrementally and often. Releasing smaller increments
more often enables you to reduce the feedback cycle with your
customers, which in turn enables you to learn quickly and thus
react to customer needs faster.
5. Embrace change. Customer needs and desires change, often
rapidly. New competitors enter the market with different or
 improved offerings. New technologies and platforms are introduced
and then evolved. To be trite, the only constant is change.
Successful product managers not only accept this but they
embrace it. The implication is to adopt flexible, light-weight
strategies.
6. Plan strategically and react tactically. Products should be
planned strategically in the long term yet implemented tactically in
the short term. The common agile strategy is to take a what is
known as a rolling wave planning approach where detailed
planning occurs for what should be delivered in near team
incremental releases but for future releases the planning is high-
level and less detailed the further in the future something is.
Product Management Roles and
Responsibilities
The role of Product Manager is strategic in nature. They should be focused on
the long-term vision for the product, on observing trends in the marketplace,
on identify new potential outcomes or themes to be supported by the product,
and on ensuring the product meets the needs of the value stream(s) the
product is involved with. Effective Product Managers tend to be very customer
focused, although recognize that this needs to be tempered by the constraints
and capabilities of your organization.
As you can see in the following diagram, the role of Product Manager is
different, yet overlapping, with that of a Product Owner (PO) . Where Product
Managers are strategic Product Owners tend to be more tactical in practice.
POs work closely with delivery teams to ensure they build the right
functionality in a timely manner. POs will transform the high-level vision of the
Product Manager into detailed requirements. To do this they work closely with
a range of stakeholders for the product, including non-customer stakeholders
such as finance, security, operations, support, audit, and others.

Figure 1. Product Owners and Product Managers (Click to enlarge).

Some people, particularly those focused on Scrum, will tell you that Product
Owners should also be focused on strategic issues. This is certainly true in
simple, non-scaled situations. It is good for POs to understand the long-term
strategy for the product that they are focused on. However, there is far more
to Product Management than just software development. Furthermore, the
day-to-day work with the delivery team, in addition to the day-to-day work
required for look-ahead modelling and planning (what Scrum refers to as
backlog refinement) with stakeholders, can be more than a full-time job for
Product Owners in and of itself.
Product Management Workflow – External
The following diagram overviews the major workflows that your Disciplined
Agile® Product Management activities are associated with. Note that
feedback is implied in the diagram. For example, where you see the Business
Roadmap and Priorities flow from Product Management to Portfolio
Management there is an implied feedback loop from the portfolio managers to
the product managers. Also note that the workflows do not necessarily imply
that artifacts exist. For example, some of the work items provided to solution
teams may be via discussions with their product owners.

Figure 1. The External Workflow of Disciplined Agile Product Management (click

to enlarge).
The following table summarizes the workflows depicted in the diagram.

Process Blade Workflow with Product Management

Continuous The continuous improvement activities will provide

Improvement potential improvement suggestions for improving
enterprise architecture efforts. Similarly, the Product
Management team may have insights to share with the
rest of the organization.

Data Product Management will provide product data to the

Management data management activities, which in turn provides
intelligence about the marketplace and your
organization’s activities.

Disciplined Product management defines minimum business

Agile Delivery increments (MBIs) for delivery teams to work on, and
provide product roadmaps to help guide prioritization
decisions made by the team.

Disciplined Product management provides product roadmaps to

DevOps various DevOps activities, such as data management and
IT operations, as input into their prioritization and
planning decisions.

Enterprise Enterprise architecture will provide the organization-

Architecture level business and technology roadmaps to product
management which is an input into evolving the vision
for a product and identifying new potential features for
products. Product management provides product
roadmaps which is are as input into evolve the enterprise
architecture.

Governance The governance efforts will provide guidance to your

product management activities.

Portfolio Product Management provides product roadmaps to

Management portfolio management, which are used as input into
 identifying potential business value. Portfolio
management provides funding for valuable initiatives
identified by product management.

Program Product Management will provide product roadmaps and

Management definitions of MBIs for a program team to work on.

The activities associated with these process blades are often very highly
related. For example, in some organizations the activities associated with
product management and portfolio management are fulfilled by a single group.
In other organizations some product management activities are performed by
the portfolio management team and some by the enterprise architecture team.
Some organizations may be large enough that it makes sense to choose to
have a separate group for product management. And of course the
organizational structure will evolve over time as your various teams learn how
to work with one another.
Product Management Practices
The following process goal diagram overviews the potential activities
associated with disciplined agile product management.
Figure 1. The process goal diagram for product management (Click to enlarge).
The process factors that you need to consider for product management are:

1. Monitor the market. Product managers will want to monitor how

successful their products are (e.g. monitor actual ROI, market
adoption rates, end user satisfaction) as well as how well the
products are being evolved (e.g. are you continuing to invest in
successful products). Product governance is one aspect of your
overall governance efforts.
2. Evolve vision. Product managers will work closely with
stakeholders, and in the case of new products/solutions potential
stakeholders, to understand their needs. The goal is to develop
roadmaps for individual products, product lines, and for the
business itself. These roadmaps describe the current vision for the
near term, intermediate term (3-12 months), and long term (one
year or more) with less detail the further out in time the roadmap
goes. These roadmaps help the product managers to guide their
prioritization decisions and provides input into the planning
activities of other efforts (such as the Enterprise
Architecture and Portfolio Management activities).
3. Explore potential features. Product managers want to identify
potential products that will provide significant value to your
organization. They may do this via a variety of means, including the
more traditional approaches of building a business case to more
agile/lean strategies such running a small experiment.
4. Prioritize potential features. There will be many potential
products that your organization would like to invest in, but a limited
budget to do so. The implication is that only the highest priority
products will be developed, and therefore need to be prioritized
appropriately.
5. Evolve roadmap. The business and/or product roadmap is
developed and evolved by your product management activities.
Traditional strategies tend to take either an annual or ad-hoc
approach whereas more disciplined agile strategies take more of a
rolling wave approach.
6. Allocate features. Features — which could be captured as
outcomes, epics, stories, feature statements, or other forms — will
need to be allocated to delivery teams so that they may be
implemented. These features will need to be prioritized by the
product managers (who are often in the role of Product Owner on
 the delivery teams) so that the teams know the order in which to
implement the functionality.
7. Choose release cadences.
8. Manage functional dependencies. Functional dependencies often
exist between products, due to the usage of common platforms and
the need for integrated solutions, and these functional
dependencies need to be managed. The product managers will
want to manage these dependencies so as to optimize when
functionality is implemented and released into production. For more
information on dependency management strategies, please
see Managing Dependencies Between Agile Teams , Managing
Dependencies Between Agile and Lean Teams , and Managing
Dependencies Between Agile/Lean Teams and Traditional Teams .
9. Market offerings. Product managers will market their products to
their potential customer base to increase the usage of the products.
The need for such marketing is clear in the case of commercial
products and other types of solutions intended for public use.
Marketing is also needed for solutions developed for internal usage
to increase the chance that the potential user base knows about
the existence of the (upcoming) release of the product.
MVPs and MBIs
Two of the key aspects of the DA™ mindset for Product Management are to
take an experimental approach and to release a product incrementally.
Experimentation is supported through the development of Minimum Viable
Products (MVPs) and incremental releases of value by Minimum Business
Increments (MBIs). These concepts, and more, are overviewed in Figure 1.

Figure 1. The relationship between MVP, MBI, MMR, and MMF (click to enlarge)
Let’s define what these terms mean:

 Minimum Viable Product (MVP) . An MVP is an investment in

learning, an experiment where your goal is to explore what a
potential customer wants. To run this experiment you'll create a
version of a product via the least effort possible so as to be used for
validated learning about your potential customers. MVPs are
experiments to explore a hypothesis about what your customers
really want. They aren't to the “real” running version of your end
product because they aren't at the level of quality or scale that you
would produce for the end product. Having said that, I have seen
MVPs evolve into a real product, or more accurately a real MBI, but
more often than not they evolve into something more along the lines
of a prototype (which is fine because they're an investment in
learning and were never meant to be the real thing). A team typically
runs the experiment with a subset of your potential customers to test
a new idea, to collect data about it, and thereby discover customers
are actually interested in. Note that the term MVP was coined by
Frank Robinson at SyncDev in 2001 popularized by Eric Ries
in Lean Startup in 2011.
 Minimum business increment (MBI) . An MBI is the smallest piece
of value that can be realized by a customer (internal or external) that
is consistent with the strategy of your organization. An MBI adds
value for your customers and leads to valuable feedback to the
product team that the right functionality is being built and is being
built in the right way. An MBI is a solution that contains all of the
pieces that are required for value realization by customers. An MBI,
when it is done right, is both an MMF and an MMR.
 Minimum Marketable Feature (MMF) . An MMF is the smallest
piece of functionality that can be delivered that has value to its
customers, and thereby value to your organization. An MMF is a part
of an MMR. The term MMF was first proposed by Denne and
Cleland-Huang.
 Minimum Marketable Release (MMR) . Successful products are
deployed incrementally into the marketplace over time, each “major”
deployment being referred to as a release. An MMR is the release of
a product that has the smallest possible feature set that addresses
the current new needs of your customers. MMRs are used to reduce
the time-to-market between releases by reducing the coherent
 feature set of each release to the smallest increment that offers new
value to customers. An MMR is one or more MBIs (ideally it is one).
In DA, we prefer to focus on the terms MVP and MBI because when you’ve
streamlined your way of working (WoW) you discover than an MBI is an MMF
that you release (so it’s also an MMR). Concepts like MMF and MMR are
steps along the path to MBIs. For a more detailed discussion, please read
Defining MVP, MBI, MMF, and MMR.
PROGRAM MANAGEMENT

Process Blade #18

Value Stream Layer
Program Management
The Product Management process blade includes
the acts of identifying and prioritizing potential
products and services (offerings) to support your
organization’s strategy; of formulating the vision for
each of these offerings; of working with customers
to understand their high-level needs; of identifying,
prioritizing, and allocating minimum business
increments (MBIs) for the offerings under
development; of identifying and managing
functional dependencies between offerings; of
marketing those offerings to their potential customers; and of monitoring the
marketplace to identify future customer needs. Disciplined agile product
management is product management performed in a collaborative and
evolutionary manner that reflects the context of your organization.

A program is a large team composed of two or more sub-teams (also called

squads). Some of the sub-teams may be external to your organization,
working for partner firms or service providers. The purpose of program
management is to coordinate the efforts of the sub-teams to ensure they work
together effectively towards the common goal of producing a consumable
solution for their stakeholders. In some ways “program coordination” is a more
accurate term than “program management,” but “program management” is the
commonly accepted term.
There are several potential reasons why large teams exist:

1. Some endeavours are inherently big. Sometimes an organization

will decide to take on a complex effort, such as building an office
tower, an air traffic control system, or a financial transaction
processing system.
2. Overly-specialized staff promote larger teams. When staff are
narrowly focused it requires many people to work, at least part
time, on a team so that the team has sufficient skills to get the job
done. When people are generalizing specialists your teams
become much smaller and more collaborative.
3. Overly bureaucratic processes promote larger teams.
Sometimes the systemic bureaucracy in an organization requires
 large numbers of people to address that bureaucracy. We once
assessed an eighty-person project team who were doing work that
only required between ten and fifteen people to do the “real work”
and everyone else to conform to the overhead of their traditional
CMMI-compliant process. Sadly, they didn’t rework the team and
failed to produce anything after three years and many millions of
dollars of investment. As an aside, it is possible and highly
desirable to effectively combine CMMI and disciplined
agile approaches, but you need to overcome the cultural
dissonance of the two paradigms. Similarly, we’ve seen teams
misjudge and adopt a scaling framework such as SAFe® when their
situation didn’t warrant it – this motivated them to create a much
larger team than they actually needed.
4. Working on large teams can lead to greater rewards. Similarly,
someone is “empire building” and purposefully creates a large team
so that they will be rewarded for doing so. We have worked in two
organizations where, before their agile transformation, the pay
grade of a manager was determined by the number of people the
person managed. Worse yet, in one organization the people on the
larger teams tended to get better bonuses, and quicker promotions,
than people on smaller teams regardless of the actual ability of the
team to deliver value to the organization.
In our opinion, the only valid reason for building a large team is because your
endeavor is inherently big. The other reasons reflect aspects of organizational
cultures that need to be fixed in time. Luckily, there are several strategies that
you can employ to reduce the size of a team:

1. Reorganize the problem into a collection of smaller problems.

Disaggregation of a large problem is performed through a
combination of agile envisioning and agile business analysis. This
is a key responsibility of your product management efforts: to feed
reasonably-sized portions, called minimum business increments
(MBIs), of work to your teams.
2. Reduce the problem. Sometimes a large problem can be shrunk
down through pruning features out of the vision, or at least by
deferring them until later.
3. Address your organization’s culture. As we discussed earlier,
most of the reasons that organizations build large teams are the
result of cultural challenges. We suggest that you fix the real
 problem by adopting a Disciplined Agile® Mindset and evolving
your way of working (WoW), thereby motivating an evolution of
your culture.
4. Organize the large team into a collection of smaller teams. In
other words, create a program.
5. Adopt a Disciplined Agile approach. Enable your teams,
regardless of size, to choose their own way of working (WoW) and
thus have a process that addresses the needs of the situation that
they face. Some people call this process right-sizing, de-scaling, or
process disaggregation – we simply call it pragmatic.
When you find yourself in a situation where you need a large team, and those
situations do exist in many organizations, and you can’t find a way to reduce
the size of the team, then you will need to adopt strategies to coordinate that
team. This process blade will help you to do exactly that.
Program Management Roles and
Responsibilities
There are several roles that are pertinent to program management.
Remember that these are roles, not positions. Small organizations may have
a single person taking on every one of these roles whereas a large
organization could have dozens of fine-grained positions. Remember, context
counts. We define the following key roles that are specific to Disciplined
Agile® (DA™) program management:

 Program Manager/Coordinator. Leads the overall program,

coordinating activities within the program to keep it on track. Works
closely with the Chief Product Owner (CPO) and Chief Architecture
Owner (CAO) to guide the overall work of the sub-teams. Facilitates
discussions between the CPO and CAO when there are differences.
 Chief Architecture Owner (CAO). Leads the architecture team
within a program and is effectively their Team Lead. Guides
the Architecture Owners through negotiating technical dependencies
within a program, mentoring people where needed. Works closely
with the enterprise architecture team and often is an enterprise
architect. May take on the role of Architecture Owner on one or more
sub-teams.
 Chief Product Owner (CPO). Leads the Product Owner team within
a program and is effectively their Team Lead. Works closely with the
Program Manager to allocate work between sub-teams and may be
the Program Manager for the offering(s) the program produces.
Guides the Product Owners through negotiating functional
dependencies, mentoring people where needed. May take on the
role of Product Owner on one or more sub-teams.
Team Structure of a Large Program
A large program team is organized as a team of teams, called sub-teams or
squads. Structures are required to coordinate people, requirements, and
technical concerns within the overall program. Where a simple “scrum of
scrums” may suffice coordination on small-to-medium sized programs (say up
to five or six sub-teams), it quickly falls apart for larger programs. As a result,
large programs will find that they need:

 A Product Management (or Product Ownership) strategy where the

Product Owners coordinate their activities
 An Architecture (or Architecture Ownership) strategy where the
Architecture Owners coordinate their activities
 A Product Coordination (or Management) strategy where the Team
Leads coordinate their activities.
 An optional Program Coordinator/Manager, a specialist role, is
responsible for coordinating the overall leadership team.

Figure 1. Team structure for a large program (click to expand).

The following structure shows how the Product Owners of each sub-team are
also members of the Product Management/Product Owner team for the
program. Similar structures, see Large Agile Teams, will also exist for Product
Delivery and Architecture as well.

Figure 2. The team structure for the Product Owner team on a large program
(click to expand).
Program Management Workflow – External
Figure 1 overviews the major workflows that a Disciplined Agile® (DA™)
program is associated with. Note that feedback is implied in the diagram to
keep it simple. For example, where you see the Roadmaps & Models flow
from Enterprise Architecture to Program Management there is an implied
feedback loop from the program to the enterprise architects. Also note that the
workflows do not necessarily imply that artifacts exist. For example, the
improvement suggestions workflow with Continuous Improvement could be a
conversation between two or more people, it could be an email, or it could be
a detailed document – or combinations thereof.

Figure 1. The relationship of program management to other aspects of your

process.
The following table summarizes the workflows depicted in the diagram.

Process Blade Workflow with Program Management

Asset All teams should use or reuse existing assets whenever

Management appropriate.

Continuous Your continuous improvement efforts should result in

Improvement improvement suggestions gleaned from other teams that
the program can learn from, and your program team
should choose to share their learnings too.

Data The program will generate data that can be used in your
Management organization’s overall business intelligence strategy, and
your program will use such intelligence as input into
their decisions.

Enterprise The enterprise architects will produce roadmaps and

architecture models that delivery teams should follow where
appropriate.

Governance The governance team will provide guidance to all teams,

including large delivery teams. This guidance will focus
on a range of topics, including: financial and quality
goals; regulatory constraints; technical guidance (security
guidelines, data standards, …); and other subjects
pertinent to the program.

Portfolio Your organization’s portfolio management activities will

Management provide the initial vision and funding required to initiate
a program, as well as ongoing funding for the program.

Product The Product Management team will provide a product

Management roadmap, define the minimum business increments
(MBIs), and share stakeholder priorities with the
program team.
 Release Your program will release solutions via your
Management organization’s release management strategy.

Support Your support/help-desk team will provide change

requests, including defect reports, identified by end
users. These change requests are potentially new
requirements for your program.

There is clearly overlap with some of the activities in the portfolio

management, enterprise architecture, release management, product
management, and governance process blades. The issue is one of scope.
Where these process blades address activities across your organization, the
scope of the related activities within program management is the program
itself. For example, where enterprise architecture addresses architectural
issues for the entire organization, the architecture activities encompassed by
program management relate only to the architecture of the solution being
produced by the program.
Program Management Workflow – Internal
Disciplined Agile® Delivery (DAD)’s Program life cycle, shown below,
describes how to organize a team of teams. Large agile teams are rare in
practice, but they do happen. This is exactly the situation that agile scaling
frameworks such as SAFe, LeSS, and Nexus address.

Figure 1. DAD’s Program life cycle for a team of teams (click to expand).
There are several critical aspects to this life cycle:

 There’s an explicit Inception phase. Like it or not, when a team is

new we need to invest some up front time getting organized, and this
is particularly true for large teams given the additional risk we face.
We should do so as quickly as possible, and the best way is to
explicitly recognize what we need to do and how we’ll go about doing
so. SAFe has a similar concept called program increment (PI)
planning, although Inception is more robust as it includes potential
activities around forming teams, explicit requirements and
architecture modeling, test strategizing, and more.
 Sub-teams/squads choose and then evolve their WoW. Sub-
teams, sometimes referred to as squads, should be allowed to
choose their own WoW just like any other team would. This includes
choosing their own life cycles as well as their own practices. We may
choose to impose some constraints on the teams, such as following
common guidance and common strategies around coordinating
within the program.
 Sub-teams can be either feature teams or component teams. A
feature team works vertical slices of functionality, implementing a
story or addressing a change request from the user interface all the
way through to the database. A component team works on a specific
aspect of a system, such as security functionality, transaction
processing, or logging. Our experience is both types of teams have
their place, they are applicable in certain contexts but not others, and
the strategies can and often are combined in practice.
 Coordination occurs at three levels. When we’re coordinating
between sub-teams there are three issues we need to be concerned
about: Coordinating the work to be done, coordinating
technical/architectural issues, and coordinating people issues. This
coordination is respectively performed by the Product Owners, the
Architecture Owners, and the Team Leads as you see in Figure 2.
The Product Owners of each sub-team will self-organize and
address work/requirements management issues amongst
themselves, ensuring that each team is doing the appropriate work
at the appropriate time. Similarly, the Architecture Ownership team
will self-organize to evolve the architecture over time and the Team
Leads will self-organize to manage people issues occurring cross
teams. The three leadership sub-teams are able to handle the type
of small course corrections that are typical over time. The team may
 find that they need to get together occasionally to plan out the next
block of work – this is a technique that SAFe refers to as program
increment (PI) planning and suggests that it occurs quarterly. DA™
suggests that you do it when and if it makes sense.
 System integration and testing occurs in parallel. The life cycle
shows that there is a separate team to perform overall system
integration and cross-team testing. Ideally this work should be
minimal and better yet entirely automated. We often need a separate
team at first, often due to lack of automation, but our goal should be
to automate as much of this work as possible and push the rest into
the sub-teams. Having said that we’ve found that usability testing
across the product as a whole, and similarly user acceptance testing
(UAT), often requires a separate effort for logistical reasons.
 Sub-teams are as whole as they can be. The majority of the
testing effort should occur within the sub-teams just like it would on a
normal agile team, along with continuous integration (CI) and
continuous deployment (CD).
 We can deploy any time we want. We prefer a CD approach to
this, although teams new to agile programs may start by releasing
quarterly (or even less often) and then improve the release cadence
over time. Teams who are new to this will likely need a Transition
phase, some people call these “hardening sprints” or “deployment
sprints” the first few times. The Accelerate Value Delivery process
goal captures various release options for delivery teams and
the Release Management process blade for organizations as a
whole.
Figure 2. Team structure for a large program (click to expand).
Let’s consider the workflow implied by the Program life cycle in Figure 1
above given the team structure of Figure 2. Someone in the role of Program
Manager coordinates the three leadership teams (described in greater detail
in Large Agile Teams):

1. Product coordination team. This team is responsible for dealing

with cross-team “management issues” such as moving people
between teams, resolving disputes that cross team boundaries, and
any coordination issue that doesn’t fall under the purview of the
other two leadership teams. The Program Manager often leads the
product coordination team, which is made up of the Team Leads
from the delivery sub-teams, and may even be a Team Lead of one
of the delivery teams as well.
2. Product owner team. This team is responsible for requirements
management, prioritizing the work, and assigning work items to the
various sub-teams. This team is led by a Chief Product Owner
(CPO), not shown, who is often a Product Owner for one more
more sub-teams.
3. Architecture owner team. The AO team is responsible for
facilitating the overall architectural direction of the program, for
evolving that vision over time, and for negotiating technical
dependencies within the architecture. This team is led by a Chief
Architecture Owner (CAO), also not shown, who is often an
Architecture Owner on one or more delivery sub-teams.
An important difference between the Disciplined Agile approach and many
agile scaling frameworks is that the sub-teams may be following different life
cycles. The Disciplined Agile (DA) toolkit supports several delivery life cycles,
including the Scrum-based Agile and Continuous Delivery: Agile life cycles;
the Kanban-based Lean and Continuous Delivery: Lean life cycles; and the
Lean Startup-based Exploratory life cycle. Even when the sub teams are
following the same life cycle they may be working to different cadences (or
not).
The life cycle diagram of Figure 1 also shows that some programs may
include a parallel independent testing effort in addition to the whole team
testing efforts of the sub-teams. The delivery sub-teams will make their
working builds available to the testers on a regular basis, who will integrate all
of the builds into their testing environment. This independent testing effort
often addresses end-to-end system integration testing as well as other forms
of testing that make better economic sense when done in a centralized
manner. Independent testing is common for large programs that are tackling
complex domains or complex technologies or that find themselves in a
regulatory environment that requires independent testing. The SAFe
equivalent to a parallel independent test team would be called a system team,
in this case one doing system integration plus independent testing. Same
basic concept, slightly different wording.
Program Management Practices
Figure 1 overviews the potential activities associated with disciplined agile
program management. Because every team, including programs, are
different, they need to be able to choose (and later evolve) their own way of
working (WoW). The goal diagram indicates the decision points critical to
program management, such as how to allocate work across squads (sub-
teams) and how to coordinate between them, and then potential options for
doing so. Your team will need to choose the best way that they can work right
now, given your skills, culture, and situation that you face. And you should
strive to learn and evolve your WoW over time.
Figure 1. The process goal diagram for program management.
The process factors that you need to consider for program management are:

1. Allocate work. Work items must be allocated to the squads

throughout the life cycle. The type of work and the focus of a squad
are the primary determinants of how work is allocated. However,
squad capacity and load balancing concerns, for example a squad
has run out of work or a squad currently has too much work, will
also be considered when allocating new work. Work allocation is
the responsibility of your product owners although team capacity
planning and monitoring is typically performed by the program
manager and team leads. Regardless, these activities should be
performed collaboratively by the available people at the time.
2. Prioritize work. The work performed by the squads – including
new requirements and fixing defects – needs to be prioritized.
There are several ways to prioritize the work, such as by business
value, by risk, by severity (in the case of production defects), or by
weighted shortest job first (WSJF) to name a few strategies.
Prioritization is an ongoing activity throughout the life cycle and is
the responsibility of your product owners.
3. Plan program. Traditional programs are often planned on an
annual or even ad-hoc basis. Agile programs, at least the
disciplined ones, tend to plan on a rolling wave basis.
4. Organize teams. There are three common strategies for how you
can organize delivery teams within a program – feature teams,
component teams, and internal open source – each of which has
advantages and disadvantages. In addition to the
squads/subteams, you are likely to find the need for leadership
teams – the Product Owner team, the Architecture Owner team,
and the Product Coordination/Management team – made up of the
product owners, architecture owners, and team leads from the
delivery teams respectively. These leadership teams are
responsible for work/requirements coordination, technical
coordination, and management coordination within the program
respectively.
5. Coordinate teams. There are several ways that the squads can
coordinate with one another. For example, they could choose to
have cross-team coordination meetings (also called a Scrum of
Scrums (SoS)); they could visualize the work through task boards,
team dashboards, and other information radiators such as a
 modeling wall; they could choose to have “big room” planning
sessions where all team members are involved or “small room”
agile modeling sessions where a subset of people are involved; or
even traditional (or agile) checkpoint meetings. All of these
strategies have their advantages and disadvantages, and all can be
applied by the various types of teams mentioned earlier.
6. Coordinate schedules. There are several strategies that a
program can adopt to coordinate the schedules between sub
teams. The easiest conceptually, although often hardest to
implement in practice, is to have all squads on the same cadence
(e.g. every squad has a two week iteration). Another option is to
have multiplier cadences where the schedules of squads align
every so often. For example, we once worked with a large program
where some squads had a one-week iteration, some had a two-
week iteration, and a few had a four-week iteration. We’ve also
seen another team where squads had one, two, or three-week
iterations that provided alignment of iteration endings every six
weeks. Most common, although rarely discussed, is for squads to
have disparate cadences. This is guaranteed to occur when teams
are following different life cycles (remember, the DA™ tool kit
supports several). For example, when some squads are following a
Scrum-based agile life cycle that has iterations, and other squads
following Kanban-based lean life cycles that have no iterations,
then you have an alignment challenge. Or if you have squads
adopting any iteration length they like (we’ve seen some programs
with squads with two, three, four and sometimes even five-week
iteration lengths) then they also in effect have disparate cadences.
7. Schedule solution releases. Programs need to schedule their
own releases, in accordance to your organization’s release
management strategy, which involves coordination between the
sub-teams. When the cadences of the squads/sub-teams are
(reasonably) aligned then it is easier to coordinate production
releases. For example, when all squads have two-week iterations
(or at least the squads with iterations do) then they could potentially
release into production every two weeks. In the case of multiplier
cadences, there is the potential to release into production each
time the iteration endings align.
8. Negotiate functional dependencies. An important responsibility of
the Product Owner team is to manage the functional dependencies
between the work being performed by various sub-teams. There
 are strategies to manage dependencies between two agile sub-
teams , between an agile sub-team and a lean sub-team , and even
between an agile/lean sub-team and a traditional sub-team (this
isn’t ideal, but sometimes happens).
9. Negotiate technical dependencies. Similarly, an important
responsibility of the Architecture Owner team is to work through
technical dependencies within the solution being developed by the
program.
10. Govern the program. The program must be governed, both
internally within the program itself while still operating under the
aegis of your organization’s overall strategy. Program-level metrics,
particularly those tracking the progress of sub-teams and the
quality being delivered, are vital to successful coordination within
the program. Sub-teams should also be working to common
conventions, ideally those of the organization but in some cases
specific to the program itself. Programs, because of their size and
because they are usually higher risk, often have more rigorous
reporting requirements for senior management so as to provide
greater transparency to them. The implication is that a program’s
dashboard often has a more robust collection of measures on
display.
Scaling Program Management
Although program management primarily addresses the issue of team
size, as you see in Figure 1 it is only one of several
potential scaling/complexity factors faced by a team. It is important to
recognize that a program team is likely to face several of the other scaling
factors in addition to team size.

Figure 1. The scaling/complexity factors of the Situation Context Framework

(SCF).
Your decisions around how to choose and evolve your way of working (WoW)
will still be affected by the other scaling factors:

1. Geographic distribution. Chances are very good that large teams

will also be geographically distributed in some way. There are two
flavors of this: Are teams geographically distributed (e.g. in different
physical locations) and are people within a team geographically
dispersed (e.g. people are working in cubes, on different floors, in
different buildings, or from home)? Both add
risk. Coordination within the program becomes more difficult the
more distributed the teams are, and more difficult within teams the
more distributed the people are. Distribution hits the leadership (the
product owner team, the architecture owner team, and the team
lead/product delivery) teams particularly hard because members
should be located with their delivery sub-teams but also need to
work regularly with their counterparts located elsewhere. The
implication is that the team may require extra tooling to enable
collaboration and more importantly be prepared to invest in travel
regularly to foster better communication between disparate
locations. Furthermore, when your stakeholders are geographically
distributed it may require your Product Owners to get support
from agile business analysts in the various locations to help elicit
requirements from them.
2. Organizational distribution. The larger the team, the more likely
you are to involve contractors, consultants, or even
to outsource portions of the work. When external organizations are
involved the Program Manager will likely be involved it the contract
management effort, which in turn may require assistance by the
team leads.
3. Skills availability. The larger the program, the less likely it is for
you to immediately have sufficient numbers of people with the
sufficient skills to do the job. The implication is that you will need to
work with your People Management group to help existing staff to
learn the requisite skills or hire people with those skills. You may
also need to work with Vendor Management to partner with
external firms to provide people, or even entire teams, with needed
skills.
4. Compliance. Compliance, either regulatory compliance required by
law or self-imposed compliance (i.e. CMMI compliancy ), will
definitely have an effect on your approach to program
 management. In fact, the larger the program the more likely it is to
fall under regulatory compliance due to the greater risk involved.
Regulatory compliance generally requires greater governance both
within the program and outwards facing as well. Under some
regulations your coordination efforts will require proof that they
occurred, such as some form of meeting minutes that capture who
was involved, the decisions made (if any), and action items taken
by people. Compliancy may also motivate more sophisticated
approaches to capturing requirements by your Product Owners and
to documenting technical concerns by your Architecture Owners.
5. Solution complexity. The larger the team, the more likely it is that
they are taking on greater solution complexity. More accurately,
greater complexity often motivates the creation of larger teams to
deal with that complexity. Greater solution complexity will motivate
greater attention to architecture and design, thereby motivating
more regular collaboration of the Architecture Owners.
6. Domain complexity. Similarly, team size and domain complexity
tend to go hand-in-hand. Greater domain complexity will require the
Product Owners to work in a more sophisticated manner and may
even motivate them to get support from agile Business Analysts (or
junior Product Owners as the case may be).
Program Management and DevOps
Program management, at least of an IT-focused effort, can and should be an
integral part of your DevOps effort. In the case of the Disciplined
DevOps workflow of Figure 1, you would support the Disciplined Agile®
Delivery (DAD) process blade with program management. Program
management would coordinate the efforts between the team of DAD teams as
well as any development efforts by people representing from other process
blades.

Figure 1. The workflow of Disciplined DevOps.

In organizations with a Disciplined DevOps strategy in place it is very common
to see program teams taking on the responsibilities of operating and
supporting their own systems in production, and of doing the work to release
their solutions into production. In organizations without a strong DevOps
mindset (yet), you are likely to find that operations, support, and release
management are done by separate groups outside of your program team.
Context counts, and it’s good to have a process tool kit that is flexible enough
to support the situation that you find yourself in.
DISCIPLINED AGILE DELIVERY (DAD)

Process Blade #19

Disciplined DevOps Layer
Disciplined Agile® Delivery (DAD)
Disciplined Agile Delivery (DAD) is a people-first,
learning-oriented hybrid agile approach to IT solution
delivery. It has a risk-value delivery lifecycle, is goal-
driven, is enterprise aware, and is scalable. DAD is part
of the Disciplined DevOps layer, as you see in Figure 1.

Figure 1. The workflow of Disciplined DevOps.

There are several reasons why you should consider adopting DAD. They are:

 DAD picks up where Scrum leaves off. DAD describes how all
agile techniques fit together, going far beyond Scrum, to define a full
agile solution delivery life cycle. Like Scrum the DAD addresses
leadership, roles & responsibilities, and requirements change
management. Unlike Scrum DAD doesn’t stop there, it also
addresses other important aspects of software development such as
architecture, design, testing, programming, documentation,
deployment and many more. In short, DAD provides a much broader
understanding of how agile development works in practice, doing a
lot of the “heavy process lifting” that Scrum leaves up to you.
 DAD is pragmatic. The DA toolkit provides choices, not
prescriptions, enabling you to easily tailor a strategy that reflects the
situation that your team finds itself in. To do this effectively you need
to understand the process-oriented choices you have and what the
trade-offs are. DAD makes these choices explicit through its
process-goal driven approach.
 DAD supports both lean and agile ways of working (WoW). DAD
supports several delivery life cycles, including a Scrum-based agile
life cycle, a Kanban-based lean life cycle, two continuous delivery life
cycles, a Lean Startup-based exploratory life cycle, and a Program
“team of teams” life cycle. Teams find themselves in unique
situations, and as a result one process size does not fit all. Even in
small companies we’ve seen situations where some teams are
taking an agile approach, some a lean approach, and some
combinations thereof.
 DAD is based on empiricism. For several years Scott Ambler,
Mark Lines, and many other contributors to DAD worked in or visited
hundreds of enterprises around the world in a wide range of
industries and environments. DAD, and the DA tool kit in general,
captures the proven strategies adopted by these organizations,
describing the strengths and weaknesses of each strategy and
providing guidance for when and when not to apply them.
 DAD provides a solid foundation from which to scale agile. DAD
supports successful scaling of agile and lean techniques in several
ways. First, its full delivery life cycles and breadth of software
development advice answers how to successfully apply agile in
practice. Second, its goal driven approach provides the required
 flexibility for tailoring your agile process to meet the challenges faced
by agile teams working at scale. Third, DAD builds in many
foundational concepts required at scale, including DevOps, explicit
agile governance, and enterprise awareness.
 DAD enables and goes beyond 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 and is in fact complementary to SAFe. DAD describes
several strategies for organizing large or geographically distributed
teams. It describes a range of options for scaling your approach to
agile and lean software development, giving you context-sensitive
options that SAFe doesn’t.
 DAD teams deliver solutions, not just software. DAD recognizes
that the software we develop runs on hardware, which may need
upgrades, and it is supported by documentation. Our stakeholders
may also need to evolve their business processes, and sometimes
even their organization structures, to address the new needs of the
situation that they face. In short, DAD teams deliver consumable
solutions that comprise software, hardware changes, supporting
documentation, improved business processes, and even
organizational changes.
 DAD is evolving. We’re constantly learning as practitioners,
learning about and experimenting with new agile and lean strategies
all of the time. These learnings are constantly being applied to
evolve DAD.
The Disciplined Agile® Delivery (DAD) tool kit suggests a robust set of roles
for agile solution delivery. These roles are overviewed in the following figure.
As you can see there are two categories of roles:

1. Primary roles. These roles are commonly found on DAD

teams regardless of the level of scale faced by the team.
2. Supporting roles. These roles are filled, often on a temporary
basis, to address scaling issues.

Figure 1. The roles of DAD (click to enlarge).

Primary roles are commonly found regardless of the level of scale. There are
five primary roles:

1. Stakeholder. A stakeholder is someone who is materially impacted

by the outcome of the solution. In this regard, the stakeholder is
clearly more than an end-user: A stakeholder could be a direct
user, indirect user, manager of users, senior manager, operations
staff member, the “gold owner” who funds the project, support (help
desk) staff member, auditors, your program/portfolio manager,
developers working on other systems that integrate or interact with
the one under development, maintenance professionals potentially
affected by the development and/or deployment of a software
project. DAD teams will ideally work together with their
stakeholders daily throughout the project.
2. Team Member. The role of team member focuses on producing
the actual solution for stakeholders. Team members will perform
testing, analysis, architecture, design, programming, planning,
estimation, and many more activities as appropriate throughout the
project. Note that not every team member will have every single
one of these skills, at least not yet, but they will have a subset of
them, and they will strive to gain more skills over time. Team
members are sometimes described by core agile methods as
“developers” or simply as programmers. However, in DAD we
recognize that not every team member necessarily writes code.
Team members will identify tasks, estimate tasks, “sign-up” for
tasks, perform the tasks, and track their status towards completion.
3. Team Lead. An important aspect of self-organizing teams is that
the team lead facilitates or guides the team in performing technical
management activities instead of taking on these responsibilities
him or herself. The team lead is a servant-leader of the team,
creating and maintaining the conditions that allow the team to be
successful. The team lead is also an agile coach, helping to keep
the team focused on delivering work items and fulfilling their
iteration goals and commitments that they have made to the
product owner. He or she acts as a true leader, facilitating
communication, empowering them to self-optimize their processes,
ensuring that the team has the resources that it needs, and
removes any impediments to the team (issue resolution) in a timely
manner. When teams are self-organizing, effective leadership is
crucial to your success.
4. Product Owner. In a system with hundreds or thousands of
requirements it is often difficult to get answers to questions
regarding the requirements. The product owner is the one
individual on the team who speaks as the “one voice of the
customer.” He or she represents the needs and desires of the
stakeholder community to the agile delivery team. As such, he or
she clarifies any details regarding the solution and is also
responsible for maintaining a prioritized list of work items that the
team will implement to deliver the solution. While the product owner
may not be able to answer all questions, it is their responsibility to
track down the answer in a timely manner so that the team can stay
focused on their tasks. Having a product owner working closely
with the team to answer any question about work items as they are
being implemented substantially reduces the need for
requirements, testing, and design documentation. You will of
course still have need for deliverable documentation such as
operations manuals, support manuals, and user guides to name a
few. Each DAD team, or sub-team in the case of large programs
organized into a team of teams, has a single product owner. A
secondary goal for a product owner is to represent the work of the
agile team to the stakeholder community. This includes arranging
demonstrations of the solution as it evolves and communicating
project status to key stakeholders.
5. Architecture Owner. Architecture is a key source of project risk
and someone needs to be responsible for ensuring the team
mitigates this risk. As a result DAD explicitly includes Agile
Modeling’s role of architecture owner. The architecture owner is the
person who owns the architecture decisions for the team and who
facilitates the creation and evolution of the overall solution design.
The person in the role of team lead will often also be in the role of
architecture owner on small teams. This isn’t always the case,
particularly at scale, but it is very common for smaller agile teams.
Although the architecture owner is typically the senior developer on
the team – and sometimes may be known as the technical
architect, software architect, or solution architect – it should be
noted that this is not a hierarchical position into which other team
members report. He or she is just like any other team member and
is expected to sign-up and deliver work related to tasks like any
other team member. Architecture owners should have a technical
background and a solid understanding of the business domain.
Supporting Roles
Supporting roles (formerly called secondary roles) are typically introduced,
often on a temporary basis, to address scaling issues. There are five
supporting roles:

1. Specialist. Although most agile team members are generalizing

specialists, sometimes, particularly at scale, specialists are
required. For example, on large teams or in complex domains one
or more agile business analysts may join the team to help you to
explore the requirements for what you’re building. On very large
teams a program manager may be required to coordinate the team
leads on various subteams/squads. You will also see specialists on
DAD teams when generalizing specialists aren’t available – when
your organization is new to agile it may be staffed primarily with
specialists who haven’t yet made the transition to generalizing
specialists.
2. Domain Expert (or subject matter expert). The product owner
represents a wide range of stakeholders, not just end users, so it
isn’t reasonable to expect them to be experts in every nuance in
your domain, something that is particularly true with complex
domains. The product owner will sometimes bring in domain
experts to work with the team, for example, a tax expert to explain
the details of a requirement or the sponsoring executive to explain
the vision for the project.
3. Technical Expert. Sometimes the team needs the help of technical
experts, such as a build master to set up their build scripts, an agile
database administrator to help design and test their database, a
user experience (UX) expert to help design a usable interface, or a
security expert to provide advice around writing a secure system.
Technical experts are brought in on an as-needed, temporary basis
to help the team overcome a difficult problem and to transfer their
skills to one or more developers on the team. Technical experts are
often working on other teams that are responsible for enterprise-
level technical concerns or are simply specialists on loan to your
team from other delivery teams.
4. Independent Tester. Although the majority of the testing is done
by the people on the DAD team themselves, some DAD teams are
supported by an independent test team working in parallel that
 validates their work throughout the life cycle. This independent test
team is typically needed for agility at scale situations within
complex domains, using complex technology, or addressing
regulatory compliance issues.
5. Integrator. For large DAD teams which have been organized into a
team of sub-teams, the sub-teams are typically responsible for one
or more subsystems or features. The larger the overall team,
generally the larger and more complicated the system being built.
In these situations, the overall team may require one or more
people in the role of integrator responsible for building the entire
system from its various subsystems. On smaller teams or in simpler
situations the Architecture Owner is typically responsible for
ensuing integration, a responsibility that is picked up by the
integrator(s) for more complex environments. Integrators often work
closely with the independent test team, if there is one, to perform
system integration testing regularly throughout the project. This
integrator role is typically only needed at scale for complex
technical solutions.

Why So Many Roles?

This is a common question that we get from people familiar with Scrum.
Scrum has three roles – ScrumMaster, Product Owner, and Team Member –
so why does DAD need ten? The primary issue is one of scope. Scrum mostly
focuses on leadership and change management aspects during Construction
and therefore has roles which reflect this. DAD, on the other hand, explicitly
focuses on the full delivery life cycle and all aspects of solution delivery,
including the technical aspects that Scrum leaves out. So, with a larger scope
comes more roles. For example, because DAD encompasses agile
architecture issues it includes an Architecture Owner role. Scrum doesn’t
address architecture so doesn’t include such a role.

Some Important Thoughts About Roles

On a DAD team, any given person will be in one or more roles, an individual
can change their role(s) over time, and any given role will have zero or more
people performing it at any given time. For example, Peter may be in the role
of team member and architecture owner right now but step into the role of
team lead next month when Carol, the existing team lead, goes on vacation.
Roles are not positions, nor are they meant to be. For example, Jane may be
in the role of stakeholder for your project but have the position of Chief
Financial Officer (CFO) within your organization. In fact, although there may
be hundreds of stakeholders of your project none of them is likely to have a
position of “stakeholder.”
Agile de-emphasizes specialized roles and considers all team members equal
– everyone pitches in to deliver a working solution regardless of their job
description. An implication of this is that with the exception of stakeholder
everyone is effectively in the role of team member.
Traditional roles, such as business analyst and project manager, do not
appear in DAD. The goals which people in traditional roles try to achieve, for
example in the case of a business analyst to understand and communicate
the stakeholder needs/intent for the solution, are still addressed in DAD but in
different ways by different roles. There isn’t a perfect one-to-one match
between any given traditional role and a DAD role, but as you will find
in Choose Your WoW! there are reasonable transition strategies. The critical
thing for traditionalists to understand is that because the underlying paradigm
and strategy has changed, they too must change to reflect the DAD approach.
Full Delivery Life Cycles
The focus of DAD is on delivery, although how other aspects of the system life
cycle affect the delivery life cycle are also addressed. As you can see in
Figure 1 a full system/product life cycle goes from the initial idea for the
product, through delivery, to operations and support and often has many
iterations of the delivery life cycle. The following diagram a high-level view of
the system life cycle, indicating the three phases which are the focus of DAD
project teams (DAD product teams typically don’t work in phases) as well as
the phases that are the focus of Disciplined DevOps. The DAD portion is the
(up to) three phases life cycle where you incrementally build a consumable
solution over time.

Figure 1. A high-level view of the delivery life cycle (click to enlarge).

Obviously there’s more to it than what the high-level diagram shows. DAD,
because it’s not prescriptive and strives to reflect reality as best it can, actually
supports several versions of a delivery life cycle. Six versions of the life cycle
are supported:

1. The Agile life cycle. This project life cycle is based on Scrum but
extended so as to provide a streamlined strategy from beginning to
end. It is depicted in Figure 2 and described in the article DAD Life
Cycle – Agile (Scrum Based).
2. The Lean life cycle. This project life cycle is based on Kanban. It
is depicted in Figure 3 and described in the article DAD Life Cycle –
Lean.
 3. The Continuous Delivery: Agile life cycle. This modern agile,
stable-team life cycle is based on Scrum. It is depicted in Figure 4
and described in the article DAD Life Cycle Continuous Delivery:
Agile.
4. The Continuous Delivery: Lean life cycle. This modern agile,
stable-team life cycle is based on Kanban. It is depicted in Figure 5
and described in the article DAD Life Cycle Continuous Delivery:
Lean.
5. The Exploratory/Lean Startup life cycle. This life cycle is based
on Lean Startup strategies. It is depicted in Figure 6 and described
in the article DAD Life Cycle Exploratory (Lean Startup).
6. Program life cycle. This life cycle is for a team of teams. It is
depicted in Figure 7 and described in the article DAD Life Cycle –
Program (Team of Teams).

Figure 2. DAD’s Agile life cycle (click to expand).

Figure 3. DAD's Lean life cycle (click to expand).

Figure 4. DAD’s Continuous Delivery: Agile life cycle (click to expand).

Figure 5. DAD’s Continuous Delivery: Lean life cycle (click to expand).

Figure 6. DAD’s Exploratory (Lean Startup) life cycle

Figure 7. DAD’s Program (team of teams) life cycle
DAD teams will adopt a life cycle that is most appropriate for their situation
and then tailor it appropriately (remember the DA™ principle Context
Counts).For more about this topic, including how to choose between each life
cycle, please read the article A Full Agile Delivery Life Cycle.
Choice is Good: A Goal-Driven Approach
DAD’s goal-driven approach enables DAD to avoid being prescriptive and
thereby be more flexible and easier to scale than other agile methods. For
example, where Scrum prescribes a value-driven Product Backlog approach
to managing requirements DAD instead says that during construction you
have the goal of addressing changing stakeholder needs. DAD then indicates
that there are several issues surrounding that goal that you need to consider,
and there are several techniques/practices that you should consider adopting
to do so. DAD goes further and describes the advantages and disadvantages
of each technique and in what situations it is best suited for. Yes, Scrum’s
Product Backlog approach is one way to address changing stakeholder needs
but it isn’t the only option nor is it the best option in most situations.
In the first DAD book we described goals in a non-visual manner using
tables which explored the advantages and disadvantages of the techniques
associated with an issue. In the second half of 2012 we began expanding on
this approach and developed a way to represent goals in a visual manner
using what we call a goals diagram (see Disciplined Agilists Take a Goal-
Driven Approach for a detailed discussion of the notation).
Let’s work through some examples. Figure 1 depicts the goal diagram
for Explore Scope, a goal that you should address at the beginning of a
project during the Inception phase (remember, DAD promotes a full delivery
life cycle, not just a construction life cycle). Where some agile methods will
simply advise you to populate your product backlog with some initial user
stories the goal diagram makes it clear that you might want to be a bit more
sophisticated in your approach. What level of detail should you capture, if any
(a light specification approach of writing up some index cards and a few
whiteboard sketches is just one option you should consider)? What view types
should you consider (user stories are one approach to usage modeling, but
shouldn’t you consider other views to explore the data or the UI)? Default
techniques, or perhaps more accurately suggested starting points, are shown
in bold italics. Notice how we suggest that you likely want to default to
capturing usage in some way, basic domain concepts (e.g. via a high-level
conceptual diagram) in some way, and non-functional requirements in some
way. There are different strategies you may want to consider for going about
modeling. You should also start thinking about your approach to managing
your work. In DAD we make it clear that agile teams do more than just
implement new requirements, hence our recommendation to default to a work
item stack over Scrum’s simplistic Product Backlog strategy. Finally the goal
diagram makes it clear that when you’re exploring the initial scope of your
effort that you should capture non-functional requirements – such as reliability,
availability, and security requirements (among many) – in some manner.

Figure 1. The goal diagram for the Explore Scope process goal (click to enlarge).
There are several fundamental advantages to taking a goal driven approach
to agile solution delivery, in that it:

 Supports process tailoring by making process decisions explicit.

 Enables effective scaling by guiding you through tailoring your
strategy to reflect the realities of the scaling factors which you face.
 Makes your process options very clear and thereby makes it easier
to identify the appropriate strategy for the situation you find yourself
in.
 Takes the guesswork out of extending agile methods and thereby
enables you to focus on your actual job which is to provide value to
your stakeholders.
 Makes it clear what risks you’re taking on and thus enables you to
increase the likelihood of success.
 Hints at an agile maturity model (this may not be a benefit).
Process Goals
The Disciplined Agile (DA) tool kit takes a goal-driven approach (some people
like to call this a capability-driven approach or even a vector-driven approach).
The purpose of DA’s goal-driven approach is that it guides people through the
process-related decisions that they need to make to tailor and scale agile
strategies, given the context of the situation that they face, to achieve the
outcomes that they desire. This supports the DA principle that Choice is
Good. This is important because every team faces a unique situation. Teams
vary in size, they vary in the way that they are geographically or
organizationally distributed, they vary by the domain and technical complexity
that they face, and they vary by the compliancy issues that are relevant to
them. Furthermore, teams are made up of unique individuals, each of whom
has a set of unique skills and experiences. In short, because each agile team
finds itself in a unique situation the team must find a way to effectively tailor
the way that they work to best face that situation—This reflects the DA
principle Context Counts. DA’s goal-driven strategy is a lightweight approach
to providing advice for such process tailoring.

The Process Goals of Disciplined Agile Delivery

(DAD)
Figure 1 summarizes the delivery-oriented process goals of Disciplined Agile
Delivery (DAD). There are twenty-four goals in total, each of which is
described by a Process Goal Diagram (see Figure 2 below for an example). A
disciplined agile team will consider how to address each goal in a manner that
reflects the situation that they face. Sometimes a goal will be very easy to
address, for example, an established development team may find that they
need to do nothing else to fulfill the Form Team goal. A team that is building a
solution via an architecture they are very familiar with will have very little work
to do to fulfill the Prove Architecture Early goal whereas a team using
technologies that are new to them may have a fair bit of work to do. Different
situations require different approaches.
Figure 1. The process goals of Disciplined Agile Delivery (DAD) (click to enlarge
image)
Each of the three delivery phases (Inception, Construction, and Transition) are
described by specific goals. Some goals, such as Grow Team
Members and Address Risk, are applicable throughout the entire life cycle. All
of the process goal diagrams are available online via the links provided below
in Table 1.
Table 1. The Process Goals of Disciplined Agile Delivery (DAD)

Timing Goals

Inception  Form Team

 Align with Enterprise Direction
 Explore Scope
 Identify Architecture Strategy
 Plan the Release
 Develop Test Strategy
 Develop Common Vision
  Secure Funding

Construction  Prove Architecture Early

 Address Changing Stakeholder Needs
 Produce a Potentially Consumable Solution
 Improve Quality
 Accelerate Value Delivery

Transition  Ensure Production Readiness

 Deploy the Solution

Ongoing  Grow Team Members

 Govern Team
 Leverage and Enhance Existing Infrastructure
 Address Risk
 Evolve WoW
 Coordinate Activities
 Intake Work
 Measure Outcomes
 Organize Metrics
Figure 2. The Explore Initial Scope Process Goal (click to enlarge)
DAD Teams are Enterprise Aware
Enterprise awareness is one of the principles of the Disciplined Agile® (DA™)
tool kit. The observation is that DAD teams work within your organization’s
enterprise ecosystem, as do all other teams. There are often existing systems
currently in production and minimally your solution shouldn’t impact them.
Better yet your solution will hopefully leverage existing functionality and data
available in production. You will often have other teams working in parallel to
your team, and you may wish to take advantage of a portion of what they’re
doing and vice versa. Your organization may be working towards business or
technical visions which your team should contribute to. A governance strategy
exists which hopefully enhances what your team is doing.
Enterprise awareness is an important aspect of self discipline because as a
professional you should strive to do what’s right for your organization and not
just what’s interesting for you. Teams developing in isolation may choose to
build something from scratch, or use different development tools, or create
different data sources, when perfectly good ones that have been successfully
installed, tested, configured, and fine-tuned already exist within the
organization. Disciplined agile professionals will:

 Work closely with enterprise professionals, such as enterprise

architects and portfolio managers.
 Adopt and follow enterprise guidance.
 Leverage enterprise assets, including existing systems and data
sources.
 Enhance your organizational ecosystem via refactoring enterprise
assets.
 Adopt a DevOps Culture.
 Share learnings with other teams.
 Adopt appropriate governance strategies, such as the ones
described here , including open and honest monitoring.
Enterprise awareness is important for several reasons:

 You can reduce overall delivery time and cost by leveraging existing
assets. In other words, DAD teams can spent less time reinventing
the wheel and more time producing real value for their stakeholders.
 By working closely with enterprise professionals DAD teams can get
going in the right direction easily.
 It increases the chance that your delivery team will help to optimize
the organizational whole, and not just the ”solution part” that it is
tasked to work on. As the lean software development movement
aptly shows this increases team effectiveness by reducing time to
market.
DAD Provides a Foundation to Scale Agile
Tactically
Disciplined Agile® Delivery (DAD) provides a pragmatic approach from which
to tailor a solution-delivery process for the context faced by a team. It also
provides a foundation which to scale agile strategies tactically. DAD explicitly
addresses the issues faced by enterprise agile teams that many agile
methodologies prefer to gloss over. This includes how to successfully initiate
agile teams in a streamlined manner, how architecture fits into the agile life
cycle, how to address documentation effectively, how to address quality
issues in an enterprise environment, how agile analysis techniques are
applied to address the myriad of stakeholder concerns, and many more.
Figure 1 overviews the basic strategy for how DAD tactically scales
agile software development. The fundamental observation was that many
organizations were struggling with how to scale agile methods, in particular
Scrum. We feel that the first step was to identify how to successfully develop a
solution from end-to-end. Although mainstream agile methods clearly provide
a lot of great strategies, there really isn’t any sort of glue beyond
consultantware (e.g. hire me and I’ll show you how to do it) to put it all
together. This is where the DA™ tool kit comes in, but that’s only a start as
you also need to tailor your approach to reflect the context in which you find
yourself.
Figure 1. Scaling agile tactically.
DAD provides a better foundation for tactically scaling agile in several ways:

1. DAD promotes a risk-value life cycle. The riskier work early in an

endeavour in order to help eliminate some or all of the risk, thereby
increasing chance of project success. Some people like to refer to
this as an aspect of “failing fast” although we like to put it in terms
of succeeding early or learning fast.
2. DAD promotes self organization enhanced with
effective governance. This is based on the observation that agile
project teams work within the scope and constraints of a larger,
 organizational ecosystem. As a result DAD recommends that you
adopt an effective governance strategy that guides and enables
agile teams.
3. DAD promotes the delivery of consumable solutions over just
the construction of working software. In addition to producing
software DAD teams also create supporting documentation,
they need to upgrade and/or redeploy the hardware the software
runs on, they potentially change the business process around the
usage of the system, and may even affect changes to the
organization structure of the people using the system.
4. DAD promotes enterprise awareness over team awareness.
Please see the earlier section on enterprise awareness.
5. DAD is context-sensitive and goal-driven , not prescriptive.
One process size does not fit all, and effective teams tailor their
strategy to reflect the situation they find themselves in. One of the
DA principles is that Choice is Good – DAD enables choice through
it’s goal driven approach and through supporting multiple life
cycles.
Now let’s examine what it means to scale agile. When many people hear
“scaling” they often think about large teams that may be geographically
distributed in some way. This clearly happens, and people are clearly
succeeding at applying agile in these sorts of situations (see some of the
more evidence we’ve gathered that agile scales , as well as some of the older
evidence ), but there’s often more to scaling than this. Organizations are also
applying agile in compliance situations, either regulatory compliance that is
imposed upon them or self selected compliance (such as CMMI and ISO).
They are also applying agile in a range of problem and solution complexities,
and even when multiple organizations are involved (as in outsourcing). Figure
2 summarizes the potential scaling factors that you need to consider when
tailoring your agile strategy.
Figure 2. Tactical scaling factors
Development Strategies for DevOps
There are several common development practices that support Disciplined
DevOps:

 Canary tests. A canary test is a small experiment where new

functionality is deployed to a subset of end users so you can
determine whether that functionality is of interest to them. This in
turn provides insight to the development team as to the true potential
value of the functionality (if any). For example, an e-commerce
company might believe that a new feature where people can buy two
related items at a discount will help to increase sales. At the same
time they fear this could decrease overall revenue. So they decide to
run a canary test where 5% of their customers are provided this
functionality for a two-week period. Sales and revenue are tracked
and compared against customers not given access to this new
functionality. If a new feature successfully passes a canary test it is
then made available to a wider range of end users (you may choose
to several rounds of canary tests before finally deploying the
functionality to all users). You can think of canary testing as an
extreme form of pilot testing.
 Split tests. A split test, also known as an A/B test, is an experiment
where two or more options are run in parallel so that their
effectiveness can be compared. For example, a bank may identify
three different screen design strategies to transfer funds between
two accounts via an automated teller machine (ATM). Instead of
holding endless meetings, focus groups, or modelling sessions the
bank instead decides to implement all three strategies and put them
into production in parallel. When I use an ATM I’m always presented
with strategy A, when you login you always get strategy B, and so
on. Because the ATM solution is instrumented to track important
usage metrics the bank is able to determine which of the three
strategies is most effective. After the split test is completed the
winning strategy is made available to all users of ATMs.
 Automated regression testing. Agile software developers are said
to be “quality infected” because of their focus on writing quality code
and their desire to test as often and early as possible. As a result,
automated regression testing is a common practice adopted by agile
teams, which is sometimes extended to test-first approaches such as
 test-driven development (TDD) and behavior-driven development
(BDD). The regression test suite(s) may address function testing,
performance testing, system integration testing (SIT), and
acceptance testing and many more categories of tests. Because
agile teams commonly run their automated test suites many times a
day, and because they fix any problems they find right away, they
enjoy higher levels of quality than teams that don’t. Because some
tests can take a long time to run, in particular load/stress tests and
performance tests, that a team will choose to have several test
suites running at different cadences (i.e. some tests run at every
code check in, some tests run at scheduled times each day, some
once every evening, some over the weekend, and so on). This
greater focus on quality is good news for operations staff that insists
a solution must be of sufficient quality before approving its release
into production.
 Continuous integration (CI). Continuous integration (CI) is the
discipline of building and validating a project automatically whenever
a file is checked into your configuration management (CM) system.
As you see in Figure 1, validation can occur via several strategies
such as automated regression testing and even static or dynamic
code and schema analysis. CI enables developers to develop a high-
quality working solution safely in small, regular steps by providing
immediate feedback on code defects.
Figure 1. The continuous integration (CI) process.

 Continuous deployment (CD). Continuous deployment extends the

practice of continuous integration. With continuous deployment,
when your integration is successful in one sandbox your changes
 are automatically promoted to the next sandbox. The CI strategy
running in that environment automatically integrates your solution
there because of the updated source files. As you can see in Figure
2 this automatic promotion continues until the point where any
changes must be verified by a person, typically at the transition point
between development and operations. Having said that, advanced
teams are now automatically deploying into production as well.
Continuous deployment enables development teams to reduce the
time between a new feature being identified and being deployed into
production. It enables the business to be more responsive. However,
when development teams aren’t sufficiently disciplined continuous
deployment can increase operational risk by increasing the potential
for defects to be introduced into production. Successful continuous
deployment in an enterprise environment requires an effective
continuous integration strategy in place in all sandboxes.

Figure 2. The continuous deployment (CD) process.

 Development intelligence. This is the application of data

warehouse (DW)/business intelligence (BI) solutions to provide
insight into how delivery teams are working. The automated team
dashboards provided by many development platforms are a simple
form of development intelligence, a more sophisticated (and useful)
 strategy is to combine information from various development tools to
display it in an integrated dashboard for the team, and more
sophisticated yet is to roll up/combine information from different
delivery teams into a portfolio management dashboard.
Development intelligence is a subset of IT Intelligence.
There are also several common operations-friendly features that developers
with a Disciplined DevOps mindset will choose to build into their solutions:

 Feature access control. To support experimentation strategies

such as canary tests and split tests it must be possible to limit end
user access to certain features. This strategy must be easy to
configure and deploy, a common approach is to have XML-based
configuration files that are read into memory that contain the meta-
data required to drive an access control framework.
 Monitoring instrumentation. Developers with a Disciplined DevOps
mindset will build instrumentation functionality — logging and better
yet real-time alerts — into their solutions. The purpose is to enable
monitoring, in (near) real-time, of their systems when they are
operating in production. This is important to the people responsible
for keeping the solution running, to people supporting the solution, to
people responsible for debugging and fixing any problems, and to
your operational intelligence efforts. Monitoring instrumentation
enables canary tests and split tests in that it provides the data
required to determine the effectiveness of the feature or strategy
under test.
 Feature toggles. A feature toggle is effectively a software
switch that allows you to turn features on (and off) when appropriate.
A common strategy is to turn on a collection of related functionality
that provide a value stream, often described by an epic or use case,
all at once when end users are ready to accept it. Feature toggles
are also used to turn off individual features when it’s discovered that
the feature isn’t performing well (perhaps the new functionality isn’t
found to be useful by end users, perhaps it results in lower sales,
…). Another benefit of feature toggles is that they enable you to test
and deploy functionality into production on an incremental basis.
 Self-testing. One strategy to make a solution more robust, and thus
easier to operate, is to make it self testing. The basic idea is that
each component of a solution includes basic tests to validate that it
can properly run while in production. For example, an application
 server may run basic tests at startup such as verifying the version of
the operating system or of frameworks that it relies on. While the
server is running it might regularly check to see if other
components that it relies on, such as data sources and middleware
services, are available. When a problem is detected it minimally
should be logged, better yet an alert should be posted if intervention
by a person is required, and even better yet the solution should try to
recover from the problem.
 Self-recovery. When a system runs into a problem it should do it’s
best to automatically recover and continue on as before. For
example, if the system detects that a data source is no longer
available it should try to restart that data service. If that fails, it
should record change transactions where possible and then process
them until the data service becomes available again. A good
example of this is an ATM. When ATMs lose their connection to a
bank’s financial processing system they will continue on for a period
of time independently albeit with limited functionality. They will allow
people to withdraw money from their accounts, perhaps putting a
limit on the amount withdrawn to limit potential problems with
overdrawn accounts. People will still be able to deposit money but
will not be able to get a current balance or see a statement of recent
transactions. Self-recovery functionality provides a better experience
to end users and reduces the operational burden on your
organization.
Now that we have overviewed a collection of development practices and
implementation features, let’s explore strategies that streamline your
operations efforts.
SECURITY

Process Blade #20

Disciplined DevOps Layer
Security
Security is one of the process blades of Disciplined
DevOps. The focus of the Security process blade is to
describe how to protect your organization from both
information/cyber/virtual threats and physical threats.
This includes procedures for security governance,
identity and access management, vulnerability
management, security policy management, incident
response, and vulnerability management. As you would
expect these policies will affect your organization’s strategies around change
management, disaster recovery and business continuity, solution delivery,
data management, and vendor management amongst others. For security to
be effective it has to be a fundamental aspect of your organizational culture.
Why is security important? Because security breaches can be devastating.
Here are just a few examples:

 The ransomware attack in May 2021 on Colonial Pipeline that forced

a temporary shutdown of gasoline (petrol) supplies to the east coast
of the United States.
 Russian-backed cyber-espionage attack on thousands of US-based
organizations, including several branches of the US government, in
late 2019 and into 2020.
 The April 2020 theft of over 500,000 Zoom teleconferencing
accounts, including email addresses, passwords, personal meeting
URLs, and host keys.
 In January 2020 over 280 million Microsoft customer records was left
unprotected on the web. Microsoft’s exposed database disclosed
email addresses, IP addresses, and support case details.
 In July 2019 Capital One suffered a data breach where the records
of 100 million credit card applications were stolen.
 In May 2017 Equifax had the personal identification information of
143 million people stolen from them over a three-month period.
 The March 2015 security breach of Slack ‘s database where 500,000
emails and other personal account information was stolen.
  The October 2015 breach of Experian/T-Mobile where the personal
data of 15 million was exposed.
As you see in Figure 1, security is an important part of our overall Disciplined
DevOps strategy. A successful DevOps approach requires you to streamline
the entire flow between delivery and operations, including any activities
required to ensure security.

Figure 1. The workflow of Disciplined DevOps.

Security Mindset
To capture the mindset for effective security, we extend the principles,
promises, and guidelines of the Disciplined Agile® (DA™) mindset with
philosophies.

Figure 1. The Disciplined Agile (DA) mindset for security.

To be effective at security, we embrace these philosophies:

1. Protect the organization. The primary goal of your security efforts

is to enable it to operate safely now an in the future.
2. Collaborate with external organizations. Within the security
community there is constant sharing of information between
organizations, including education about new security threats and
new mitigation strategies.
3. Work closely with teams. Security engineers will be invited to
work with teams throughout your organization to review their work
for security concerns at the earliest feasible moment and in some
cases to help them to secure critical aspects of their work.
4. Transfer security skills and knowledge. Providing people with
coaching and training in security will help to build security
awareness within your organization. Security training should be
provided to all members of your organization, with deeper training
and education provided to IT staff who are directly involved with
development or operations of secure systems.
5. Holistic security. Your security efforts must address the
production of your people; your intangible assets, such as
corporate data and intellectual property (IP); and your physical
assets such as buildings and vehicles.
6. Common security infrastructure. Security engineers will help
teams to identify and adopt appropriate security procedures,
tooling, and technologies. They will also develop and evolve
security guidance for your organization.
Security Roles and Responsibilities
There are several roles that are pertinent to security. Remember that these
are roles, not positions. Small organizations may have a single person taking
on every one of these roles whereas a large organization could have dozens
of fine-grained positions. Remember, context counts. We define the following
key roles for Disciplined Agile® (DA™) security:

 Security engineer. Helps teams to understand security

fundamentals, to act in such a way as to help secure
your organization’s tangible and intangible assets, and to produce
secure offerings for their customers. Will help to build a secure
operational infrastructure and to evaluate and potentially adopt
security tooling — including but not limited to testing tools, code
analysis tools, development tool kits, and security infrastructure
products. Security engineers will work with external security experts
and practitioners to keep abreast of evolving security threats.
 Security manager. A functional manager who leads the security
team. The will often work with enterprise architects as a security
expert/stakeholder, with executive leadership to help them
understand the implications of security, and with external security
experts and practitioners to keep abreast of evolving security threats.
Security Practices
The following process goal diagram overviews the potential activities
associated with disciplined agile security. These activities are performed by,
or at least supported by, your security team.
Figure 1. The Security process goal diagram (click to enlarge)
The process decision points that you need to consider for implementing
effective security are:

 Ensure security readiness. How do you ensure that your

environment has been built to withstand the evolving security threats
that you face?
 Enable security awareness. How do you help your staff to become
knowledgeable about security threats, how to avoid attacks, and how
to deal with them when they occur?
 Monitor security. How do you identify when you are under attack
(for most organizations the answer is constantly) and more
importantly how you’re being attacked?
 Respond to threats. When an attack occurs what will you do to
address it?
 Secure physical assets. How will you protect physical assets such
as buildings, vehicles, and equipment? By implication, how will you
ensure the security of your people?
 Secure IT perimeter. How will you secure access to your IT
systems?
 Secure the network. How will you ensure the security of digital
communications?
 Secure IT endpoints. How will you secure access to devices such
as phones, workstations, and other I/O devices?
 Secure applications. How will you address security within the
applications/systems of your organization?
 Secure data. How will you ensure the validity and privacy of the data
within your organization?
 Govern security. How will you motivate, enable, and monitor
security activities within your organization?
Security Strategies for DevOps
There are several security strategies that support Disciplined DevOps:

1. Build “rugged software.” Rugged software is a recent movement

in the IT industry that recognizes the need for robustness, quality
and security. An implication of this is that software-based solutions
should have appropriate security control features built in, including
but not limited to access control, monitoring, validated input, and
sanitized data transfers.
2. Automated separation of duties (SoD). The need for regulatory
compliance, particularly around security, is very common.
Standards such as Payment Card Industry Data Security Standard
(PCI DSS) or ISO 27001 typically require separation of duties
(SoD). Although much is made of the issue that the person who
develops something should be different than the person who
deploys, a continuous deployment (CD) strategy where things are
deployed by your tools (and appropriate logging occurs) can still
pass a compliancy audit. In fact, this level of automation tends to
provide better SoD control than what you find when people are
involved with manually running scripts.
3. Collaborative security engineers. As with other enterprise IT staff
— such as enterprise architects, asset engineers, or data
managers — security engineers can and should collaborate closely
with the teams they support. They should actively strive to transfer
their skills and knowledge whenever they can so as to enable
teams to be as self-sufficient as possible.
4. Exploit testing. Also known as penetration testing, the goal is to
simulate common ways that attackers can exploit potential security
gaps. It is common to have such testing tools as part of your
continuous integration (CI) strategy.
5. Real-time security monitoring. Your operational systems should
be monitored in real-time for potential attacks/exploits. This is an
important aspect of your operational intelligence.
Security Terminology
This page lists definitions for common security terms used throughout the
Disciplined Agile® (DA™) security process blade:

 Access control. This is the process of providing access to systems

and data at a granular level. Access is typically provided at per-user,
per-group, and per-resources levels.
 Cyber security. Strategies for safeguarding computers, networks,
programs, and data from unauthorized access or hackers for
exploitation. Also known as information security, info security, or
infosec.
 Data protection. The process of safeguarding information so it
doesn’t fall into the wrong hands. Also known as data privacy or
information privacy.
 Physical security. The protection and safeguarding of personnel
and your organization’s physical assets from physical actions and
events that could cause serious loss or damage. This includes
protection from fire, flood, natural disasters, burglary, theft,
vandalism and terrorism.
 Private data. Data that is used to identify you, such as your name,
address, phone number, or government identification number.
 Threat. An event or action that has the potentially to cause negative
consequences your organization.
DATA MANAGEMENT

Process Blade #21

Disciplined DevOps Layer
Data Management
According to the Data Management Body of
Knowledge, data management is “the development,
execution and supervision of plans, policies, programs
and practices that control, protect, deliver and enhance
the value of data and information assets.” Unfortunately
the implementation of data management strategies
tends to be challenged in practice due to the traditional,
documentation-heavy mindset. This mindset tends to
result in onerous, bureaucratic strategies that more often than not struggle to
support the goals of your organization.
Having said that, data management is still very important to the success of
your organization. The Disciplined Agile (DA) tool kit’s Data
Management process blade promotes a pragmatic, streamlined approach to
data management that fits into the rest of your organizational processes – we
need to optimize the entire workflow, not sub-optimize our data management
strategy. We need to support the overall needs of our organization, producing
real value for our stakeholders. Disciplined agile data management does this
in an evolutionary and collaborative manner, via concrete data management
strategies that provide the right data at the right time to the right people.
There are several reasons why a disciplined agile approach to data
management is important:

1. Data is the lifeblood of your organization. Without data, or more

accurately information, you quickly find that you cannot run your
business. Having said that, data is only one part of the overall
picture. Yes, blood is important but so is your skeleton, your
muscles, your organs, and many other body parts. We need to
optimize the whole organizational body, not just the “data blood.”
2. Data is a corporate asset and needs to be treated as such. The
traditional approach to data management has unfortunately
resulted in data with sketchy quality, data that is inconsistent,
incomplete, and is often not available in a timely manner.
Traditional strategies are too slow moving and heavy-weight to
address the needs of modern, lean enterprises. To treat data like a
real asset we must adopt concrete agile data quality techniques
such as database regression testing to discover quality problems
 and database refactoring to fix them. We also need to support
delivery teams with lightweight agile data models and agile/lean
data governance .
3. People deserve to have appropriate access to data in a timely
manner. People need access to the right data at the right time to
make effective decisions. The implication is that your organization
must be able to provide the data in a streamlined and timely
manner.
4. Data management must be an enabler of DevOps. As you see in
Figure 1, Data Management is an important part of our
overall Disciplined DevOps strategy. A successful DevOps
approach requires you to streamline the entire flow between
delivery and operations, and part of that effort is to evolve existing
production data sources to support new functionality.

Figure 1. The workflow of Disciplined DevOps.

Data Management Mindset
To capture the mindset for effective data management, we extend the
principles, promises, and guidelines of the Disciplined Agile® (DA™) mindset
with philosophies.

Figure 1. The Disciplined Agile (DA) mindset for data management.

To be effective at data management, we embrace these philosophies:

1. Work closely with others. Data professionals need to actively

work with others throughout your organization, helping them to
leverage data in their decision making. They also need to work
closely with delivery teams to produce and work with high-quality
data sources.
2. Transfer skills and knowledge. The aim is to enable others to
better understand and become more effective at working with data.
3. Usage-driven data. Traditional strategies promote a data-driven
approach where their design efforts focused on data structure and
semantics first, with the belief that usage would follow. This tended
 to result in data sources that weren’t readily usable by their
intended audience. The agile strategy is to start with an
understanding of what people want to do and then design data
sources to support that.
4. Timely, secure, and auditable intelligence. When people are
making decisions, they need easy access to the right data at the
right time. Having said that, they should only have access to the
data that they are allowed to and no more – this is referred to as
the principle of least access. Data activities must also be auditable
– we should know where data comes from, when and how it
changes, and who and when someone accessed it in the case of
private/secure data.
5. Fix the source. Every organization has technical debt, poor quality
assets, that hampers their ability to operate effectively. Technical
debt in data sources includes inaccurate data, inconsistent data,
poorly formatted data, and many other problems. Traditional
strategies of dealing with these problems were to transform the
data as you bring it into your data warehouse (DW) environment or
into other systems, a strategy that proves to be expensive and
inconsistent over time. A better option, albeit harder in the short
term, is to fix the problems at the source via data
refactoring strategies.
6. Model to understand. Models are very good at communicating
and capturing high-level concepts but rather poor at capturing
details. Visual models showing major concepts - such as entity
types and the relationships between them on conceptual diagrams
or systems and data flow on architectural diagrams – prove useful
in practice because they show you the lay of the land. The
challenge is that people tend not to keep the details up to date and
very often don’t even bother to read them anyway. The implication
is that we need something else to capture the details, which is what
executable tests are good at doing.
7. Test to specify. Strategies such as Acceptance Test-Driven
Development (ATDD) and Sustainable Test-Driven Development
(STDD) are quickly becoming the norm for exploring and capturing
detailed requirements and design specifications respectively.
Supported by automation, this promotes greater quality and ease of
change while providing superior specifications for future efforts.
The tests form executable specifications and thus add real value to
 the delivery teams because they validate their work, and are
therefore much more likely to be kept up to date than static
documentation.
8. Automate, automate, automate. Automated checking of the work
of delivery teams via ATDD and STTD is enabled via continuous
integration (CI) and continuous deployment (CD) technologies.
These strategies have their roots in software development, but they
are also being applied in the data realm and are contributing to
improving overall data quality and decreasing the time to safely
deploy database updates into production. In parallel, automation is
common in the data warehouse (DW)/business intelligence (BI)
environment to evolve from batch processing to full real-time
processing across the entirety of your data infrastructure. See
the Accelerate Value Delivery process goal for automation options.
Data Management Roles and
Responsibilities
There are several roles that are pertinent to data management. Remember
that these are roles, not positions. Small organizations may have a single
person taking on every one of these roles whereas a large organization could
have dozens of fine-grained positions. Remember, context counts. We define
the following key roles for Disciplined Agile® (DA™) data management:

 Database Administrator (DBA). Operates, supports, and evolves

existing legacy data sources. Collaborates with delivery teams,
ideally as a member of those teams, to ensure that data sources are
developed and evolved in a quality manner.
 Data analyst. Explores existing data sources to understand their
structure, content, and semantics. Interprets data from multiple
sources and turns it into information that can be used by decision
makers within your organization.
 Data manager. A functional manager who leads the data
management team, guiding the data-oriented activities with the
organization. Often leads the long-term refactoring of legacy data
sources to help pay down data-oriented technical debt. Collaborates
with others within your organization to ensure that data quality is
maintained and enhanced across disparate data sources, leading
the development of any data-oriented guidance.
Data Management Workflow – External
Key tenets of agile and lean are to work collaboratively and to streamline your
workflow respectively. In Figure 1 we see that data management is a
collaborative effort that has interdependencies with other Disciplined Agile®
(DA™) process blades and the solution delivery teams that data management
is meant to support. This can be very different than the current traditional
strategies. For example, with a DA approach, the data management team
works collaboratively with the delivery teams, IT operations , and release
management to evolve data sources. The delivery teams do the majority of
the work to develop and evolve the data sources, with support and guidance
coming from data management. The delivery teams follow guidance from
release management to add the database changes into their automated
deployment scripts, getting help from operations if needed to resolve any
operational challenges. Evolution of data sources is a key aspect
of Disciplined DevOps. This is very different than the typical traditional
strategy that requires delivery teams to first document potential database
updates, have the updates reviewed by data management, then do the work
to implement the updates, then have this work reviewed and accepted, then
work through your organization’s release management process to deploy into
production.
Figure 1. Successful Data Management is collaborative.
Data Management Workflow – Internal
Now let’s drill down and see what the workflow for a Disciplined Agile® (DA™)
approach to data management looks like. First, notice how all of the activities
depicted in Figure 1 are collaborative in nature. This is shown via the
additional roles beside the activities or interacting with them. Second, how you
address these activities will vary depending on the situation that you face. Our
aim here, is to explore a baseline from which you can potentially start, but
you’ll need to tailor it to address your actual situation.

Figure 1. Internal workflow for Data Management.

Let’s work through each activity one at a time:

1. Evolve organizational data artifacts. Organizational data

management artifacts may include data models, including but not
limited to a high-level conceptual model for your enterprise
(typically a view within your enterprise architecture); metadata
 describing common concepts, entity types, and data elements
within your organization; master data for critical entity types; and
master test data to support database testing across multiple
delivery teams. Data managers will work closely with product
managers to understand their overall vision for their products and
the organization as a whole to ensure that their data management
strategy aligns with your product roadmaps. Data managers will
also work closely with enterprise architects to ensure that data
concerns are addressed appropriately in your organization’s
architecture and that your data management strategy aligns with
your technology roadmap. These collaborations are often
accomplished through regular working sessions that are often
called in an as-needed, impromptu manner.
2. Enable delivery teams. Data managers work closely with delivery
teams to train, educate, and coach them in data skills. The overall
strategy is to enable delivery teams to be as self-sustaining as
possible when it comes to data-related activities, to offload as much
of the grunt work as possible to enable the teams to become more
reactive and to allow data managers to focus on value-added
activities such as evolving organizational data artifacts and
guidance. The implication is that data managers will need to
develop and maintain a training program around fundamental data
skills (computer-based training often proves sufficient for this) such
as data modeling, database design, and data security. They will
also need coaching skills so that they can work side by side with
delivery teams to help them to learn these critical skills.
3. Support delivery teams. Delivery teams will need help from time
to time to address hard database design problems, to gain access
to and to understand legacy data sources, and to obtain and/or
generate test data. The DA strategy is for data managers to work
collaboratively with the delivery teams to do so, to get directly
involved with the teams to do the actual work (and to transfer skills
while doing so). In a pragmatic take on the sage advice around
teaching a man to fish, the goal should be to teach the delivery
team how to fish but while doing so provide enough fish to sustain
them until they become self-sufficient.
4. Evolve and support data guidance. Delivery teams should follow
your organizational conventions around data (and around security,
and user experience, and so on). The data management team is
the source of this data guidance, which should address
 fundamental issues such as data naming conventions, data
security conventions, and your data architecture and design
patterns. This guidance should be developed and evolved
collaboratively with the delivery teams themselves to ensure that
the guidance is understandable, pragmatic, and accepted by the
teams.
5. Support and monitor operations. Data managers will work
closely with operations managers to monitor your existing
production data sources (operations managers monitor far more
than just data sources of course). Ideally this monitoring is fully
automated with dashboard technology used to render critical
operational intelligence in real time. Note that operational database
administration activities are addressed by the IT operations process
blade.
6. Improve data quality. Data managers will guide and collaborate in
the data quality improvement efforts of your database
administrators (DBAs) and operations engineers as well as your
delivery teams. This is depicted below in Figure 2. They will monitor
your automated database regression testing efforts (ideally a
continuous effort) and your ongoing data source evolution efforts
(implemented as database refactorings) that occur on a daily basis.
Your data managers will oversee the long-term aspects of
database refactoring, in particular the retirement of deprecated
database schema and the scaffolding required during the
deprecation periods for the appropriate refactorings.

Figure 2. A collaborative approach to data quality (click to enlarge image).

Let’s examine Figure 2 in a bit more detail. Common data quality activities are
indicated towards the top (the blue bubbles). Immediately below each activity
is the primary role(s) responsible for it – notice how in an agile environment
data quality is so important that it isn’t left to just people in data roles. Below
the primary roles, in some cases, we indicate secondary roles that may be
involved in assisting with, or supporting, the activity.
Data Management Practices
Figure 1 depicts the process goal diagram overviewing the potential activities
associated with Disciplined Agile® (DA™) data management. These activities
are often performed by, or at least supported by, a data management team.
Figure 1. The process goal diagram for Data Management.
The decision points that you need to address with your data management
strategy are:

1. Consolidate data. A fundamental function provided by data

management is to gather data, from various sources in various
forms. This data is then turned into potential intelligence (actionable
information) to aid in decision making.
2. Provide intelligence. Data has no inherent value until it is used by
someone, or some software, to make a decision. Data
management provides appropriate access to data, and access to
tools to manipulate and communicate it, to turn it into intelligence
(actionable information).
3. Ensure data security. This is a very important aspect of security in
general. The fundamental issue is to ensure that people get access
to only the information that they should, and that information is not
available to people who shouldn’t have it. This is called the
principle of “least access.” Data security must be addressed at both
the virtual and physical levels.
4. Analyze data. Existing data sources, and the data that they
contain, must be explored and examined so that the data may be
understood and hopefully be turned into intelligence.
5. Evolve data assets. There are several categories of data that
prove to be true assets over the long term: Test data that is used to
support your testing efforts; reference data, also called lookup data,
that describes relatively static entities such as states/provinces,
product categories, or lines of business; Master data that is critical
to your business, such as customer or supplier data; Meta data,
which is data about data. Traditional data management tends to be
reasonably good at this, although can be heavy handed at times
and may not have the configuration management discipline that is
common within the agile community.
6. Specify data assets. At the enterprise level your models should be
high level – lean thinking is that the more complex something is,
the less detailed your models should be to describe it. This is why it
is better to have a high-level conceptual model than a detailed
enterprise data model (EDM) in most cases. Detailed models, such
as physical data models (PDMs), are often needed for specific
legacy data sources by delivery teams.
 7. Improve data quality. There is a range of strategies that you can
adopt to ensure data quality. The agile community has developed
concrete quality techniques – in particular database testing,
continuous database integration, and database refactoring – that
prove more effective than traditional strategies. Meta data
management (MDM) proves to be fragile in practice as the
overhead of collecting and maintaining the meta data proves to be
far greater than the benefit of doing so. Extract transform and load
(ETL) strategies are commonplace for data warehouse
(DW) efforts, but they are in effect band-aids that do nothing to fix
data quality problems at the source.
8. Refactor legacy data sources. Database refactoring is a key
technique for safely improving the quality of your production
databases. Where delivery teams will perform the short-term work
of implementing the refactoring, there is organizational work to be
done to communicate the refactoring, monitor usage of deprecated
schema, and eventually remove deprecated schema and any
scaffolding required to implement the refactoring.
9. Govern data. Data, and the activities surrounding it, should be
governed within your organization. Data governance is part of your
overall governance efforts.
Looking at the diagram above, traditional data management professionals
may believe that some activities are missing. These activities may include:

 Enterprise data architecture. This is addressed by the enterprise

architecture process blade. The DA philosophy is to optimize the
whole. When data architecture (or security architecture, or network
architecture, or…) is split out from EA it often tends to be locally
optimized and as a result does not fit well with the rest of the
architectural vision.
 Operational database administration. This is addressed by the IT
operations process blade, once again to optimize the operational
whole over locally optimizing the “data part.”
As you can see, we’re not talking about your grandfather’s approach to data
management. As Figure 2 summarizes, organizations are now shifting from
the slow and documentation-heavy bureaucratic strategies of traditional Data
Management towards the collaborative, streamlined, and quality-driven
agile/lean strategies that focus on enabling others rather than controlling
them.
Figure 2. Shifting from bureaucracy to enablement in Data Management.
How to Adopt Disciplined Agile Data
Management
We’ve found that the following strategies are critical to your success when
adopting a Disciplined Agile® approach to Data Management:

1. Surface your challenges. You need to have an honest

conversation about the effectiveness of your current approach to
data management. This conversation must be driven from an
organizational viewpoint so as to take into account stakeholder
needs. We’ve found that a very effective way to do this is value
stream mapping (VSM) sessions to reveal the true efficiency and
quality levels of your critical data management processes. This will
not be pleasant for anyone who still believes in traditional data
management practices, but it is vital to your success that everyone
recognizes that you need to improve.
2. Expect better. One of the reasons why the data management field
has languished for as long as it has is because the rest of the IT
community allowed them to. For the most part we accepted their
claim that they needed to work in a slow and onerous manner, that
eventually they’d address our organization’s data quality challenges
through some form of bureaucratic magic that only they
understood.
3. Invest in your staff. Traditional data professionals tend to be
overly specialized, often focusing on one aspect of data
management such as logical data modeling, meta data
management, data traceability, and so on. Not only does this result
in bureaucratic, drawn-out processes but many of these specialties
are no longer required when you’ve adopted pragmatic, quality-
focused agile strategies. To be effective you need T-
skilled generalizing specialists, and that requires you to invest in
training and long-term coaching to help people to modernize their
skillset.
4. Hire agile coaches with deep experience in both Agile and
Data management. Someone with agile coaching experience
alone will struggle to gain the trust of experienced data
management people, and a data management coach without deep
 agile experience will struggle to help people to overcome their
deep-rooted traditional belief system.
Improving your data management processes and organization structure to
support a Disciplined Agile way of working is a daunting task. Along with
evolving your governance strategy it is likely the hardest part of any
organizational transformation, but it is one that you cannot ignore. Effective
data management is critical to your success as an organization.
Data Management Strategies for DevOps
There are several data management strategies that support Disciplined
DevOps:

 Data and information guidelines. A straightforward way to promote

greater consistency in the development and application of data and
information sources is to have common guidance that teams will
adopt and then follow. This guidance, including both standard
policies and guidelines, will need to be defined, supported, and
evolved over time in a collaborative and open manner.
 Quality data sources. Your production data sources, including files,
databases, and data feeds, should be high quality assets that are
easy to work with. When it comes to data sources of record it is
particularly important for them to be of high quality so that they are
easy to work with and evolve. Unfortunately this is often little more
than fanciful thinking in many organizations. With a Disciplined
DevOps mindset teams realize that they should be very careful
about increasing the technical debt within their data sources, and
more importantly invest in the effort to pay down any technical debt
that they find.
 Self-service business intelligence (SSBI). Business intelligence
(BI) is the creation, support, evolution, and operation of data
warehouse (DW)/BI solutions that support decision making across
your organization. SSBI is BI where end users have access to the
tools and data they require to support their own data analysis and
decision making.
RELEASE MANAGEMENT

Process Blade #22

Disciplined DevOps Layer
Release Management
The release management process blade encompasses
planning, coordinating, and verifying the deployment of
IT solutions into production. Release management
requires collaboration by the IT delivery team(s)
producing the solutions and the people responsible for
your organization’s operational IT infrastructure. In the
case of organizations with a “you build it, you run it”
DevOps strategy these people may be one in the same,
although even in these situations you will often find a group of people
responsible for governing the overall release management effort.
There are several reasons why enterprises adopt release management
strategies:

 They have a complex operational infrastructure. The greater the

complexity of your operational infrastructure the greater the risk that
the release of new functionality into production will break something,
hence the greater need for release management. Operational
infrastructures become complex when there are many technologies
in place, when there are different versions or configurations of those
technologies, and when solutions are highly coupled to one another.
Ideally you should strive to pay down this technical debt .
 There are many delivery teams working in parallel. Your
operational infrastructure is a shared environment, or more
accurately a collection of shared environments, that your IT delivery
teams deploy into. As the number of delivery teams rises, the greater
the chance that their release efforts will conflict with one another.
 IT delivery teams need help to release their solutions into
production. Your IT delivery teams, particularly new ones, may not
have much experience deploying solutions into your operational
environment. Your release management team can coach your IT
delivery teams in effective release strategies, can guide them in
ensuring that their solutions are production ready, and can help in
the planning and coordination of their release efforts.
 Release management must be an enabler of DevOps. As you see
in Figure 1, release management is an important part of our
overall Disciplined DevOps strategy. A successful DevOps approach
 requires you to streamline the entire flow between delivery and
operations, and part of that effort is to coordinate and support the
release/deployment efforts of the delivery teams.

Figure 1. The workflow of Disciplined DevOps.

Release Management Workflow – External
Release management is an important part of Disciplined DevOps, and Figure 1 depicts
the high-level workflow that release management is involved with. One interesting
aspect of this diagram is that it shows that many IT delivery teams, which may be
following different lifecycles or even tailored versions of one of the Disciplined Agile®
lifecycles, potentially feed production ready releases into the release management
process. In some organizations you may have a separate release management team
doing this work. Other organizations, particularly those that are well on the way to
adopting a DevOps strategy, will often choose to have the delivery teams themselves
do the release management work via a “you build it, you release it, you run it” mindset.
For now, our focus is on the activities surrounding release management, not on the
potential organizational structures to support it.

Figure 1. The external workflow of release management.

The following table summarizes the workflows depicted in the diagram.

Process Blade Workflow with Release Management

Business Release management safely deploys consumable
Operations solutions into your operational environment(s).

Continuous Your continuous improvement efforts should result in

Improvement improvement suggestions gleaned from other teams that
release management can learn from. Similarly, your
release management efforts may also generate learnings
that other may benefit from.

Data Your release management efforts will generate create

Management data, such as what was released, when it was released,
where it was released to, and how much effort was
required that can be used for decision making purposes
elsewhere. Similarly, your release management efforts
will benefit from intelligence gleaned from other
activities within your organization. For example, if a
platform is currently down (perhaps it is being
upgraded), then you would likely be blocked from
deploying into that environment until it is available.

Disciplined Delivery teams will produce new releases of the

Agile Delivery consumable solutions that they are working on when
(DAD) they believe they are ready to be deployed.
Because delivery teams work in different manners, it
implies that release management professionals (if any)
will need to be sufficiently flexible to work with these
teams in manners that reflect their chosen strategies.

Enterprise Roadmaps & Models

Architecture
The enterprise architects will produce roadmaps and
models that will reflect the current operational
environment as well as the expected direction that it will
head in. This information will be used as input into
decisions regarding any technology strategies to support
release management activities.
Governance The governance team will provide guidance to all
teams, including anyone performing release
management activities.

IT Operations Release management safely deploys consumable

solutions into your operational environment(s).
Release Management Practices
Some methods will choose to prescribe a single approach to Release Management, but the
Disciplined Agile® (DA™) tool kit promotes an adaptive, context-sensitive strategy. DA does this
via its goal-driven approach that indicates the process decision points that you need to consider,
a range of techniques or strategies for you to address each decision point, and the advantages
and disadvantages of each technique. Figure 1 shows the goal diagram for the release
management process blade.

Figure 1. The process goal diagram for release management (click to enlarge).
The process factors that you need to consider for release management are:

 Plan release schedule. Your organization’s overall release schedule

needs to be planned and communicated. Many organizations have
blackout periods where teams are not allowed to deploy into production
(for example, many retail organizations will not allow non-critical
production releases near local holidays). There are many strategies
that organizations may choose to adopt when it comes to scheduling
releases, including release trains, release streams, ad-hoc releases,
and release windows.
 Schedule solution release. The release of an individual delivery
team’s work needs to be scheduled so that it does not conflict with the
 releases of other teams who want to deploy into the same operational
environment.
 Manage infrastructure configuration. The release management team
will work closely with your operations team, in fact they are often
members of your operations team, to perform configuration
management of your operational environment. To safely deploy into
production you must know what is currently there and how those
various elements depend on each other. The more complex your
operational infrastructure, and the more delivery teams you have, the
more important this process factor becomes.
 Determine production readiness. Part of the release process is to
verify that the solution is ready to be deployed and that the
stakeholders are ready to have it deployed to them. The bigger and
more infrequent your releases, the more this becomes an issue.
 Support delivery teams. The release management team, when a
separate one exists, will work closely with the delivery teams to help
them deploy successfully. This help may take the form of coaching the
team on deployment techniques, on planning, and even working with
them to automate their deployments. The release management team
will often help with deployment testing, the verification after the fact that
a deployment was in fact successful.
 Govern releases. Your organization’s overall release efforts should be
governed, ideally with the aim to streamline those efforts as much as
possible. This governance will include the development of policies and
guidelines pertaining to the release process as well as the identification
and collection of pertinent metrics. This is part of your
overall governance efforts.
It is important to note that most, if not all, of these activities can and should be
automated. Automation is a key enabler of Disciplined DevOps.
Release Management Strategies for DevOps
There are four general release scheduling strategies that potentially support
DevOps. These strategies, from least effective to most effective, are:

1. Release windows (slow cadence). A release window is a period

of time during which one or more teams may release into
production. A release slot is subset within that release window (and
may be the entire window) during which a team may deploy their
solution into production. For example, your organization may have
a policy that production releases occur between 1am and 5am on
Saturday evenings (the release window) and that up to four
releases may occur during that window (the release slots). In lean
terms, a release slot is effectively a Kanban card that allows a team
to deploy. Release windows tend to align with periods where
system usage is lower, although in the modern world of global 24/7
operations these periods have all but disappeared. With a slow
cadence approach to this strategy the release windows occur far
apart, as seldom as once a week or even longer. The advantages
of this approach are that it provides a consistent release cadence
to business stakeholders and it provides consistent release date
targets for delivery teams. The primary disadvantage with slow
cadence release windows is that they become bottlenecks for
release management processes that need to support multiple
teams. There are only so many release slots available during each
window and this number can be easily exceeded, forcing teams to
aim for a future release window. This problem becomes
exacerbated when teams start to move to a continuous delivery
strategy.
2. Release train. The idea with a release train is that every team
involved with that “train” has the same release cadence — for
example this train releases once a quarter, or once a month, or
even once a week. This strategy is commonly used in large
programs, or teams of teams, where the individual teams are each
working on part of a larger whole. Having the common drumbeat of
a release train provides a consistent release schedule for
stakeholders and serves as a rallying point for development teams.
The train metaphor works quite well in practice. If your team misses
the release date, if you miss the train, then the train goes on
without you and you need to wait for space on the next on.
 Dependencies are also respected. For example, if several
components need to ship together they must all go on the same
train (similar to a family taking a trip together). The primary
disadvantage is that development teams are constrained to a
common release schedule, making it difficult to support lean or
continuous delivery strategies. A potential disadvantage is that
release trains may also suffer from the bottleneck problems of slow
cadence release windows.
3. Release windows (quick cadence). To support continuous
deployment, particularly across many delivery teams, you will need
a large number of release slots. The implication is that you will also
likely need more release windows more often. The advantage of
quick cadence release windows is that they are less likely to suffer
from the bottleneck challenges associated with slow cadence
release windows and release trains.
4. Continuous release availability. With this approach delivery
teams are allowed to release their solutions into production
whenever they need to. In many ways this is simply an extension of
the release window strategy to be 24/7. This is the only strategy
that truly supports continuous delivery. To make it work a host of
DevOps practices are required, such as fully automated
deployment, fully automated regression testing, feature toggles,
self-recovering components, and many others are required.
Our experience is that most enterprises today employ a slow cadence release
window approach although are starting to evolve into the quick cadence
version of this strategy. This is usually motivated by the adoption of agile
techniques by solution delivery teams and more often than not by continuous
delivery practices. We also see large programs take a release train approach,
a strategy pioneered in the 1990s by large software companies such as
Microsoft and Rational that sold software suites comprised of many products
that needed to be shipped together. In recent years the OpenUP and SAFe
frameworks have popularized the release train strategy. The strategy of
continuous release availability is commonly used in advanced DevOps
organizations such as Etsy and Amazon.
In addition to the release scheduling strategies listed above, there are several
technical release management strategies that support DevOps:

 Integrated deployment planning. From the point of view of

development teams, deployment planning has always required
 interaction with an organization’s operations and release
management staff; in some cases, via liaison specialists within
operations often called release engineers. When you adopt a
Disciplined DevOps mindset, you quickly realize the need to take a
cross-team approach to deployment planning due to the need for
operations staff to work with all of your development teams. This isn’t
news to operations staff, but it can be a surprise to development
teams accustomed to working in their own, siloed environments
(luckily this strategy is built into DAD’s Accelerate Value Delivery
process goal). If your team is not doing this already, you will need to
start vying for release slots in the overall organizational deployment
schedule.
 Standard development and testing environments based on
production. Development teams know that the greater the
consistency between their development, testing, and production
environments the easier it is to test and deploy. In multi-team
environments the implication is that this will result in de facto
standardization of many aspects of your environments. Developers
may choose different development tools, but aspects of the
infrastructure such as operating systems, application servers,
middleware, databases and so on will become consistent over time
to streamline the overall release process.
 Release service streams. A key tenant of DA is that every team is
unique, and an implication of that is that some teams will need more
help than others. Teams will produce different levels of quality, they
will have different amounts of automation, they will have different
release cadences, and so on. As a result your release management
strategy needs to be flexible enough to address these different
situations. One way to do so is to offer different server streams, or
service levels as it were, to solution delivery teams. For example,
you may have a basic release management service stream where
release management engineers actively help delivery teams to
deploy their solutions into production and even help them to start
automating some of their processes. At the other end of the
spectrum you may have a continuous delivery service stream for
delivery teams that have fully automated their testing and
deployment processes and that can be trusted to successfully deploy
on their own. And of course you could have several other service
streams between those two extremes. The advantage of this
 approach is that it is very flexible albeit at the cost of slightly greater
scheduling complexity.
 Release blackout periods. Some organizations have periods of
time where they choose not to release new functionality into
production unless it is absolutely critical. These blackout periods
typically occur during high-volumes of business transactions. For
example, many North American retail companies will have blackout
periods between mid-November and early January for the holiday
sales seasons. Many organizations will have blackout periods near
the end of their fiscal years to enable them to focus on the process
required to close out the year.
 Shared release practices. Although this is really a process
improvement issue, it’s worthwhile to point out that whoever is
involved with release management should actively strive to share
effective practices between teams. Sharing learnings across teams
is an important aspect of enterprise awareness.
Release management is an important part of your Disciplined
DevOps strategy. Having said that, many IT departments are still in their early
days of adopting a DevOps approach yet still effective release management.
The implication is that the way that you approach release management will
vary depending on how far down the DevOps adoption path you are. For
example, with no DevOps in place at all your release management activities
are likely to be performed by a team that is separate from your delivery teams.
When you are in the process of adopting a DevOps mindset , release
management is likely to be a collaborative effort between the delivery teams
and the release management team. When you have fully adopted DevOps
strategies release management is mostly performed by the delivery teams
themselves.
SUPPORT

Process Blade #23

Disciplined DevOps Layer
Support
Support is a process blade of Disciplined DevOps. Your
support activities, sometimes called Help Desk or End-
User Support, focus on helping customers to work with
the solutions produced by your delivery teams. Ideally
your solutions should be designed so well that end
users don’t need anyone to help them but unfortunately
it doesn’t always work out that way. In many ways your
support strategy is your “last line of defense” in your
efforts to Delight Customers.
There are several reasons why it is important to offer support to your
users/customers:

 To provide a point, or points, of contact for people to gain assistance

 To provide a way for people to get their questions answered
 To help trouble-shoot or solve problems people are having with your
offerings
As you see in Figure 1, support is an important part of our overall Disciplined
DevOps strategy. A successful DevOps approach requires you to streamline
the entire flow between delivery and operations, and part of that effort is to
coordinate interaction between customers and your organization, including
your delivery teams.
Figure 1. The workflow of Disciplined DevOps.
Support Mindset
To capture the mindset for effective support, we extend the principles,
promises, and guidelines of the Disciplined Agile® (DA™) mindset with
philosophies.

Figure 1. Support Mindset

The following philosophies describe a Disciplined Agile Mindset for Support:

1. Avoid problems to begin with. The most effective support calls

are the ones that you didn’t need to have in the first place. You can
reduce the number of problems that people encounter through
better user experience (UX) design during development and by
building a trustworthy infrastructure. It is critical to recognize that
any money spent on support is addressing failures as opposed to
adding value.
2. Solve the problem. When end users decide to contact your
support help desk, the support engineer should take responsibility
for the problem, explain what happened and what the process is to
resolve the problem, and then see it through until the problem is
 resolved to the end user’s satisfaction. Ideally, you want to get to
the root cause of any problems so that you can identify where
improvements need to be make.
3. Proactive support. Self-monitoring systems can now detect many
problems as they occur in real-time, and often recover from those
problems before your users even notice. But, in some cases it may
be likely that the end user has been affected by a problem. In this
case you may choose to apologize for the potential problem and
ask the end user if they would like help from a support engineer.
4. You build it, you support it. The DevOps philosophy of “you build
it, you run it” applies to Support activities too. In small
organizations, or at least those with a limited number of products, it
is common to see the delivery team itself staff the support desk for
their solution.
5. Embrace feedback. Learn from the feedback, improve the system,
improve your process.
6. Two-way conversations. A key skill for anyone doing support is
for them to strive to have real conversations with the end users that
they’re helping and not just be order takers capturing a problem
description. The idea is to find out what they are trying to achieve
by using your solution, to identify what is working well, what isn’t,
and what is potentially missing from the solution. In other words,
get a sense of what end users want to accomplish so that you can
better deliver value to them. Support engineers are often some of
the best stakeholders for a solution delivery team because they
have the most contact with actual end users and therefore will have
significant insight into what they need.
7. Self-service support. With the advent of free online software such
as Google Mail, Facebook, LinkedIn and more people have
effectively been trained to support themselves in many cases.
These techniques, such as providing online information and online
discussion forums, can be employed for both customer-facing as
well as internal-facing systems. Providing robust self-support
options can both dramatically reduce the number of requests to
your help desk and improve end user satisfaction with your
solutions. A very good strategy is to post online videos describing
ways to get better value out of your solutions or to address
common problems that people run into.
8. Automate, automate, automate. There are many opportunities to
automate the support process, including artificial intelligence (AI)-
based solutions such as chatbots, ticketing software, escalation
routing, knowledgebases, and business intelligence (BI)-based
customer intelligence gathering to name a few.
Support Workflow – Internal
Now let’s explore, at a high-level at first, the workflow for a typical Support
engagement. This is depicted in Figure 1, and from our point of view it’s a two-
step process:
Step 1: Self service. The first step, we hope, is for the end user to attempt to
solve their problem themselves. In many cases the end user will ask their
colleagues for help and will often get it, particularly when the end user has an
issue that an experienced end user understands. When this doesn’t work the
next thing the end user should do is take advantage of your self-service
offerings, such as online help, a frequently asked questions (FAQ)
knowledgebase, online videos, and so on. Hopefully your self service offerings
are sufficiently robust so that they don’t have to contact your assisted support
options (which are expensive).

Figure 1. High-level view of the Support workflow (click to enlarge)

Step 2: Assisted support (if needed). Let’s start with the more common,
indirect support version of this step as shown in Figure 2. In this case an end
user engages with the support desk, perhaps by calling in or via a chat
system. The front-line support engineers provide “level 1” support and handle
most incidents on the spot. Sometimes an issue is too complex for them to
handle, or perhaps they don’t have the authority to resolve the problem, so
they bump the incident up to “level 2” support, which is typically a more senior
support engineer or even the support manager. Many incidents are resolved
at this level. Sometimes an incident requires someone on the delivery team to
address it, so it is escalated to “level 3” support (now this has evolved into
direct support by the solution development team, more on this in a minute).
Some organizations have a “touch and hold” strategy where the support
engineer who accepted the initial request for help stays with it throughout any
escalations. Sadly, many organizations do not take this approach and hand off
the issue from one person to the next, with the potential for the incident to get
routed to the wrong person or even dropped.

Figure 2. Detailed view of the Support workflow (click to enlarge)

Now let’s explore direct support, depicted below in Figure 3. This strategy
tends to occur in two situations:

 Escalation. As described above, an incident gets escalated to the

solution development team from the support team. This development
team may be a sustainment team who at some point in the past has
taken over responsibility for the system from the original
development team.
 DevOps. It may be the case that the original solution development
team took a stable, product team approach to development where
the team sticks around and continues evolving and supporting their
work. In other words, they’re taking a “you build it, you support it”
strategy that is common with a Disciplined DevOps approach.
Having developers interact with end users can be expensive, but it
also has the benefit that developers directly learn about what end
users are struggling with, which in turn tends to lead to them
developing better solutions in the long run.

Figure 3. Direct support by a developer (click to enlarge)

A significant challenge with direct support by the developers, particularly when
there isn’t a help desk between the end user and the developer, is that
developers can get quickly overwhelmed if there are usability or other quality
problems with their solution. Having said that, it’s arguable that they should
get overwhelmed with requests in this situation to better understand the
impact of their work.
Support Practices
Some methods will choose to prescribe a single approach to Support, but the
Disciplined Agile® (DA™) tool kit promotes an adaptive, context-sensitive
strategy. DA does this via its goal-driven approach that indicates the process
decision points that you need to consider, a range of techniques or strategies
for you to address each decision point, and the advantages and
disadvantages of each technique. In this section we present the goal diagram
for the Support process blade and overview its decision points.

Figure 1. The potential activities associated with Disciplined Agile Support (click
to enlarge)
The process decision points that you need to consider for Support are:

 Support strategy. How will you provide support services, if at all, to

your end users?
 Provide self-service options. Self-support strategies enable end
users to support themselves by providing information to them.
 Provide assisted support channels. Assisted support channels
provide end users with access to a staffed help/support desk or even
to the development teams themselves.
 Escalate incident. Most incidents will be addressed immediately by
someone in the role of Support Engineer (which in the case of a “you
build, you support it” DevOps-style approach would be someone on
the delivery team who built the solution). Sometimes, when an
incident is too complex, it may need to be escalated to others with
greater experience or knowledge.
 Address incident. There are several potential aspects to
addressing an incident, including categorizing and prioritizing it,
assigning it to the appropriate person(s), and monitoring the status of
it if it is not addressed quickly (some incidents take hours or even
days to address).
 Architect a support environment. You will need to provide an
infrastructure to enable your support strategy. Please see the
section architecting your support environment.
 Govern support. Your support efforts should be governed so as to
ensure they are effective. This is part of your
overall Governance efforts.
Support Strategies
There are three categories of support strategies – direct assisted support,
indirect assisted support, and self service – which may be combined. The
strategies are described in the following table.

Support Strategy Trade-offs

Direct assisted support. In  End users get expert help

small organizations you can from the delivery team
take what is known as a itself; Team members gain
direct-support strategy, often a better understanding of
called the “you build it, you how end-users work with
support it” strategy in DevOps, their solutions
where end-users contact the
 Requires team members to
delivery team directly for
be available, able, and
support.
willing to support end users
 Works well for small
organizations with a small
number of products and
that have a small number of
end users

Indirect assisted support.  End users get expert help

Large organizations often from the delivery team
have a support/help desk itself; Team members gain
organization providing support a better understanding of
to all end users, in some how end-users work with
cases routing complicated their solutions
incidents to the delivery team
 Requires team members to
responsible for a given
be available, able, and
solution.
willing to support end users
 Works well for small
organizations with a small
number of products and
that have a small number of
end users
Self service. Many  Effective when you are
organizations are offering dealing with very large
sophisticated self-service numbers of end-users, in
support offerings, including but the millions or even
not limited to discussion hundreds of millions;
forums, online help, how-to Dramatically reduces the
videos, tutorials, and more. number of support-desk
requests that you receive
 Still requires indirect and
even direct strategies for
complex or unique incidents
 Commonly used for free or
low-cost SAAS/PAAS
systems or when end users
are technical savvy
Support Infrastructure
An important aspect of support that is easily forgotten is the need to build out
your infrastructure to support your support efforts. This may include:

 Creating a support knowledgebase so that your support engineers

can capture solutions to the problems they solve.
 Provide access to the support knowledge base to support self-
service by end users. This access is often limited for privacy reasons
– end users should have access to solutions to common problems
but not the details to specific incidents.
 A support environment to simulate problems. In some cases, such
as an online trading system perhaps, you don’t want your support
engineers trying to diagnose end user problems on the live system
itself due to potential side effects of doing so.
 Installing communication systems such as chat software and a
phone/call in system.
 Automated support systems such as integrated voice response (IVR)
and artificial intelligence (AI)/bots

Figure 1. High-level architecture for a Support environment (click to enlarge)

Support Strategies for DevOps
There are several solution support (help desk) strategies that
support Disciplined DevOps:

 Online information. A very common “self serve” support strategy is

to develop and maintain online assets such as frequently asked
questions (FAQ) pages, training videos, and user manuals to name a
few. This enables customers to potentially support themselves,
although suffers from the TAGRI (They Ain’t Gonna Read It)
syndrome.
 Artificial intelligence (AI). AI options include chat bots where
customers purposefully interact with the AI, advice systems where
the AI observes how the customer works with the solution and offers
suggestions (such as Microsoft’s ill-fated Clippy), and correction
functionality when the AI fixes input of customers (such as spelling
autocorrect).
 Online discussion forums. Many organizations choose to
implement internal discussion forums so that their customers can
help each other in learning how to use their systems. This is
effectively a collaborative self-serve support option for customers.
The primary advantage is that your “power users”, or in some cases
members of the development team, will come to the aid of other
users who are struggling with an issue. A potential disadvantage is
that you risk your discussion forum becoming a complaints forum if
problems aren’t addressed in a timely manner.
 Asynchronous support. With asynchronous support strategies an
customer will put in a request for help and then sometime later
somebody gets back to them with help (hopefully). Common ways to
implement asynchronous support include implementing a standard
support email or a support request page/screen. It is common in
many organizations to put a service level agreement (SLA) in place
putting limits on how long people will need to wait for help.
 Synchronous support. With synchronous support strategies
customers are put in contact with support people (who may even be
one of the application developers) in real-time. This is often done via
online chat software, video conferencing, or telephone calls. The key
advantage of synchronous support is responsiveness. However,
synchronous support can be expensive to operate and potentially
 frustrating for customers, particularly when the support desk function
is outsourced to people following scripts.
 Support alerts. With this strategy your solution itself detects serious
problems affecting customers, such as a data source or a
service/component being unavailable. When such an event occurs,
and the solution isn’t able to swiftly recover, the customer is informed
of the problem and presented with a “Would you like help?” option. If
yes, they are put in direct contact with an appropriate support person
who then helps them in real-time. This is part of your solution’s self-
recovery process.
 Developer-led support. This strategy has development teams
performing the support services for their own solutions and is
described in Development Strategies for DevOps.
Furthermore, anyone doing solution support, even if it is the development
team itself, is likely to need an environment in which they can reproduce
problems that customers experience. There are several options available to
you:

 Production. In some cases your production environment is

sufficient, although many regulatory regimes, particularly life-critical
and financial-critical ones, will not allow this.
 Pre-production test sandbox. Some support teams will find that
they can use their pre-production test environment to try to simulate
production problems. The advantage is that you don’t put production
at risk when trying to reproduce problems, the disadvantage is that
you the test environment will be different than production and as a
result you may not be able to simulate all reported problems.
 Support sandbox. Some organizations choose to have a specific
environment set up to enable support staff to simulate production
problems. This strategy has the same trade-offs as using a pre-
production test sandbox plus the additional cost and maintenance
associated with yet another environment.
IT OPERATIONS

Process Blade #24

Disciplined DevOps Layer
IT Operations
The primary aim of IT operations is to run a trustworthy
IT ecosystem. From the point of view of your customer,
you want to do such a good job that they don’t even
notice IT. For older organizations this can be a
challenge due to the existence of hundreds, if not
thousands, of legacy systems that have been deployed
over the decades. You may face daunting technical
debt in these systems – poor quality data, overly
complex or poorly written source code, systems with inadequate automated
regression tests (if any), different versions of the same system, several
systems offering similar functionality, numerous technology platforms,
systems and technologies for which you have insufficient expertise, and
more.
There are several reasons why IT operations is critical to your success:

1. Your organization runs on software. This is clearly true for

organizations offering intangible products and services, such as
financial institutions and media organizations, in the
marketplace. But it is also true for organizations offering tangible
products, such as physical construction companies and
restaurants, because they have human resource, planning,
ordering, and many other systems supporting their business
processes. When those systems don’t run smoothly the business
doesn’t run smoothly.
2. Your IT ecosystem must be managed and governed. It requires
effort to build, run, evolve, and monitor your IT ecosystem so that
you effectively support the rest of your organization.
3. IT is a key enabler of innovation. Your ability to bring new
offerings to your customers, to evolve existing offerings, and to
react to changes in your environment are directly impacted by the
resiliency, flexibility, and scalability of your IT ecosystem.
4. IT operations is a key part DevOps. As the very name suggests,
and as you see in Figure 1, IT operations is an important part of our
overall Disciplined DevOps strategy.
Figure 1. The workflow of Disciplined DevOps.
IT Operations Mindset
To capture the mindset for effective IT operations, we extend the principles,
promises, and guidelines of the Disciplined Agile® (DA™) mindset with
philosophies.

Figure 1. The Disciplined Agile (DA) mindset for IT Operations.

To be effective at IT operations, we embrace these philosophies:

1. Trustworthy ecosystem. At a high level the goal is to “keep the

lights on.” At a detailed level anyone responsible for IT operations
wants to run an IT ecosystem that is sufficiently secure, resilient,
available, performant, usable, and environmentally friendly. Part of
running a trustworthy ecosystem is monitoring running services so
as to identify and hopefully avoid potential problems before they
occur. For some systems, and perhaps for your IT ecosystem as a
whole, you may have service level agreements (SLAs) in place with
your end users that guarantee a minimum level of trustworthiness.
2. Resilient infrastructure. Resiliency requires a focus on the
strategic (long-term) over the tactical (short-term). Anyone
 responsible for IT operations needs to have a very good
understanding between the long-term implications of a decision
versus the short-term conveniences. For example, a solution
delivery team may want to apply what they believe to be the “best”
technologies to implement their system. This makes a lot of sense
from the narrow viewpoint of that single solution and it often proves
to be incredibly convenient, and fun, for the developers because
they often get to work with new technologies. However, from an
operational point of view you end up with a mishmash of
technologies that must be operated and evolved over time,
resulting in a potential maintenance nightmare. Yes, you will still
make some short-term decisions but you should do so intelligently.
Too great a focus on the long-term results in a stagnant IT
ecosystem, too great a focus on short-term decisions results in
operations teams who spend all their time fighting fires. The long-
term technical vision for your organization is developed by
your Enterprise Architecture efforts and the long-term business
vision comes from your Product Management activities.
3. Standardization without stagnation. The more standardized your
IT ecosystem is the easier it will be to run, to release new
functionality into, and to find and fix problems if they should arise.
However, too much standardization can lead to stagnation where it
becomes very difficult to evolve your ecosystem. You will need to
work very closely with people performing enterprise architecture
and product management activities to ensure that you understand
the long-term vision and are working towards it.
4. Regulated releases. Most DevOps strategies reflect the viewpoint
of a single product team. But what about the viewpoint of your
overall IT ecosystem, which may comprise hundreds of products?
An interesting question to ask is what is the WIP limit for releases
across your overall ecosystem? In other words, what rate of
change can your infrastructure, and your stakeholder community,
bear? In the Disciplined Agile (DA) tool kit this philosophy is an
important driver of the Release Management process blade.
Furthermore, some regulatory compliance regimes call out a
separation of concerns pertaining to release management – the
people building a product are not allowed to release the product
into production, someone or something else must make that
decision and do the work (even if “the work” is automatically
running a script once your regression test suite passes).
5. Sufficient documentation. Yes, there will be some documentation
maintained about your IT ecosystem. Hopefully this documentation
is concise, accurate, and high-level. Common documentation
includes an overview(s) of your infrastructure, release procedures
(even if fully automated, there’s still some overview documentation
and training), and high-level views of critical aspects of your
infrastructure including security, data architecture, and network
architecture. Organizations that operate in regulated industries will
of course need to comply to the documentation requirements of the
appropriate regulations. When infrastructure components are
discoverable and self-documenting there is a lesser need for
external documentation, but there is still a need. Any
documentation that you do create should be maintained under
configuration management (CM) control.
6. Automate, automate, automate. Any IT operations process that
still has people in the loop should be questioned, examined, and
automated wherever possible. This will increase the predictability,
resilience, and speed of your operations efforts while reducing
overall cost and service-level variance.
IT Operations Roles and Responsibilities
There are several roles that are pertinent to IT operations. Remember that
these are roles, not positions. Small organizations may have a single person
taking on every one of these roles whereas a large organization could have
dozens of fine-grained positions. Remember, context counts. We define the
following key roles for Disciplined Agile® (DA™) IT operations:

1. Operations engineers. Operations engineers install, configure,

operate and evolve common infrastructure such as the network,
servers, and your external services (e.g. the cloud). Sometimes
called a System Operator or Operator.
2. Operations manager. A functional manager who leads the
operations team. Responsibilities potentially include managing
change within the operational infrastructure; Planning for and
mitigating operational disasters; and guiding the creation of
operational guidelines.
3. Tool smith. Someone who is responsible for buying, building,
installing, configuring, and potentially supporting tooling used by
people to support their work. In this case of IT Operations their
focus is typically on DevOps tooling, including tools for deployment,
security, operational monitoring, backup/recovery, and chaos
engineering.
4. DevOps engineer. This role is common when organizations are
either new to DevOps or are very small. In small organizations a
DevOps Engineer is typically a “jack-of-all-DevOps-trades” who
takes on the responsibilities of several of the roles listed here. As
your organization grows you’ll find that these specialist roles will
emerge and that DevOps Engineer goes away.
5. Database administrator. Operates, supports, and evolves existing
legacy data sources. Data administrators collaborate with delivery
teams, ideally as a member of those teams, to ensure that data
sources are developed and evolved in a quality manner. From
the Data Management process blade.
6. Release manager/coordinator. A functional manager who leads
the release team (if any). Responsibilities include coordinating the
multitude of solution releases into production across all delivery
teams; facilitating the determination of whether a solution is
production ready; guiding the development of common release
practices; and coordinating the overall release schedule. From
the Release Management process blade.
IT Operations Practices
The Disciplined Agile® (DA™) tool kit promotes an adaptive, context-sensitive
strategy so that you may have a fit-for-purpose way of working (WoW). DA
does this via its goal-driven approach that indicates the decision points that
you need to consider, a range of techniques or strategies for you to address
each decision point, and the advantages and disadvantages of each
technique. Figure 1 overviews the potential activities associated with
Disciplined Agile IT Operations.

Figure 1. The Operations process blade (click on diagram for larger version).
The decision points that you need to consider for IT Operations are:

1. Run solutions. Your IT operations efforts exist to run your

organization’s IT solutions in production.
2. Manage infrastructure. Your IT ecosystem is made up of the
solutions that you build and buy as well as the infrastructure
(hardware, software, network, cloud, and so on) that those
solutions run on. This infrastructure must be managed and evolved
over time.
3. Manage configurations. You need to understand the configuration
of your IT ecosystem, including dependencies between various
aspects of it, to support impact analysis of any potential changes.
Traditional strategies are centered around manual maintenance of
configuration and dependency metadata, a risky and expensive
proposition at best. Agile strategies focus on deriving/generating
the required metadata from your IT ecosystem.
4. Evolve infrastructure. You will evolve your IT ecosystem over
time, upgrading databases, operating systems, hardware
components, network components, and many more. This is
certainly true if you run your own ecosystem on premises, but it is
also true even with a cloud-based approach. Even when you are
“100% cloud” there is always some on-premises infrastructure, and
the cloud-based offerings evolve over time and you will need to
react accordingly. Due to the significant coupling of your IT-based
solutions to your infrastructure, and infrastructure components to
other aspects of your infrastructure, this can be a risky endeavor
(hence the need to identify the potential impact of any change
before making it).
5. Mitigate disasters. Disciplined organizations will plan for
operational disasters. Potential disasters include servers going
down, network connectivity going down, security breaches, power
outages, failed solution deployments, failed infrastructure
deployments, natural disasters such as fires and floods, terrorist
attacks, and many more. Furthermore, it is one thing to have
disaster mitigations plans in place, it is another to know whether
they actually work. Disciplined organizations will run through
disaster scenarios to verify how well their mitigation strategies work
in practice. This can be done on a scheduled basis at first, evolving
 into unscheduled or “random” problems via chaos engineering
strategies, and eventually even full-fledged disaster scenarios.
6. Govern IT operations. As with other process blades, the activities
of IT Operations must be governed effectively. Operational
governance is part of your organization’s
overall Governance efforts.
IT Operations Teaming Strategies
our organization will need to organize the person(s) involved with IT
operations as appropriate for your situation. In this section we share three
common patterns for doing so:

1. A traditional strategy
2. A DevOps strategy for small organizations
3. A DevOps strategy for large organizations
First, let’s explore the traditional approach to organizing an operations team.
This is depicted in Figure 1. With this strategy the development teams and the
operations team(s) are kept separate, often because the skillsets are
perceived to be distinct and sometimes because of a strict interpretation of
separation of duties requirements in regulations such as PCI-DSS. A release
manager, and in larger organizations a release management team, is
responsible for shepherding releases of new functionality into production. The
operations team is responsible for running the solutions in production, for
maintaining and evolving the IT infrastructure, for monitoring running systems,
and for addressing problems as best they can. There is often an IT
support team, not shown in Figure 1, helping end users.

Figure 1. A traditional approach to operations (click on diagram for larger

version).
The small-organization DevOps teaming strategy is depicted in Figure 2. This
works well in organizations with a handful of systems, where each system is
being evolved by a solution delivery team, and where a “you build it, you run
it” approach has been adopted by the delivery teams. In this case the delivery
teams themselves are responsible for developing, releasing, operating, and
(very likely) supporting their solution.

Figure 2. A DevOps approach to operations in small organizations (click on

diagram for larger version).
You can see that there in Figure 2 that there is someone in the role of
“DevOps Engineer”, a specialist role. This role is common when organizations
are either new to DevOps or are very small. In small organizations a DevOps
Engineer is typically a “jack-of-all-DevOps-trades” who takes on the
responsibilities of several of the roles in Figure 3 (Release
Manager/Coordinator, Database Administrator, Tool smith, and sometimes
even Operations Engineer). As your organization grows you’ll find that these
specialist roles will emerge and that DevOps Engineer goes away. In
organizations new to DevOps you’ll often see them call their more senior
developers DevOps Engineers, particularly those on teams following
the Continuous Delivery: Lean or Continuous Delivery: Agile lifecycles.
The large-organization DevOps teaming strategy is depicted in Figure 3. As
an organization grows they realize that the “you build it, you run it” philosophy
at the team level doesn’t scale very well by itself. The people on a given team
can and should operate and support the specific functionality that they are
responsible for, but that functionality is hosted within your overall enterprise
ecosystem. Because there is a shared ecosystem, there are some common
issues across teams that are better handled at the strategic level. For
example, this may include:
  Having a Release Manager/Coordinator to coordinate and guide the
deployment efforts across dozens or even hundreds of teams
 Operations engineers to operate and evolve common infrastructure
such as the network, your servers, and your external services (e.g.
the cloud)
 Disaster planning, simulation, and mitigation
 Managing the enterprise ecosystem configuration

Figure 3. A DevOps approach to operations in large organizations (click on

diagram for larger version).
We’ve seen all three of these approaches, and combinations thereof, work
quite well in practice. As usual, context counts – different situations require
different teaming strategies.
IT Operations Strategies
Successful Operations efforts balance several competing factors:

1. Strategic (long term) versus tactical (short term). There is a fine

balance between ensuring operational safety while enabling the
evolution of operational systems.
2. Operations needs versus organizational needs. You want to not
only optimize the flow of operational work but do so within the
context of your larger organization – Context Counts.
3. Standardization versus evolution. To reduce the overall cost and
risk associated with operations, and to simultaneously make it
easier for development teams to test and release changes into
production, you want to standardize as much of your IT
infrastructure as possible. Yet your infrastructure cannot be allowed
to stagnate, it must safely evolve over time – Hence the need to
work with your Enterprise Architecture efforts to envision the future
and run experiments so as to learn how to evolve towards that
vision.
4. Team DevOps versus organizational efficiency.
The DevOps philosophy of “you build it, you run it” is very attractive
to individual delivery teams, and it certainly makes sense for
smaller organizations. But for organizations with dozens, hundreds,
or even thousands of delivery teams working in parallel your costs
and risks quickly skyrocket. These organizations quickly realize that
having a flexible operations/infrastructure team to support the
delivery teams to leverage common infrastructure and guidance will
help to optimize the overall workflow across your Disciplined Agile
Enterprise – Follow the Be Pragmatic principle.
IT Operations Strategies for DevOps
There are several technical IT operations strategies that support Disciplined
DevOps:

1. Solution monitoring. As the name suggests, this is the operational

practice of monitoring running solutions and applications once they
are in production. Technology infrastructure platforms such as
operating systems, application servers, and communication
services often provide monitoring capabilities that can be leveraged
by monitoring tools. However, for monitoring application-specific
functionality, such as what user interface (UI) features are being
used by given types of users, instrumentation that is compliant with
your organization’s monitoring infrastructure will need to be built
into the applications. Development teams need to be aware of this
operational requirement or, better yet, have access to a toolkit that
makes it straightforward to provide such instrumentation.
2. Standard platforms. Software development practices, such as
continuous deployment and initial architecture envisioning, are
enabled by consistency within your operational infrastructure. It is
much easier to deploy to a handful of standard hardware
configurations than it is to a myriad of unique ones. It is easier to
deploy when there are consistent versions of infrastructure
software (e.g. operating systems, databases, middleware, and so
on) deployed across your environment. For example, all instances
of your Oracle DB are 11.2.1.3, you don’t have 11.2.0.0, 12.0.1.0,
and 11.2.1.3 installed in various places. Furthermore, it is much
easier to make architecture decisions when there is consistency of
infrastructure software packages in the first place. For example you
standardize on Linuz for your server operating system, you don’t
also have Windows, z/OS and others also in production (and if you
do you’re actively retiring them).
3. Deployment testing. After a solution, or an update to a component
of your operational infrastructure, has been deployed you should
run a quick set of tests to verify that the deployment was
successful. Were the right versions of the files installed where they
need to be? And were they deployed to all appropriate servers?
Were database transformations applied successfully? Did the
 appropriate announcements, if any, get sent out? Did the overall
deployment process run within the desired time frame?
4. Automated deployment. Deployments should be automated, not
manual. This increases the consistency of your deployments and
supports the practice of continuous deployment. Part of your
automation effort should be to support both self-recovery and self-
testing as native aspects of your deployment strategy.
5. Operations intelligence. This is the application of data warehouse
(DW)/business intelligence (BI) solutions to provide insight into your
operations and support efforts. Your operations team may have
individual dashboards for each solution, they may combine
information being generated by individual solutions into an
integrated dashboard, and better yet share that information for an
IT portfolio management view.
There is a collection of operations strategies focused on operational disaster
mitigation that IT departments may choose to adopt:
1. Disaster planning. Disciplined organizations will plan for
operational disasters. Potential disasters include servers going
down, network connectivity going down, power outages, failed
solution deployments, failed infrastructure deployments, natural
disasters such as fires and floods, terrorist attacks, and many
more. This planning will include identification of potential problems,
identification of strategies to address those problems, and putting
mechanisms in place to hopefully mitigate the disasters. Potential
strategies to address these disasters include building solutions that
self-test and self-recover, building redundancies into your
operational infrastructure, having disaster procedures in place, and
practicing those procedures in simulated disasters.
2. Scheduled disaster simulation. It is one thing to have disaster
mitigations plans in place, it is another to know whether they
actually work. Disciplined organizations will run through disaster
scenarios to verify how well their mitigation strategies work in
practice. For example, to test whether your power outage
emergency plan works you would purposely simulate a power
outage at one of your data centers and then work through your
recovery plan. Like fire drills, these simulations should be done on
a regular basis so that staff members build up the “body memory”
required to act swiftly and appropriately in an emergency. The
 advantage of a scheduled disaster simulation is that you knowingly
run it at a time where you will have minimal impact on your
stakeholders. A disadvantage, at least when people are informed of
the simulation ahead of time, is that people are mentally prepared
for the simulation and aren’t caught unaware and thereby you don’t
simulate the real level of stress that people would be under during
an actual emergency.
3. Random disaster simulation. Very disciplined organizations will
implement a service within their operational environment that
causes problems such as server or service outages at random
times. An example of this is the Chaos Monkey functionality in
Amazon’s Web Services (AWS) offering, functionality that is being
implemented within many organizations now. The Chaos Monkey
injects random problems into production to verify that the IT
operations organization is capable of overcoming them. This is
done to verify that your solutions really are able to automatically
recover from problems and failing that at least operators are alerted
to the problem.
As you would expect, truly disciplined organizations have adopted all of these
strategies.