DevOps Roadmap

Template
For use with the Implement DevOps
Practices That Work storyboard

Info-Tech Research Group, Inc. is a global leader in providing IT research and advice.
Info-Tech’s products and services combine actionable insight and relevant advice with
ready-to-use tools and templates that cover the full spectrum of IT concerns.
© 1997-2019 Info-Tech Research Group Inc. Info-Tech Research Group 1
Introduction: How to use this template

This template is for those involved in creating a roadmap for DevOps adoption.
• This template is intended to be used with the blueprint, Implement DevOps Practices That Work.
• Use this template to create a knowledge database and communications deck for identified challenges, opportunities,
and roadmap objectives for adopting DevOps in your organization.
• All stakeholders must understand and agree on the objectives and important characteristics of the roadmap.
• Stakeholders must be given the opportunity to adjust the contents within to better address their needs and concerns.
• Communicate the content of this PowerPoint deck to project sponsors to facilitate decision making, reach agreement,
secure buy-in, and obtain official approval.
• To use this template, simply customize any text in dark grey to fit the needs of your enterprise. Be sure to remove all
introductory text in dark grey and convert the remaining text to black prior to distribution.

Info-Tech Research Group 2

Revision history
This section is used to document any changes made to the original document. Use the table below to organize and track
changes to this document.
Sample revision history:

Version Revision Date Author/Editor Comments

1.0 02/01/2019 Joe Smith Original document

Info-Tech Research Group 3

[Organization Name]’s DevOps journey

Project C
Project A Project E Project F

Project B

Project D

Phase A

Phase B
Training Module B
Phase C Training Module A

Accomplished To Date In Progress

• Determined overarching metrics Adoption Phase A
• Structured DevOps capabilities Client • Project A
• Determined requisite DevOps changes
Index • Project B
• Structured DevOps adoption roadmap • Training Module A
• Initiated phase A of DevOps roadmap • Project C

Info-Tech Research Group 4

What is DevOps?

DevOps is an operational
philosophy that seeks to promote
an improved relationship between
development and operations to
break down existing silos and
better align the groups in providing
customer value.

Because common understanding of

value is so critical to DevOps, you
need to frame value in a language that Many
Many areas
areas ofof the
the industry
industry clarifies
clarifies the
the goals
goals and
and
objectives
objectives of of DevOps
DevOps using
using the
the CALM
CALM (Culture,
(Culture,
the business, development, and Automation,
Automation, Lean,Lean, Metrics)
Metrics) framework,
framework, or or some
some variation
variation
operations can mutually understand of
of it.
it. This
This framework
framework may may help
help frame
frame your
your understanding
understanding
of
of DevOps,
DevOps, but but itit does
does not
not provide
provide the
the structure
structure or
or
and achieve. guidance to integrate DevOps into your
guidance to integrate DevOps into your software software
development
development lifecycle
lifecycle (SDLC)
(SDLC) and
and development
development
methodologies.
methodologies.

Info-Tech Research Group 5

Our proposed DevOps framework

We have adopted the following framework for our DevOps adoption to holistically explore the different
factors that can contribute to our success prior to narrowing them down based on an assessment of
impact and effort. Use the remainder of this space to discuss how this DevOps framework will enable
success within your organization. Frame this within the perspective of your stakeholders who will want to
know why this framework is effective. It may be helpful to discuss the limitations in defining DevOps and
their single issue approaches while explaining why this model will be the most effective for your
organization. Create a convincing case so that your stakeholders will give you full buy-in.

DevOps CLAIM Framework

Teams believe that value is best created by self-organizing, collaborative, cross-functional teams
C ulture who are driven by a customer satisfaction, common delivery mindsets, and grounded expectations
from all perspectives.
DevOps is a radical change in how people work and think. Structured, facilitated learning is
L earning required throughout the transformation to help leaders and practitioners create mutual
understanding and synergies across the organization.

DevOps organizations strive towards the automation of delivery and operational capabilities to
A utomation achieve self-service and continuous delivery (CD). Automation comes with a heavy investment so it
must be applied in the right areas.

ntegrated While temporary teams can get some benefits from DevOps, standing, self-organizing teams that
I teams cross business, delivery, and operations are essential to gain the full benefits of DevOps

