Use DevOps Practices To C

For Application Development & Delivery Professionals
Use DevOps Practices To Create A Lean And

Responsive Application Delivery Organization
Organization: The Modern Application Delivery Playbook
by Kurt Bittner, Amy DeMartine, Diego Lo Giudice, and Randy Heffner
January 20, 2016
Why Read This Report
Key Takeaways
Agile practices are helping organizations deliver

high-quality digital experiences that delight
customers, rapidly and at lower cost. Application
development and delivery (AD&D) leaders have
learned that taking the next step and transforming
their organizations to embody DevOps practices
means changing the culture and values, using
new teaming and sourcing approaches, adopting
new processes and practices, and using
automation to streamline delivery. This report
helps leaders understand the dimensions of the
change and form a plan to make it happen.
Changing Culture Is The Key To Better

Performance
High-performing organizations have norms
and cultural values that place customer
experience above everything else. Regardless
of organizational structure, they incent and
reward people to put customers first, they reward
learning and experimentation, and they measure
results in terms of customer outcomes, not
internal milestones.
This is an update of a previously published report;

Forrester reviews and updates it periodically for
continued relevance and accuracy.
Cross-Functional Collaboration Focuses On

Delivering Customer Value, Not Utilization
High-performing organizations focus on
improving customer experience and brand loyalty,
not on arbitrary measures like keeping everyone
as busy as possible. They staff their organizations
to maximize responsiveness and minimize waiting
on scarce resources.
Modular Application Architectures Enable
Modular Organizations
The more an organization builds and tests
its software as small, independent, modular
services and components, the faster it delivers
software and the less time and effort it spends
coordinating teams.
forrester.com
Use DevOps Practices To Create A Lean And Responsive

Application Delivery Organization
by Kurt Bittner, Amy DeMartine, Diego Lo Giudice, and Randy Heffner
with Christopher Mines, Bobby Cameron, William Martorelli, Margo Visitacion, Sophia Christakis, Kevin
Driscoll, and Karen Traikovich
January 20, 2016
Table Of Contents
2 Delivering Faster Means Changing People,
Processes, And Technology
3 Organizational Change Is Really About
Changing People
4 Technology Affects What People Do And
How People Work
9 DevOps Teaming Models Improve
Responsiveness
Recommendations
15 Transform Your Organization Incrementally

But Deliberately
17 Supplemental Material
Notes & Resources

Forrester interviewed 37 vendor and user
companies: 3Pillar, Allianz, American Airlines,
Atlassian, Bose, CA Technologies, Capital One,
CI&T, CloudBees, Delta Air Lines, EPAM, Fidelity
Investments, FINRA, General Electric, General
Motors, Health Care Service Corporation,
Hewlett Packard Enterprise, IBM, KPMG, MC10,
Microsoft, Nationwide Insurance, New Relic,
Northwestern Mutual, Practical Large Scale Agile,
Progressive Insurance, Puppet Labs, RogueWave
Software, Scaled Agile, Scrum.org, Solstice
Mobile, ThoughtWorks, Travelers, USAA, Verizon
Communications, Wells Fargo, and XebiaLabs.
Related Research Documents

Faster Software Delivery Will Accelerate Digital
Transformation
Forget Two-Speed IT; DevOps Enables Faster
Delivery Across The Board
Use DevOps And Supply Chain Principles To
Automate Application Delivery Governance
Forrester Research, Inc., 60 Acorn Park Drive, Cambridge, MA 02140 USA

+1 617-613-6000 | Fax: +1 617-613-5000 | forrester.com
2016 Forrester Research, Inc. Opinions reflect judgment at the time and are subject to change. Forrester,
Technographics, Forrester Wave, RoleView, TechRadar, and Total Economic Impact are trademarks of Forrester
Research, Inc. All other trademarks are the property of their respective companies. Unauthorized copying or
distributing is a violation of copyright law. Citations@forrester.com or +1 866-367-7378
January 20, 2016
Use DevOps Practices To Create A Lean And Responsive Application Delivery Organization
Delivering Faster Means Changing People, Processes, And Technology

Applications help companies make closer connections to their customers, partners, and employees by
providing new ways to interact and achieve better outcomes through collaboration. Delivering highquality applications rapidly, reliably, and repeatedly requires AD&D leaders to build organizations that are
lean and flexible and that innovate while also minimizing cost and waste. Applying development and
operations (DevOps) practices helps organizations transform across three dimensions (see Figure 1).
FIGURE 1 Transforming Application Delivery Means Changing People, Processes, And Technology
People
Culture, organizational structure, skills
Processes
Technology
Agile and Lean SDLC,

continuous delivery
Application architecture,
process automation
2016 Forrester Research, Inc. Unauthorized copying or distributing is a violation of copyright law.
Citations@forrester.com or +1 866-367-7378
FoR AppLicAtion DeveLopMent & DeLiveRy pRoFessionALs
January 20, 2016
organization: the Modern Application Delivery playbook
organizational change is Really About changing people