etrics and Successful DevOps implementations require the disciplined use of delivery and operations metrics
M governance that support and validate the satisfaction of the DevOps governance model.

Info-Tech Research Group 6

Where our journey began

Based on an initial brainstorming session, [Organization’s Name] saw the following as some potential
ways to improve business value delivery.

People Process Technology

• Guiding Principles • Release Planning • Application Lifecycle Management

• Cross-Functional Collaboration
• Coaching and Training
• Personal Development Programs
• Formal Learning Sessions
• Communities of Practice (CoPs)
• Organizational Design
• Governance and Oversight
• Stakeholder Management
• Continuous Integration
(CI)
• CD
• Change Management
• Continuous Improvement
• Program Frameworks
• Industry Frameworks (SAFe, DAD,
ITSM, ITIL, etc.)
• Service Management
• SDLC Optimization
• Kaizen
• Release Management
(ALM)
• Infrastructure as Code
• Build Automation
• Test Automation
• Release Automation
• Deployment Automation
• Version Control
• Real User Monitoring
• Synthetic Monitoring
• Infrastructure Monitoring
• Service Desk/Help Desk
• Incident Management
• Disaster Recovery
• Environment Management

Edit this list as necessary to reflect the possibilities explored prior to this DevOps adoption initiative.

Info-Tech Research Group 7

[Organization Name]’s definition of DevOps

• Continuous releases and deployment.

DevOps Principles
• Simple and transparent processes.
• Management of change, feature, and project requests. We must work together in pursuit of
common goals.
o Collective ownership of the backlog.
• We will clarify accountability and
Team collaboration and communication.
responsibility to drive collaboration.
• Good communication with stakeholders and end users.
Our roles are a foundation, not a
• Continuous improvement of our products and processes. box.
• Problem management and contingency plans.
We will be humble, open, and honest
• Cross-functional training and sharing of knowledge. as we learn how to work together
• Collaboration with internal and external resources. better.

• Automate, where possible, as appropriate. We need to handle success AND

adversity together.
• Clearly articulated roles and responsibilities.
• Engagement across development and operations for all initiatives. We will ensure everyone knows why
they are involved in any activities
• DevOps integrate with existing development methodologies and and what is expected.
processes (Scrum and Waterfall).

Import your DevOps definition from Exercise 1.1.

Info-Tech Research Group 8

[Organization Name]’s organizational vision and objectives

Vision: Our vision is to collaborate as strategic

partners to deliver innovative, reliable, and adaptable
solutions that will enable all users to reach higher levels
of success through equitable access to technology.

• Objective: Be strategic partners to better serve the needs of all users,

including our students, staff, parents, and our community.
• Objective: Provide adaptable and robust technology solutions that
manage cost and risk while promoting creativity and innovation for all
users.
• Objective: Deliver operational excellence with modern, reliable, and
responsive services to drive efficiencies.

Import your organizational priorities and vision from Exercise 1.1.

Info-Tech Research Group 9

[Organization Name]’s DevOps priorities

As a team, we discussed why as an organization DevOps would benefit us. For each of the documented
reasons for DevOps, we defined the current metrics that are currently being used and in cases where
there were none, brainstormed some initial metrics.
Reason for DevOps Pillars Expected Results Related Metrics
• Increase stability • Reliability:
• People have what they need when they need MTTF/MTTR
it to do the right thing (e.g. prod. data
access)

• Reduce rework • Number of defects

When we work together we:
Reduce risks by reducing the
number of issues and resolving
them quickly
Build confidence by delivering
a quality product on time
Technology
Drive engagement by being
recognized for delivering these
benefits
• Improve product quality • Number of outages
• Less unplanned work due to deployment
People • Environment alignment standardization and • Complexity – cost of
automation deployment
• Number of service
Controls desk calls
• Deliver value sooner (improve time to value) • Number of deployed
• Risk reduction features
• Improve responsiveness/customer service – • Estimates vs
deliver on time outcomes
• Better estimates
• Operations is engaged early • Requests for change
• Knowledge sharing, broaden skillsets • Key person
• Better engagement/retention dependencies
• Better handoff between “Dev” and “Ops” as • Engagement survey
we design, build, and deliver

Import your rationale for DevOps from Exercise 1.1.

Info-Tech Research Group 10

Current challenges in meeting metrics benchmarks