organizations are more than roles and responsibilities, more than lines and boxes on an org chart, and
more than RAci charts; organizations are principally defined and guided by their culture and values.1
creating an innovative and responsive organization requires leaders to change its culture, not just
reorganize.
As tempting as it seems, you cannot reorganize your way to continuous improvement and
adaptiveness. What is decisive is not the form of the organization but how people act and react.
(Mike Rother, author of Toyota Kata: Managing People for Improvement, Adaptiveness, and
Superior Results)2
organizations dont spontaneously change; leaders have to set the change in motion and sustain it in
the face of resistance from supporters of the status quo. our discussions with organizations that have
dramatically improved their responsiveness have revealed that their leaders:
Create and promote a vision for a new way of working. Audacious customer-focused goals,
backed by concerted action, motivate people to change. Leaders point the way, provide support,
and remove roadblocks to maintain and
build momentum. By focusing everyone
on gaining new customers and retaining
Audacious customer-focused
existing customers by improving their
goals, backed by concerted
experiences, leaders create a bond between
action, motivate people to
their teams and their customers.
change.
Make it safe, and even rewarding, to learn.

Leaders signal a new way of working by
asking different questions: What can we
learn from that? instead of Whom do we
hold accountable? they build trust by not punishing mistakes and instead learning from it when
things dont turn out as planned. continuously improving organizations always ask themselves how
to make it better next time, rather than assigning blame.
Alter the rules to incent and reward the change. Goals and measurements powerfully influence
behavior; people generally do what they are measured on, ignoring other exhortations when they
conflict. Measures that reward individual performance crowd out collaboration; measures that
incent improvements in customer experience reward collaboration. Measures that incent cost
reduction alone may hurt revenue by damaging customer experience. Be careful what you ask for;
you might just get it.
Level the playing field. the status quo has a constituency that benefits from things staying the
same. Leaders must incent new behaviors and take action to prevent their organizations from
sliding back to old ways. changing measures and objectives and rewarding success speak
powerfully, but sometimes teams need more forceful action.
2016 Forrester Research, inc. Unauthorized copying or distributing is a violation of copyright law.
citations@forrester.com or +1 866-367-7378
January 20, 2016
We started off having teams opt in, supporting their journey with the right resources and celebrating
their success. Peer pressure is a wonderful motivator, because when people see success, they
want to be part of it. But eventually we had to confront the fact that not everyone wanted change.
Those discussions were hard, but our message was clear: This is going to be our future, and if you
dont want to be part of it, you need to go. (Senior application delivery leader, large corporation)
Challenge their organizations to adapt. Short-term delivery pressures can cause organizations
to focus too much on meeting immediate needs and not enough on developing a sustainable
ability to change. The only guarantees are that customers will continue to change, markets will be
more competitive, and organizations will continue to have to adapt. Leaders need to shape their
organizations so that delivered solutions meet todays needs while also preparing for more change
over the long haul.
Break down organizational silos to drive better results. Organizational silos and rigid roles
can get in the way of collaboration. When leaders communicate goals like improving customer
experience and delivering specific applications faster and with higher quality, they help everyone
set the right priorities. These shared goals must include everyone: businesspeople, developers,
quality assurance (QA), security, and operations.3 To ensure that moving fast doesnt lead to
disconnected application silos, it is particularly important to break down silos between developers
and architects, customer experience, and operations.4
Technology Affects What People Do And How People Work