Key metrics are not meeting defined benchmarks. Teams and management identified the following
challenges that must be addressed to ensure organizational objectives are met.

Metric Current Challenges

Reduce release lead times by x% • Poor communication mediums between development and operations
• Issues with version control slowing releases
• Lack of coding standards, leading to lag time

Reduce MTTR by x% • Triage system not streamlined

• Operations not sure which developers to escalate defects to

Increase deployment frequency by x% • Manual tests

• Manual builds
• Inconsistent environments
• Slow to integrate new business requirements

Reduce cycle time by x% • Difficulties handing off products at stage gates

• Cadence misalignment
• Lack of tooling standards
• Process inefficiencies

Use this slide to summarize any challenges identified in your current metrics program from Exercise 1.6.

Info-Tech Research Group 11

DevOps readiness assessment: Results
A readiness assessment was conducted to determine our current ability to move forward.
Score Culture
0 • Blame and finger-pointing are common.
• Lack of quality accountability.
• Lack of management and team support for
change.
1 • Team-based accountability for quality and
value delivery.
• Empathy of challenges shared within team
and with management.
• Shared decision making within team.
• Management and team support for change.
• Teams are aware of sub-culture.
2 • Shared decision making, empathy, and
accountability across all teams involved in
delivery.
• Shared vision of DevOps and its alignment
to business priorities.
• Business is motivated to collaborate with IT.
• Integration of team sub-cultures.
3 • Failure-tolerant culture acceptable across
the organization.
• High degree of experimentation where
appropriate.
• Executive-level support for scaling DevOps
initiatives.
Import your DevOps readiness assessment scores and justifications from Exercise 1.7.
Learning
• Solely dependent on experts for
knowledge.
• Siloed knowledge is the norm.
• Unpredictable, reactive to change.
• Limited knowledge sharing.
• Can repeat what is known, but
struggle to react to unknowns.
• Effectively react to delivery and
product unknowns and issues.
• Teams regularly hold retrospectives
to facilitate delivery improvements.
• Cross-functional knowledge sharing
is the norm.
• Teams contribute improvements to
delivery provided by other teams.
• Proactively make changes based
on identified risks and opportunities.
Automation
• Manual and inconsistently executed
delivery processes (e.g. build, test, and
deployment).
• Environment inconsistencies.
• Tools are implemented in silos.
• Defined, lean, and repeatable delivery
processes.
• Architected and integrated toolsets
across all SDLC stages.
• Artifacts are standardized across the
organization.
• SDLC processes are automated where
appropriate.
• Environment consistency and effective
environment management across
SDLC.
• Teams can do work without manual
approval from outside of the team.
• Continuous integration and continuous
delivery where appropriate.
• Environments are accessible to all roles
through a self-service model.
• Push-button deployments.
Info-Tech Research Group 12
DevOps readiness assessment: Results
A readiness assessment was conducted to determine our current ability to move forward.
Score Integrated Teams
0 • Organization is inappropriately siloed by
functional roles or products.
• Teams members are inconsistent and unfamiliar
with each other.
1 • Managed and regular communications within
functional teams.
• Roles and responsibilities are defined and
transparent.
2 • Some integration of roles and shared
responsibilities among functional roles within
teams.
• Collaboration occurs across multiple teams and
teams are motivated to collaborate.
• Team is composed of cross-functional roles.
3 • Center of Excellence (CoE) to manage the
knowledge sharing, coaching and mentorship of
multiple teams.
• Team is composed of generalized specialists.
• Integration of business and IT stakeholders in the
delivery process.
Import your DevOps readiness assessment scores and justifications from Exercise 1.7.
Metrics and Governance
• No metrics are gathered
• No governance model defined.
• Functional roles are measured against a consistent and
visible set of metrics.
• Centralized system monitoring and alerting.
• Metrics collected and analyzed against business goals.
• Team governance model defined.
• Organization-wide standards are established.
• Monitoring and alerting are configurable by teams.
• Non-functional requirements are defined and measured.
• Holistic product delivery governance model defined.
• System and product performance dashboards shared with
and understood by all functional roles and stakeholders.
• Proactive improvements and enhancements using trend
analysis of metrics.
• Integration of product delivery governance model with the
holistic IT governance model.
Info-Tech Research Group 13
Business value delivery challenges