The architecture of an application tends to reflect the team structure of the organization that produced
it.5 And once produced, that architecture tends to constrain how teams can be organized. As a result,
organizations can find themselves trapped by the architecture of software written decades ago.
Breaking free of these bonds often requires organizations to re-architect their applications.
Application Architecture Shapes And Constrains Collaboration
Breaking applications into components affects team structure by separating concerns that require close
collaboration (e.g., how the component is implemented, applying the design principle of high cohesion)
from concerns that require minimal collaboration (e.g., how the component is used, applying the design
principle of loose coupling). Componentization affects organization structure in the following ways:
Changing tightly coupled applications requires complex coordination. Tightly coupled
applications, those that lack effective componentization, are hard to modify because so many
things need to be considered in order to make a change. Many different people need to be involved
to make a decision. Reducing application and component coupling reduces the scope of change
and simplifies communication.
January 20, 2016
if you have tightly coupled architectures that require large groups of people working together, then
you need very structured approaches to build stable complex applications. if you have loosely
coupled architectures that enable small teams to develop, qualify, and release code, then you are
able to reap the benefits of a much simpler delivery pipeline. (Gary Gruver, ceo, practical Large
scale Agile)6
Loose architectural coupling using APIs boosts team independence. consumers of
components dont need to understand indeed should not know the components internal
details to be able to use them. isolating concerns using Apis lets teams move at different rates
of speed.7 technologies like service virtualization simplify collaboration by standing in for new or
changing components while they are under development.8 organizations with older applications are
constrained by their architectures at first, but modernizing via increasing componentization gives
them greater team independence.9
Common components establish a lingua franca for collaboration, at a cost. common services
lie waiting to be found in most applications. Refactoring them into reusable components and
aggregating those components into a platform of continuous business services provides a common
foundation across applications, enables organizations to simplify and accelerate application
delivery, and reduces complexity and
redundant effort.10 But common platforms
have an organizational component, too:
common platforms have an
they require shifting resources to refactor
organizational component,
components and support the common
too: they require shifting
platform. Without a team and budget
resources to refactor
supporting them, platform components
wither and die.
components and support the
common platform.
our platform approach is now paying
significant dividends, but initially there was
a lot of pushback; many teams were afraid
that it would slow them down. it does, in
the short run, but in the long run, it really speeds things up. our cios strong support helped us to
overcome this resistance. over time, the organization embraced the platform approach once they
saw the benefits. (todd piehler, vp of architecture and data services, Fidelity investments)
DevOps Practices And Automation Change What People Do
Devops introduces tools and practices that automate the application delivery pipeline.11 Automating
low-value-added manual work lets people focus on higher-value activities, changing the skills
they need to contribute and the types and numbers of resources the organization needs. Devops
automation changes the nature of the work in a number of ways:
January 20, 2016
Infrastructure as code (IaC) changes how dev, EA, QA, ops, and security pros work.
Standardizing environment definitions, versioning them, and building new environments from
the versioned definitions frees ops from manually crafting environments and lets them focus on
working with developers to create more robust, more supportable, more self-healing applications.
Architects still need pretty pictures to communicate design concepts, but they turn these into
actionable guidance with proven running code, with built-in modularity, scalability, and failover
strategies, at minimum. Whats more, they do this across the application delivery pipeline. At its
best, this all takes the form of managed patterns.12
IaC frees developers and QA from waiting for environments to be ready and ensures that both have
fresh, uncontaminated environments in which to work, which reduces errors and unplanned rework.
It also changes the game for security pros by ensuring that environments and application patterns
are built with the most secure, least vulnerable components and configurations so they can focus
on anticipating new threats, rather than responding to those already known.13
Continuous integration (CI) changes developer and tester work. Developers can use the time
they spent building and integrating software to write better code, and testers can focus on more
advanced tests because unit and functional testing can be automated using APIs and integrated
into the CI process. Even load and performance testing can be automated as part of CI.14
Automation-assisted code reviews change code quality work. Making code reviews simpler
by calling static analysis, peer code review, and security code scanning tools directly from the CI
automation lets developers focus more on things that matter. Providing developers with earlier
feedback on their codes quality means fixes are faster and take less effort than when they get
feedback weeks or months after they wrote the code.15 These techniques also make enterprise and
solution architects more effective by freeing them from basic compliance reviews so that they can
make more substantive contributions.16
Automating delivery pipelines changes the focus of security and compliance work. The
additional control and visibility provided by automated application delivery processes allow
compliance and security professionals to have greater visibility into who has touched the software
and why and how they have built the software. Automated code scans and automated compliance
and security testing, built right into the automated delivery pipeline process, free compliance and
security pros to be more proactive in responding to unwanted events.17
Release automation changes the nature of deployment work. Infrastructure and operations
(I&O) pros automate release processes to create fidelity between different environments such as
development, testing, and production. This fidelity builds on IaC and ensures the consistency of
the application and its supporting software, configuration, and middleware as it moves through
the development life cycle into the hands of customers.18 Release automation tools let I&O pros
spend their time streamlining and improving the quality, flexibility, and stability of environments,
rather than spending time manually executing commands and filling out forms. Being less reactive
reduces costs and improves reliability.19
January 20, 2016
Application analytics changes the nature of customer insight work. Faster delivery cycles,
better analytics tools, and applications instrumented to provide insight into customer experience
give organizations the means to improve their traditionally hit-or-miss requirements processes.20
instead, they adopt hypothesis-driven approaches in which they test ideas quickly with real
feedback, rather than subjective guesswork. this changes the nature of business analysts work
as well as the way businesspeople engage in application delivery: they still provide subject matter
expertise, but they spend less time designing solutions and more time identifying unmet customer
needs and devising ways to measure whether new solutions meet them.21
Agile And DevOps Collaboration Makes Delivery Roles And Responsibilities More fluid
Forresters Agile-plus-Architecture research has shown that collaboration is the single most important
success factor for achieving fast delivery, high quality, and long-term sustainability.22 organizations that
do all three work differently:
Developers still develop, but they also test and support their code. As Werner vogels, cto
of Amazon.com, said, you build it, you run it.23 Making developers accountable for supporting
their code helps them build better applications by understanding how customers use it and how it
performs in production. it also encourages them to work closely with their i&o and cybersecurity
peers to ensure that their applications are
stable, reliable, scalable, and secure.24 once
they do, taking responsibility for testing it as
Making developers
part of the ci process before customers
accountable for supporting
get it and even before QA gets it takes
their code helps them build
on greater importance. Developer testing is
better applications.
not about final verification and acceptance,
as QA-led testing is, but about improving
quality by finding problems faster.
the essence of Devops is to design a
system in which people are held responsible for the consequences of their actions and indeed,
one in which the right thing to do is also the easiest thing to do. (Jez Humble, principal at Humble,
oReilly & Associates)25
I&O pros still support production, but they have more time for optimization. Freed by
automation from performing repetitive, manual tasks such as creating environments or manually
releasing applications, they are able to focus on working with their developer and architect peers to
create more secure, scalable, and production-ready environments, as well as optimizing production
platform performance and scalability. Application analytics in early life-cycle phases gives
developers and i&o pros early feedback to either redesign the supporting environment or modify
the application before the application is released into production.26
January 20, 2016
QA still tests but with more automation and fewer people over time. QA resources are
integrated into cross-functional application delivery teams. As testing is increasingly automated
and built into the application delivery pipeline, they focus more on user experience and exploratory
testing. Creating and maintaining this growing base of automated tests means that organizations
need to build new skills in test automation as they reduce the amount of manual testing they do.27
Customer experience (CX) permeates application delivery teams. Great customer experiences
require everyones focus, not just the CX teams. CX pros can often make their greatest
contributions by working closely with their delivery team colleagues to help them learn how to
understand customers better and to translate that understanding into great products.28
We embedded our CX professionals in application delivery teams at critical times in the delivery
cycle when they could have the greatest impact on the products outcome. Working directly with
application delivery team members also helped them to raise their CX awareness to build better
products over the long run. (CX lead, multinational financial services firm)
Multilevel architecture collaboration blends near-term and long-term goals. To sustain
quality and fast delivery over the long run, leading enterprises foster rich, frequent collaboration
between architects and developers at many levels. For example, lead developers and solution
architects on delivery teams collaborate with domain architects who work across many teams in
related areas. These architects in turn collaborate with enterprise architects whose scope spans
the entire digital business.29
Developers and architects both adjust their working models. Rather than focusing only on
standards and future technology directions, enterprise architects get their hands dirty helping
developers put standards and technologies in action. Rather than being concerned only about
getting an individual solution working in production today, developers work with architects to
ensure that the solution is prepared to evolve for tomorrow and that, when it is combined with other
solutions in the future, the result will be coherent business operations.
Cybersecurity pros have new tools and new opportunities to engage. DevOps practices dont
help just AD&D and I&O pros; they also open up new opportunities for improving cybersecurity by
automating the delivery pipeline and increasing transparency across the delivery life cycle.30
Demand management drives team priorities. Product owners and program managers ensure
that application delivery teams connect with broader organizational goals. DevOps practices enable
them to obtain earlier customer and user feedback to inform decisions. As delivery cycles shrink,
they adopt more hypothesis-driven approaches, trying out new ideas and measuring the results.
DevOps practices like feature toggling provide new means other than releasing software to control
capability visibility.31 Shorter application delivery cycles give organizations new ways to balance
priorities to be more responsive to customer needs.32
January 20, 2016
Devops teaming Models improve Responsiveness

Devops teaming models build on Agile practices to help organizations deliver products faster to
customers, with lower cost and less waste, but these teams cannot stand alone; they need the help
of the entire organization. streamlining the
organization yields benefits that go far beyond
the customer-focused teams by eliminating
Devops teaming models build
waste and rework. Driven by the need to
on Agile practices to help
respond rapidly to shifting customer needs and
organizations deliver products
nimble competitors, organizations have applied
faster to customers, with
Agile and Lean principles to create modular
lower cost and less waste.
organizations capable of moving quickly (see
Figure 2).
fIGURe 2 the Modular customer-Focused Application Delivery organization
Customers
Business offering teams
Ongoing releases
Dedicated resources
Aligned with business
offering funding
Integrated
product teams
Ideally deliver via automated

self-service
Resources shared across
products and projects
Ideally staffed or automated for
zero wait time
Shared
service
teams
Project
teams
One or more products

Integrated customer experience
Integrated business processes
Single release
Shared resources
Finite scope
Common components and

services
Software
platform Common architectural patterns
services
teams
Operational platform services
S
o
u
r
c
i
n
g
Computing-as-a-utility
January 20, 2016
Business Offering Teams Ensure Great CX Spanning Products And Services

Most organizations offer more than one product, and their customers experiences grow from a
complex series of interactions over a long period of time. When a person buys a Tesla or an iPhone,
they are not just buying the product; they are engaging in a series of interactions with the company
that shape their overall customer experience. Business offering teams are responsible for one or more
offerings that comprise one or more products with associated services and customer experiences.
Business offering teams:
Own the relationship with the customer, end to end. They organize themselves to provide a
specific set of customers with specific consistent, high-quality experiences that meet specific
needs.
Build offerings from one or more products or applications. Delighting customers often requires
more than one product, and customer experiences accumulate from the collective experience of
all of their interactions with a company. An offering team provides a way to connect the work that
product teams do with the value that customers experience.
Span functional areas. Pulling together work of application delivery teams and building on
customer service, fulfillment, marketing, and other teams, business offering teams ensure
consistency without handoffs and dropped communications.
Integrated Product Teams Own The Customer Experience With The Apps They Deliver
Organizations struggle when they try to apply project management principles to products. The Project
Management Institute says:
A project is temporary in that it has a defined beginning and end in time, and therefore defined
scope and resources. And a project is unique in that it is not a routine operation, but a specific set
of operations designed to accomplish a singular goal.33
Products are different. Although products do reach the end of their life, they have no defined end while
they are viable. Software products have many releases, and while some organizations try to apply
project management practices to releases, they struggle when release cycles are very short because
project management practices lack resource and funding continuity between releases, and project
management planning, funding, and governance practices are ineffective for managing products. In the
application delivery context, think of a product as:
A long-lived application that has sustained, ongoing funding that spans releases and is delivered
in a series of releases, each of which may deliver new capabilities, fixes, and improvements to a
set of users; capabilities may also be removed or deprecated over time.
An integrated product team is responsible for building and supporting a specific product. Software
product teams:
10
January 20, 2016
Organize around a set of integrated capabilities. For integrated product teams to create and
maintain focus, they concentrate on specific personas and specific capabilities that they will
provide to those personas. they make conscious decisions about whom they serve and what
they do for them. they push personas and outcomes that are outside their scope back to portfolio
management for broader consideration.
Persist across releases and product versions. team members may change, but the team itself
exists in perpetuity until the product reaches its end of life. this is the primary difference from a project
team, which exists only for the duration of the project, which is typically a single software release.
Are small, focused, and multiskilled.
Forresters Q2 2015 Global Agile software
Application Development online survey
showed that successful organizations keep
application delivery teams small and crossfunctional. they draw essential team skills
from traditional functional areas such as
dev, ops, QA, cX, and architecture with
product leadership provided by the business
(see Figure 3).34 over time, team members
become more cross-skilled and the team
more self-sufficient.
separating production
support from new
development keeps delivery
teams in the dark about how
their apps are being used and
deprives them of valuable
feedback.
exploit loosely coupled architecture to