To expand on our approach and start to develop a more value-centric perspective, we conducted a set of
exercises as a group to identify current customer needs and challenges and the ways that development
and operations can come together and collaborate to deliver increased business value.

The following needs and challenges were identified:

Business Value Delivery Challenges

• Run reports • System availability challenges
• Take calls • System integration challenges
• CSR assessments • Challenges integrating multiple languages
• Case management in CRM • System performance issues
• Cross-functional communication • IT support issues, triaging
• Active customer feedback • UX issues
• Access mail servers • Market competition

Use this slide to summarize any business value delivery challenges identified in Exercise 2.4.

Info-Tech Research Group 14

[Organization Name]’s guiding principles

To support the DevOps mindset and organizational objectives, guiding principles were defined and will be
followed by all roles involved in delivery, including IT and the business.

Principle Description Rationale Impact

QA Start to Make sure QA is involved at
the start of every project and
Finish throughout operations
Save time, get things done
right, reduce defects, and
make things easier for
product delivery roles
Faster completion times, make sure there is
enough time for testing, and make sure it is
committed, better acceptance by users
Minimize risks
Must clearly state entry, frequency, exit, and
verification and validation points in the
process
Support team must have the artifacts they
need to add, manage, and enhance quality

Shared All teams using similar
documentation and delivery
Consistency practices
Apply to Collaboratively build and
deliver business cases
Business  
Value Make sure we are doing the
right thing, the right way, and
we are integrated with the
needs of the organization
Knowledge is shared
between teams and team
members can move
between teams
Have the right players at the
table to ensure we have a
clear direction in what we’re
doing
Good practices would be shared,
opportunity to implement automation,
product would be of increased quality
Increase end-user satisfaction and
successful implementations

Document your DevOps guiding principles from Exercise 3.1.

Info-Tech Research Group 15

[Organization Name]’s target state DevOps topography

Given the current DevOps objectives and product delivery constraints, [Organization Name] selected
[chosen topography]. The team also identified the involvement of a DevOps champion to facilitate the
growth and maturity of this organization in our DevOps journey.

DevOps Value Opportunities Risks and Impacts Confidence of Fit

Topography
• Development team is
accountable for the decisions
they make
Shared Accountability • Development team is
motivated to test
• Issues are properly escalated
to development
• Significant cultural and
mindset shift
• Issue escalation procedure
is not well defined Good fit but with challenges
• Lack of deployment
warranty period

Involvement of DevOps Champions

DevOps champion will initially operate as an integrator to bring the various teams together. The role will eventually
transition to a coach who will build a CoE to grow and scale the DevOps practice across the organization.

Use this slide to summarize the rationale of your target state DevOps topography and the involvement of
a DevOps champion from Exercise 2.5.

Info-Tech Research Group 16

[Organization Name]’s prioritized DevOps capabilities

Based on an impact and effort analysis of the brainstormed DevOps capabilities, the following capabilities
were prioritized as mission critical in the early stages of our DevOps journey to build towards our target
state. Some capabilities are now shared to support the chosen DevOps topography.

Development Capabilities Shared DevOps Operations Capabilities

Capabilities

Application
Application
Business
Business Analysis
Analysis and
and Environment
Environment
Architecture
Architecture and
and
Modeling
Modeling Management
Management
System
System Design
Design

Code
Code and
and Build
Build Configuration
Configuration Help
Help Desk
Desk
Management
Management Management
Management

Source
Source Code
Code and
and Quality
Quality Assurance
Assurance Infrastructure
Infrastructure and
and
Build Management
Build Management and Testing
and Testing Storage Management
Storage Management

Application
Application Problem
Problem and
and Incident
Incident
User
User Experience
Experience Performance
Performance Management
Management
Management
Management
Release
Release and
and
Data
Data Governance
Governance and
and Service
Service Level
Level
Deployment
Deployment
Management
Management Management
Management
Management
Management

New capability Capability needs to be optimized to fit DevOps

List your prioritized DevOps capabilities from Exercises 2.6 and 2.7.
Info-Tech Research Group 17
Competencies to support DevOps capabilities

Each role in product delivery requires a new or modified set of competencies to successfully execute the
target state DevOps capabilities. Any gaps will be addressed through training, hiring, process
adjustments, or other appropriate means.

Role Legacy Future State Gaps Strategy to Fill