avoid staffing complexity. product teams typically create their applications using a combination
of custom-developed code as well as extensively using components built by other teams,
components acquired from vendors, and open source components.35 product teams can be kept
small by exploiting loose coupling, by isolating functionality into components and then shifting
the work to separate teams that build those components. organizations may also outsource
component development, which allows them to more effectively manage variable demand.36
Hold responsibility for new features, maintenance, and production support. separating
maintenance and production support from new development keeps delivery teams in the dark
about how their apps are being used and deprives them of valuable feedback. product teams take
responsibility for all three to obtain a holistic picture of their applications health.37
Draw upon matrixed or dedicated resources. the actual reporting structure is not as important
as how teams work. the essential feature of the product team is that it never needs to wait for a
team member to be available to do work. in practical terms, it means that product work is always
the top priority of team members. they may have other responsibilities, but they need to put those
aside when the team needs their participation.
11
January 20, 2016
Share expertise across teams using communities of practice. Product team members can
become isolated from one another, making it harder to share experiences and assets. The old
organizational silos provided a means for sharing within role-based hierarchies but not broadly
across an organization. Communities organized around common interests, spanning teams and
even organizations, provide practitioners with the means to stay up on the latest technologies
and techniques.
Share culture and objectives and maybe location. While Agile teaming models originally
emphasized colocation of team members, many organizations have seen success using distributed
teams. Open source projects are good examples: Their team members are almost always
geographically separated, yet they deliver high-quality, complex software. Shared cultural values
and firm agreements on how the team will work, coupled with effective processes and support,
make teams effective, not simply being in the same place. Colocation can be important in the initial
sprints because it helps to build that shared culture.
FIGURE 3 Typical Product Team Skills And Roles
Skill
Dev
Ops
QA
Architects
CX
Product managers Cybersecurity
Discovering outcomes
Designing capabilities
Writing code/scripts
Testing code/scripts
Assessing usability
Optimizing experiences
Optimizing application
and operational platforms
Reviewing analytic data
Securing applications
Architecting solutions
patterns and IaC
Project Teams Are Still Useful For One-Off Work, But Dont Mix Resources With Products
Projects are never going to go away; organizations will always have a mixture of project and product
work. The challenge they face is staffing both and minimizing resource conflict. Organizations deal with
the resource conflict between projects and products in a variety of ways. They:
Avoid sharing resources between project and product teams. When projects and products
share resources, one or both will suffer. In order to maintain their fast delivery, product teams need
dedicated resources; when people are busy working on other things, product progress stalls.
Dedicated resources make the most progress in either teaming model.
12
January 20, 2016
Outsource project work whenever possible. organizations typically use product teams for
competitively differentiating apps that are central to the business strategy. they usually dont use
project work because it is by nature nonrecurring. the finite nature, well-defined scope and budget,
and well-defined deliverable make project work easy to outsource. When complete outsourcing is
not possible, staffing with contractors is attractive.38
Prioritize product work over project work when they need to share resources. project work
is often less time-critical than product work, making it possible for shared team members to put it
aside when product work claims priority. When the postponed project work is off the critical path,
project schedules arent even affected. projects are typically staffed with shared resources and can
often accommodate delays and wait time, but not always.
shared services Teams Develop self-service Capabilities
shared services organizations are staffed with people with scarce but specialized deep skills that neither
product nor project teams need all the time. Unfortunately, using shared services often forces other
teams to wait in queues, wasting time and killing productivity. to a degree, organizations can manage
this by involving shared services teams in sprint zero and identifying architecture sprints they can do in
parallel with feature sprints.39 However, staffing enough shared resources to eliminate all wait time is
often both cost-prohibitive and pragmatically impossible. Automation can step in where people cannot.
teams with scarce specialized skills should
produce a tool, a library, or a service that
other teams can use, instead of doing the
work themselves. (Randy shoup, former
engineering director, Google and principal of
Randy shoup consulting)
to prevent becoming bottlenecks that prevent
rapid delivery, shared services teams develop
self-service capabilities like:
teams with scarce specialized

skills should produce a tool, a
library, or a service that other
teams can use, instead of
doing the work themselves.
environments on demand. Devops

practices like iac and templated cloud environments make it easy for architects and i&o pros
to provide developers and testers with the ability to obtain high-quality, standard environments
whenever they need them. no more tickets, no more waiting, no more having developers end-run
around ops by going to public cloud providers, and no more having testers reuse old environments
that have potentially been contaminated by prior test runs.
Test data on demand. A large insurer started its shared service automation journey by supplying
standard, scrubbed, and approved test data to developers and testers on demand. it found that
creating standard test data made testing more accurate and saved everyone valuable time.
13
January 20, 2016
Continuous delivery pipeline-as-a-service. Many teams do their own builds, maintaining their
own build servers and build automation. standardizing the build and continuous integration
process saves time and effort and provides a foundation for further automation, including
governance activities, security code scans
and automated tests, and the ability to
assess architectural fitness using static code
standardizing the build
40
analysis and dynamic automated testing.
and continuous integration
process saves time and effort

Common platforms and services
on demand. common platforms help
and provides a foundation for
organizations standardize technology,
further automation.
eliminate redundant code, and reduce
team sizes. Refactoring product and
project code to pull out common services
helps teams deliver faster while reducing
maintenance costs and complexity.41 standardizing platforms and services also provides a means
for encapsulating specialized expertise, reduces unnecessary variation and complexity, and makes
applications more modular.42
sourcing strategies Align With Teaming Models
Resources at any one of the layers depicted in Figure 2 can be sourced from outside the organization.
organizations align their sourcing strategies with their teaming models in a number of ways. they:
Augment teams with skilled resources. organizations sometimes just need extra talent with
specific skills, especially skilled developers with specific experience. they generally do this to meet
short-term needs and to balance workloads. to avoid dependence on external resources, they
often try to limit staff augmentation to teams building nondifferentiating capabilities, though this is
not always possible.
source components or services from external vendors. An organization doesnt need to
develop all components or services itself. smart organizations develop only those services that
help them competitively differentiate; they should source everything else from somewhere else.
sourcing of this kind changes the number and types of teams that an organization needs.
fill temporary, time-critical skills gaps. in some cases, the organization simply lacks critical
expertise, such as the situation in which many organizations found themselves when customer
demand for mobile applications exploded. in such situations, they cannot wait to develop in-house
expertise, so they will source entire applications to an outside agency, usually with a plan to bring
the application development and delivery in-house over time. this sort of sourcing does not change
the organizations structure in the short run, but as the applications are brought in-house, it will
increase the number and types of teams, as well as the roles and skills needed in the organization.
14
January 20, 2016
Outsource their IT infrastructure, wholly or partially. When an organization moves an

application to a public cloud provider, it is outsourcing part of its computing infrastructure. Teams
that used to work with other parts of their own organizations will now potentially need to work with
external organizations, and they generally have to take on new responsibilities, such as those
cases where developers take over responsibilities for defining and designing environments running
in public clouds.43
Recommendations
Transform Your Organization Incrementally But Deliberately

Transforming an application delivery organization is a long journey, but the payoffs are dramatic. To get
started, AD&D leaders need to:
Turn culture from a barrier to a lever. Leaders who have made the transition say that culture
matters more than any other single factor. Getting everyone focused on the same goal of winning,
serving, and retaining customers is the first and most important step. Along with excellence in
digital customer experience, some teams may focus heavily on digital operational excellence.44
Look for volunteers at first. You have lines of business with a burning need for better results and
faster delivery, and you will have AD&D, architecture, and I&O pros in your organization who have
heard of Agile and DevOps and want to work in a different way. Bring all three together to show
that the new approach can work. Dont try to force it to work on products and teams that are not
ready to change.
Slow down to speed up. Teams with extreme delivery pressure dont take the time to improve their
practices. Allow time to find and pursue improvement opportunities while also getting feature work
done, but also shift from making large infrequent improvements to improving continuously.
Leverage peer pressure, mentoring, and internal social networks to expand. Once the pioneer
teams show results, celebrate those successes to build a broader base of people ready to work
in new ways. Show that the new approach is actually less risky than clinging to the old approach.
Use informal social networks and gatherings to share experiences and engage imaginations. And
support the change by helping people learn the new skills they will need to be successful.
Work iteratively and opportunistically. People need time to build skills and become comfortable
with taking a markedly new approach. When teams and business partners are ready, be prepared
to go full speed. Take advantage of the natural momentum of change.
Get involved in the change. Actions speak powerfully. Support the change by asking teams what
you can do to help to remove barriers and then remove them.
15
January 20, 2016
Evolve your application architectures toward looser coupling. Service-oriented architectures

(e.g., APIs), open source software, and componentized architectures (e.g., OS-level containers
like Docker) reduce barriers to change by reducing coordination complexity. Evolving application
architectures to exploit loose coupling is a long-term commitment, but every step toward it make
the next step easier.
Mature beyond Agile by evolving Agile-plus-Architecture practices. To achieve the flexibility
and fast innovation provided by DevOps and the long-term application stability provided by
architecture, developers and architects must collaborate. Business architecture context provides
clarity for how initiatives fit together. Architects work closely with developers to adjust and refine
architecture for project delivery. Developers work closely with architects on technology selection.
And both developers and architects change their operating culture: Developers consider future
implications in their designs, and architects eschew ivory tower architecture pronouncements.
Strong collaboration makes Agile-plus-Architecture work.45
Think journey, not destination. You cant accomplish this transformation in a year or even two. The
destination is not as important as creating a flexible, adaptive organization that continuously improves
itself to respond to business challenges, market opportunities, and evolving customer needs.
Engage With An Analyst

Gain greater confidence in your decisions by working with Forrester thought leaders to apply our
research to your specific business and technology initiatives.
Analyst Inquiry
Analyst Advisory
Ask a question related to our research; a

Forrester analyst will help you put it into
practice and take the next step. Schedule
a 30-minute phone session with the analyst
or opt for a response via email.
Put research into practice with in-depth