Competencies Competencies Gap
• Coding/scripting • Coding/scripting • Strong grasp of • Automation –
• Communication/ • Communication/ automation tools external hire with
collaboration collaboration • Empathy, experience (too high
• Problem-solving skills: • Strong grasp of persuasion, of a risk to business
solution automation tools negotiation, product to
implementation and • Project planning and consensus building, experiment)
verification management, project and conflict • Empathy,
• Project planning and scoping, estimation, resolution skills persuasion,
Developer management, project process planning negotiation,
scoping, estimation, and management consensus building,
process planning and • Empathy, and conflict
management persuasion, resolution skills –
negotiation, internal L&D training
consensus building, sessions and
and conflict coaching
resolution skills

Detail results from Exercise 3.4 on your brainstormed strategies for filling the gaps between your current
and desired competencies.
Info-Tech Research Group 18
Target state roles and responsibilities: Developer

Role Responsibilities Accountabilities Consulted Informed

Developer • Design • Code base quality • Estimation • Prioritization
• Develop • Source control • Backlog grooming • User feedback
• Test • Knowledge sharing of • Trends and customer
• Deploy completed features satisfaction from
• Code review and changes operations
• Bug fixes • Course of action on
• Demonstrations rollback
• Address tickets (L3)
• Research
• Operational tasks (month
end)
• Environment
management
• Release notes
(deployment instructions
& ORD)
• Update technical
documentation
• Conduct rollbacks

** Text in red font indicates potential changes or additions from current state role definitions.
Document your target state roles and responsibilities to support your DevOps capabilities from Exercise
3.4.
Info-Tech Research Group 19
Target state roles and responsibilities: QA

Role Responsibilities Accountabilities Consulted Informed

QA • Write and maintain • Test coverage • Estimation • Prioritization
testing documentation • Defect • Grooming • Design
(e.g. test plan, test management • Demonstration • Business needs
cases) • Course of action on • Development
• Hand off build to UAT rollback rationale
• Conduct functional
testing
• Conduct smoke testing
• Conduct regression
testing
• Communicate test results
• Report test defect
• Manage test automation
framework and tools
• Validate rollback

** Text in red font indicates potential changes or additions from current state role definitions.
Document your target state roles and responsibilities to support your DevOps capabilities from Exercise
3.4.
Info-Tech Research Group 20
Target state roles and responsibilities: Operations/Support

Role Responsibilities Accountabilities Consulted Informed

Operations/ • Triage tickets • Execute against • Design • Prioritization
Support • Resolve tickets service level • Estimation
• Collect requirements agreement • Backlog grooming
(non-projects) • Manage user • Lessons learned from
• Create and prioritize user feedback process
stories (non-projects) • Course of action on
• Create escalation defect rollback
tickets
• Communicate with
business
• Communicate with
product managers
• Perform change requests
and deploy changes
• Execute daily tasks
• Environment
management
• Analyze and
communicate trends
• Conduct rollback

** Text in red font indicates potential changes or additions from current state role definitions.
Document your target state roles and responsibilities to support your DevOps capabilities from Exercise
3.4.
Info-Tech Research Group 21
Changes to current development and operations governance
Collaborative Governance
• Collaborative governance means that you use
your existing governance groups and interface
Description them at regular intervals or milestones to
collaborate solutions and deliver actions.
• This model requires your existing groups to
interface and co-define problems, processes,
solutions, and necessary actions to deliver the
appropriate solutions to drive value.
• By co-opting and delivering solutions you will be
Implications
maturing your current and implementing new
DevOps capabilities. This will create a readiness
to act more as a cohesive group.
• All teams must be committed to collaboration at
the beginning and this commitment must be
upheld when pressures or problems arise.
Key • This model requires a high degree of trust
Challenges amongst senior stakeholders and management
to drive towards mutually beneficial solutions and
sufficient support.
Highlight your chosen governance model and use this opportunity to explain why it was the best-fit model
based on your organizational culture, processes, and environment. Import outcomes from Exercise 3.5.
Integrated Governance
• Integrated governance means that you will
permanently re-structure your governance groups so
that any governance decisions will be made by a
centralized body irrespective of the functional group.
• Integrating your governance groups will require some
changes in your organizational design and your
current governance processes to accommodate both
development and operations roles and
accountabilities.
• A solitary governance group will monitor and evaluate
the DevOps practice based on business need and
management feedback, and direct future directions
based on these feedback loops.
• By having a single governance group you reduce
diversity of thought, empowerment, and risk losing
equal representation from development and
operations.
• Bringing together groups can introduce conflict in
terms of vision for future direction, and may result in
some initial growing pains, especially where a skilled
moderator isn’t present.
Info-Tech Research Group 22
[Organization Name]’s target state organizational design