analysis of your specific business and
technology challenges. Engagements
include custom advisory calls, strategy
days, workshops, speeches, and webinars.
Learn more about inquiry, including tips for

getting the most out of your discussion.
Learn about interactive advisory sessions

and how we can support your initiatives.
16
January 20, 2016
Supplemental Material
Companies Interviewed For This Report
3Pillar
MC10
Allianz
Microsoft
American Airlines
Nationwide Insurance
Atlassian
New Relic
Bose
Northwestern Mutual
CA Technologies
Practical Large Scale Agile
Capital One
Progressive Insurance
CI&T
Puppet Labs
CloudBees
RogueWave Software
Delta Air Lines
Scaled Agile
EPAM
Scrum.org
Fidelity Investments
Solstice Mobile
FINRA
ThoughtWorks
General Electric
Travelers
General Motors
USAA
Health Care Service Corporation
Verizon Communications
Hewlett Packard Enterprise
Wells Fargo
IBM
XebiaLabs
KPMG
Endnotes
RACI: responsible, accountable, consulted, informed.
You can find additional information about the Toyota Kata approach at the following site. Source: Toyota Kata (http://
www-personal.umich.edu/~mrother/Presentations.html).
For a deeper perspective on how AD&D leaders and CIOs shift to an outcome-oriented approach, see the Manage BT
Outcomes, Not IT Assets Forrester report.
17
January 20, 2016
Delivering once is not enough: Development teams must sustain and increase the rate of change over time. Agile
development practices and continuous delivery are essential tools, but so is an architecture that enables resilience.
See the Agile-Plus-Architecture: Embrace The Oxymoron Forrester report.
For a deeper perspective on how AD&D leaders and CIOs shift to an outcome-oriented approach, see the Manage BT
Outcomes, Not IT Assets Forrester report.
Conways Law, as it has become known, is named for Melvin Conway. The observation he made is that organizations
which design systems are constrained to produce systems which are copies of the communication structure of those
organizations. Fred Brooks was the first to call it Conways Law in his classic work The Mythical Man Month.
Source: M. E. Conway, How do committees invent? Datamation, 14,4 (April, 1968), pp. 28-31.
Source: Gary Gruver, Tommy Mouser, and Gene Kim, Leading the Transformation: Applying Agile and DevOps
Principles at Scale, IT Revolution Press, 2015.
For a discussion on how loose architectural coupling enables team independence and helps organizations delivery
higher-quality software faster, see the Brief: Software Innovation Requires A Loosely-Coupled Application
Architecture Forrester report.
To learn about how this extends to business strategy, see the How APIs Reframe Business Strategy Forrester report.
For more on service virtualization, see the The Forrester Wave: Service Virtualization And Testing Solutions, Q1
2014 Forrester report.
For more information on how organizations are incrementally modernizing their legacy applications, see the
Application Modernization, Service By Microservice Forrester report.
For more on continuous business services, see the CIOs, CX, And End-To-End Tech Management Forrester report.
10
11
For a description of the automated application delivery pipeline and a breakdown of the categories of tools that make
up the pipeline, see the TechRadar: Continuous Software Delivery, Q2 2015 Forrester report.
12
Patterns created and managed collaboratively between developers and architects are one of 30-plus best
practices that Forrester has identified for Agile-plus-Architecture. See the Best Practices For Agile-Plus-Architecture
Forrester report.
For deeper views on how DevOps improves security, see the The Seven Habits Of Rugged DevOps Forrester report
and see the Improve Cybersecurity With DevOps Forrester report.
13
Testing automation and test process automation become a step in a continuous integration process for faster
delivery with high quality. For more information, see the The Forrester Wave: Modern Application Functional Test
Automation Tools, Q2 2015 Forrester report.
14
There is nothing more destructive to developer productivity than context switching. See the Brief: Fast Feedback
Accelerates Software Time-To-Market Forrester report.
15
Agile practices and software architecture practices actually reinforce one another when done right. For more
information, see the Best Practices For Agile-Plus-Architecture Forrester report.
16
For more information about how DevOps improves speed and governance, see the Use DevOps And Supply Chain
Principles To Automate Application Delivery Governance Forrester report.
17
For more information on how release automation increases fidelity of the application life cycle, please see the Market
Overview: Application Release Automation Tools Forrester report and see the The Forrester Wave: Application
Release Automation, Q2 2015 Forrester report.
18
For more information on how DevOps practices including IaC and release automation can increase speed and quality
of releases, please see the Brief: Join The DevOps Craze, But Start With The Right Business Case Forrester report.
19
18
January 20, 2016
For more information on making use of tools such as application performance management (APM) to get more direct
feedback on features, please see the Application Performance Management Remains The Same Even With
Mobile Forrester report.
20
Design practices that utilize fast delivery and feedback cycles to deliver better results are changing the way that
organizations understand customer needs and deliver solutions. For more information, see the Bring Design Practices
to Application Development Forrester report.
21
The following report provides more information on the challenges that developers and architects face in trying to
collaborate and identifies important resources that both sides can draw upon. See the Agile-Plus-Architecture:
Embrace The Oxymoron Forrester report.
22
Source: A Conversation with Werner Vogels, ACM Queue, June 30, 2006 (http://queue.acm.org/detail.
cfm?id=1142065).
23
Putting developers on call is a good first step. For more information on the benefits and how to do this, see the Brief:
Put Developers On The Front Lines Of App Support Forrester report.
24
Source: Theres No Such Thing as a Devops Team, Continuous Delivery, October 19, 2012 (http://
continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/).
25
For more information on how I&O pros need to change from strictly being reactive to being proactive partners in the
application delivery life cycle, see the DevOps Makes Modern Service Delivery Modern Forrester report.
26
For more on what organizations need to do to improve testing speed without sacrificing quality, see the Five MustDos For Testing Quality At Speed Forrester report.
27
Staffing teams that deliver digital products requires special attention to get the right blend of skills and the right team
culture. For more information, see the Build Your Dream Team: Organizing To Deliver Exceptional Digital Experiences
Forrester report.
28
Forrester categorizes Agile-plus-Architecture best practices into four categories: 1) business architecture and project
context, 2) project delivery guidance and governance, 3) architecture management and technology selection, and 4)
organization and culture. See the Best Practices For Agile-Plus-Architecture Forrester report.
29
For more information about how DevOps improves application security, see the Improve Cybersecurity With DevOps
Forrester report and see the The Seven Habits Of Rugged DevOps Forrester report.
30
For more information about hypothesis-driven development and feature toggling, see the Bring Design Practices To
Application Development Forrester report.
31
For a deeper view on how organizations utilize the insights provided by continuous delivery and embrace continuous
planning, see the Its Time For Agile Strategic Planning And Portfolio Management To Join The Mainstream Forrester
report.
32
Source: Project Management Institute (www.pmi.org).
33
For more information on which Agile practices Agile expert teams are using and how they mix methodologies,
organize, and measure their progress, see the The 2015 State Of Agile Development: Learn From Agile Expert Firms
Forrester report.
34
For more about how organizations are using components and services to compose applications, see the From
Application Design To Application Composition Forrester report.
35
Organizations use sourcing in a variety of different ways. Using sourcing along with Agile and DevOps approaches
creates new opportunities and challenges. For more information, see the Developing Modern Applications With Agile
Outsourcing: Part One Forrester report and see the Developing Modern Applications With Agile Outsourcing: Part
Two Forrester report.
36
19
January 20, 2016
For more information on the benefits of having developers take on production support responsibilities, see the Brief:
Put Developers On The Front Lines Of App Support Forrester report.
37
For more information on the existing sourcing options that I&O pros should use to align, engage, and deliver
operational excellence in the age of the customer, see the Brief: Sourcing Behavior Secures Operational Excellence In
The Age Of The Customer Forrester report.
38
Sprint zero is an Agile-plus-Architecture best practice wherein, before the first feature development sprint, developers
and architects collaborate to identify architecture issues and decide the best way to address them. This may include
running architecture sprints that resolve issues ahead of the feature sprints that will encounter them. See the Best
Practices For Agile-Plus-Architecture Forrester report.
39
40
For more on this topic, see the Use DevOps And Supply Chain Principles To Automate Application Delivery
Governance Forrester report.
41
To read more about incremental application modernization, see the Application Modernization, Service By
Microservice Forrester report.
42
Fidelity Investments presents an interesting case study on how organizational structure and platform architecture
intersect. For more information, see the Case Study: Fidelitys Journey To A Common Platform For Global Scale And
Efficiency Forrester report.
43
For more information on the existing sourcing options that I&O pros should use to align, engage, and deliver
operational excellence in the age of the customer, see the Brief: Sourcing Behavior Secures Operational Excellence In
The Age Of The Customer Forrester report.
The pioneers of the digital revolution, be they B2B or B2C firms, are driving increased revenues through a superior
digital customer experience and are increasing efficiency and agility through digital operational excellence. See the
Understand The Digital Business Landscape Forrester report.
44
45
Forrester categorizes Agile-plus-Architecture best practices into four categories: 1) business architecture and project
context, 2) project delivery guidance and governance, 3) architecture management and technology selection, and 4)
organization and culture. See the Best Practices For Agile-Plus-Architecture Forrester report.
20
We work with business and technology leaders to develop