Our newly defined roles and governance structure were integrated together to create the following
organizational design. Use the remainder of this space to create a few highlighted changes and explain
why these are important in your transition.

CIO
Evan D.

Orange outlines
Apps represent new
Director integrated
Will R.
governance
structure
Apps Operation
Manager s Manager
Larysa L. Luke A.

Release
QA App Ops SysAdmin
Manager
Kathy G. Lorenzo M. Tanya V. Daniel B.

Dev DBA
Julia S. Adrianna A.

From Exercise 3.6, detail your target state organizational design.

Info-Tech Research Group 23

Changes to implement target state organizational design

The following key changes are highlighted with details on why this decision is important and how we
plan to get there.

Key changes Details

Establish Communities of • Establish a dedicated space for meetings for CoPs.
Practice (CoPs) to facilitate • Establish a schedule for meetings.
cross-team learning • Have attendance from a member of the governance team document results of
these meetings and monitor cultural progress.

Bring together business and • Improve the strength and effectiveness of technical and business leadership to
technical leadership ensure shared objectives.

Establish a separate QA • This will transfer to shared ownership over time with developers; however, we
department to own test need to establish an ownership of process during the inception of functional
automation capability test automation.

Shift from the concept of • Shift mentality of working within a siloed set of tasks to a cross-functional team
internal silos to application delivering towards the support of a product.
teams • Helps to build cross-functional alignment.

Introduce product owner role • Creates a stronger interface point between the business and IT.

From Exercise 3.6, list your brainstormed strategies for reaching your target state organizational design.

Info-Tech Research Group 24

 [Organization Name]’s target state product delivery process
with DevOps

Define
Define
Frequent intake Define
Define Epic
Epic Product Approved? Product
Product/Portfolio of business need Backlog
Backlog
Product
Backlog,
Roadmap
Roadmap
Manager Product
Roadmap,
Create
Create Define
Define Define
Define Refine
Refine Status
Elicit
Elicit Business
Business Sprint
Test
Test Features
Features and
and Product
Product Sprint Reports
Business + Development + Operations

Requirements
Requirements Backlog
Strategy
Strategy Releases
Releases Backlog
Backlog Backlog
Product
Owner Define
Refine Backlog Refine Define Design Working
Refine Refine Acceptance Design
Backlog Item Requirements Acceptance Solution
Backlog Requirements Criteria Solution Code With
Criteria
Automated
Test, Build,
No Yes
Yes and Deploy
Create
Create Test
Test Sprint
Works?
Code
Code Code
Code Done?
No
Plan,
Define, Accept
Accept User
User Retrospective
Retrospective Deploy
Deploy Update Tool-
Review
Review
DevOps
Design, Support
Support
Requests
Sprint
Sprint
Demonstration
Demonstration
and
and Feedback
(refine
(refine
process)
Prod.
Prod.
Version
Based
Team Requests Feedback process) Version Documentation
Build, Required to
Test, Enhance,
Incidents, Adopt, and
Deploy, Issues, Support the
Problems
Maintain Product

Maintain

Import target state process flow from Exercise 3.7.

Info-Tech Research Group 25

[Organization Name]’s target state product delivery toolchain

The following is our planned standardized toolchain across our development and operations groups. By
standardizing these as our tools, we can ensure integration through the product lifecycle and any new
acquisitions of tools in the future can be vetted to integrate with the entirety of our current system.

VersionOne Azure DevOps JIRA

Define Design Develop Test Deploy Maintain

HP
Visual
GIT SVN Quality Hudson Azure
Studio
Center

Import target state toolchain from Exercise 3.8.

Info-Tech Research Group 26

Changes to accommodate target state process and toolchain

Key changes Details

Establish policy on tool • Get teams working with the same tech stack so any innovations are broadly
standardization across teams applicable across the organization.
• Ensure that there is integration across the product lifecycle for monitoring
purposes.