customer-obsessed strategies that drive growth.
Products and Services
Core research and tools

Data and analytics
Peer collaboration
Analyst engagement
Consulting
Events
Forresters research and insights are tailored to your role and

critical business initiatives.
Roles We Serve
Marketing & Strategy
Professionals
CMO
B2B Marketing
B2C Marketing
Customer Experience
Customer Insights
eBusiness & Channel
Strategy
Technology Management
Professionals
CIO
Application Development
& Delivery
Enterprise Architecture
Infrastructure & Operations
Security & Risk
Sourcing & Vendor
Management
Technology Industry
Professionals
Analyst Relations
Client support
For information on hard-copy or electronic reprints, please contact Client Support at
+1 866-367-7378, +1 617-613-5730, or clientsupport@forrester.com. We offer quantity
discounts and special pricing for academic and nonprofit institutions.
Forrester Research (Nasdaq: FORR) is one of the most influential research and advisory firms in the world. We work with
business and technology leaders to develop customer-obsessed strategies that drive growth. Through proprietary
research, data, custom consulting, exclusive executive peer groups, and events, the Forrester experience is about a
singular and powerful purpose: to challenge the thinking of our clients to help them lead change in their organizations.
115536
For more information, visit forrester.com.

Use DevOps Practices To C

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Use DevOps Practices To C

Uploaded by

Copyright:

Available Formats

For Application Development & Delivery Professionals