Automate configuration • Standardize environments across dev, test, etc. to reduce defect rates in
management production that result in variations in system consistency.

Develop standards for handoff • This will transfer to shared ownership over time with developers; however, we
between Dev and Ops need to establish an ownership of the process during the inception of
functional test automation.

Continuous assessment • Incorporate monitoring tools earlier in development process.

• Measure which features are most valuable to the customer; streamline efforts
for high customer value.
• Continuously measure the business value that an application delivers –
provide longitudinal data to track deviations and prioritize future investments
into high-value features.

Continuous integration • Establish single-source repository.

• Establish build automation and test automation.
• Get developers in practice of committing to main trunk every day.

Continuous deployment • Continuously deploy code to production as features are completed and
release criteria have been met.
• Keep a higher bar of quality in development group, reducing overall defect
rates.

Detail results from Exercise 3.7 and 3.8 on your brainstormed strategies for reaching your target state
process and tools. Import any lists, processes flows, etc. here.

Info-Tech Research Group 27

[Organization Name]’s target state metrics program
The following metrics were determined to align with our overall objectives for adopting DevOps, and are
strategically aligned to promote collaboration across our development and operations groups.

DevOps Objective Supporting Capabilities Metrics

Faster delivery of features
Increased operations stability
Decrease time on maintenance; free up
time for innovation
Improve business-IT alignment
Improve product quality
• Deployment automation
• Continuous integration
• Continuous delivery
• Automated environment configuration
• Collaboration
• Communities of Practice
• Applications performance management
• Agile operations
• Automated testing
• Collaborative workspaces
• Mentoring programs
• Linking incentives and awards to business
objectives
• Cross-functional collaboration
• Service-oriented architecture
• Service virtualization
• Release automation
• Test automation
• Cross-functional collaboration
• Real-time application monitoring
• Lead times
• Cycle times
• Deployment frequency
• Defect cycle time
• Mean time to repair (MTTR)
• Resolution time for identified capacity
bottlenecks
• Downtime (hours per month)
• Percentage of preventative vs. reactive
maintenance
• New features introduced per year
• Employee satisfaction surveys
• Net promoter scores (NPS)
• Percentage of deployments rolled back
due to code defects
• Outages or negative user reactions
• Number of repeated incidents
• Number of escalations

Import from Exercise 3.9.

Info-Tech Research Group 28

Metrics collection approaches

Collection methods, locations of the metrics, and timing of collection were collected for each metric to
enable continuous monitoring of our DevOps environment.

Metric Collection Method Location Audience Timing

Lead time Time measured between Accessible by • DevOps governance group Reported at
the elicitation of request from • Business stakeholders release on a per-
business requirements PMO • PMO feature basis
to the release to
customer
Deployment Frequency auto- Stored in • DevOps governance group Reported to
frequency collected from AWS dashboard in • Dev teams teams at end of
CodeDeploy AWS CodeDeploy • Ops teams sprint
Mean time to repair Collected by Operations Stored in Ops • DevOps governance group Reported for
(MTTR) Manager after resolution Mgmt. dashboard • Business stakeholders trend analysis on
of a system failure • Ops teams a monthly basis
Number of repeated Auto-collected by Stored in Ops • DevOps governance group Weekly
incidents ServiceNow Mgmt. dashboard • Ops teams dashboard email
• Apps Support distribution
Net promoter score Collected by survey of Marketing • DevOps governance group Collected on a
(NPS) customers • Business stakeholders per-quarter basis.
• PMO
• Dev teams
• Ops teams

Import from Exercise 3.10.

Info-Tech Research Group 29

Target state assumptions

Target State Assumptions

• A series of internal workshops will be run in 2019 to establish an initial understanding of DevOps and validate the hypothesized
value/ROI to the organization. This will help build the necessary consensus in high-level stakeholders to make some of the
necessary transformational changes to support our end state.

• Workshops will continue to be run in years subsequent to 2019 and will be delivered as part of a program offered by the
Applications Center of Excellence (CoE).

• Internal learning and development will be absorbed by the Applications CoE over time to provide an onboarding program for
future scalability of our DevOps program.

Info-Tech Research Group 30

Build and continuous refinement of DevOps

Finally, with the right people performing the right processes with the right monitoring
and governance in place, begin to use DevOps tools to assist in transforming
RE

towards your desired target state. Seek further gains by automating error-prone
UT

manual processes, as long as there is an established business case that

UC

demonstrates the cost-benefit of doing so. Make the modifications to your processes
R
ST

and people foundations where necessary.

G
TI N
OR

With your teams aligned to your DevOps function in terms of skills and
PP

structure, optimizing your processes is the next logical step. Create

SU

initiatives to align your current process with your desired target state,
focusing first on components that do not have associated tooling
changes. Revise your people foundation as needed.
N

The initial timeline objectives of your roadmap should focus on

TIO

getting the people components (organizational design, culture,

DA

competencies, and governance framework) in place. These

UN

provide the foundational collaborative structures for people to

FO

act upon your target state processes and to use your desired
tool as intended.

Info-Tech Research Group 31

 [Organization Name]’s DevOps adoption roadmap
DevOps Roadmap Q1 19 Q2 19 Q3 19 Q4 19 Q1 20 Q2 20 Q3 20 Q4 20 Q1 21 Q2 21 Q3 21 Q4 21
Culture, Measurement & Sharing
Define team metrics
and adjust roles and                        
responsibilities
Distribute guiding
principles/manifesto
Initiative Project A –
Knowledge sharing
Project B – L&D
capability                        
development
Training Module A -
                       
Testing
Project C – Personnel
evaluations and                        
competency building

Lean Product Delivery Process

Training Module B –
                       
Lean methodology
Project D – Version
                       
control
Product Delivery Automation
Project E –
Continuous                        
integration
Project F –
                       
Continuous delivery

Import from Exercise 4.1.

Info-Tech Research Group 32
Detailed breakdown: Culture, measurement, and sharing

Project Associated Capabilities/Details Impacted Metrics

Project A – Knowledge • Implement information knowledge-sharing mechanisms • Wiki contributions
sharing to facilitate increased collaboration across functions. • Westrum scores
• Implement shared learning structures for increasing • Employee satisfaction surveys
collaboration within roles – increase competencies
across teams:
o Dev, Test, and Ops Communities of Practice
• Have the presenter document best practices into
internal wiki database to centralize information for future
onboarding.
Project B – Learning and • Structure internal learning and development program to • Cycle times
development capability begin to absorb lessons from upcoming training
modules and convert them into training modules for
future onboarded teams.

Training Module A – • Provide external training on improving testing outcomes • Downtime (hours/month)
Testing in development cycle. • Cycle time
• Teach fundamentals to both development and • Release frequency
operations sides to build empathy for • Defect rates
upstream/downstream effects.

Import from Exercise 4.1.

Info-Tech Research Group 33

Detailed breakdown: Lean product delivery process

Project Associated Capabilities/Details Impacted Metrics

• Train teams on Lean principles and the associated • Cycle time
principles and methodologies to enable broad-scale • Defect rates
Training Module B – Lean improvements to the predictability of SDLC. • Deployment frequency
methodology • Lead times

• Implement a version control strategy. Define each • Cycle time

artifact and how it is used in your development process • Defect rates
and which application or system it is used for. • Deployment frequency
Project D – Version control
• Identify the tool that is or will be used to version each • Lead times
artifact and the criteria for it to be versioned (e.g. the
acceptance criteria) across the development group.

Import from Exercise 4.1.

Info-Tech Research Group 34

Detailed breakdown: Product delivery automation

Project Associated Capabilities / Details Impacted Metrics

• Incorporate Lean principles as an underpinning – build • Cycle time
quality in, optimize the whole. • Resolution time for identified capacity
• Build automation, test automation, removal of error- bottlenecks
Project E – Continuous
prone manual tasks impacting the cycle times. • Percentage of deployments rolled back
integration • Infrastructure as code: enabler for automated due to code defects
deployments in upcoming project.

• Deployment automation: Quickly deliver features from • Defect cycle time

development to production in a regular and frequent • Mean time to repair (MTTR)
manner with on-demand capabilities. • Deployment frequency
• Environmental consistency: Generate repeatable • Lead times
Project F – Continuous
deployment processes for various production
delivery environments.
• Release automation: Shorten deployment cycles to
enable quicker flexibility and agility to changing
requirements and conditions.

Import from Exercise 4.1.

Info-Tech Research Group 35