ADOPTING DEVOPS

Adopting DevOps is a transformative journey that reshapes how

organizations approach software delivery and operations by focusing on
collaboration, automation, and continuous improvement.
 What It Means to Adopt DevOps

• A Philosophy, Not a Product: DevOps isn’t about purchasing a tool or

following a rigid process. It's about embracing a culture and mindset
centered around collaboration, efficiency, and delivering value to
customers faster and more reliably.

• Transformational Change: Adopting DevOps requires fundamental

changes across people, processes, and tools. It’s a long-term
commitment to evolving the organization.
 Key Principles of DevOps

• Collaboration: Break down silos between development, operations,

and other teams.

• Continuous Improvement: Embrace iterative changes and feedback

loops for consistent growth.

• Lean Principles: Focus on eliminating waste, improving flow, and

delivering value.
 Creating a DevOps Adoption Playbook

• Assess Current State (Point A):

• Evaluate your organization's maturity in existing practices and capabilities.
• Identify gaps and areas needing improvement.

• Define Desired State (Point B):

• Establish clear business goals and objectives DevOps will help achieve (e.g., faster releases, higher
reliability, reduced errors).

• Chart the Roadmap:

• Create a step-by-step plan with actionable "plays" to address gaps and build capabilities.
• Prioritize changes based on impact and feasibility.

• Iterate and Evolve:

• Continuously revisit and update the playbook to reflect progress and adapt to emerging challenges.
 Four Core Areas for DevOps Transformation
• Process Improvement
• Streamline workflows to reduce inefficiencies.
• Adopt practices like Continuous Integration (CI) and Continuous Delivery (CD).
• Eliminate bottlenecks to improve delivery speed.

• Tools for Automation

• Use tools to automate repetitive tasks, making processes consistent and error-free.
• Examples include CI/CD pipelines, infrastructure as code (IaC), and automated testing tools.

• Platform and Environments

• Build resilient, scalable, and elastic platforms to support development and production.
• Implement environment standardization to ensure consistency across the application lifecycle.

• Culture
• Foster trust, communication, and collaboration among teams.
• Encourage shared responsibility and ownership of outcomes.
 Why Adopting DevOps Is a Journey
• Different Paths for Different Organizations: Each organization has
unique needs, challenges, and starting points. There’s no one-size-fits-
all approach.

• Variable Maturity Levels: Teams may vary in their maturity,

requiring tailored strategies for different parts of the organization.

• Continuous Evolution: DevOps is not a static goal but a dynamic

process of growth and adaptation.
 Path to DevOps Adoption
1. Plan and Measure
• Align on Goals and Outcomes:
• Define clear objectives
• Establish key performance indicators (KPIs) to measure success.

• Assess Current Capabilities:

• Evaluate your current development and operations processes to identify
strengths and areas for improvement.
• Conduct a gap analysis to understand the differences between your current
state and the desired DevOps state
• 2. Develop and Test (Collaborative and Continuous)
• Foster Collaboration
• Implement Continuous Integration (CI)
• Continuous Testing
• 3. Release and Deploy
• Continuous Delivery (CD)
• Continuous Deployment
• 4. Monitor and Optimize
 Developing Devops Playbook
• DevOps adoption playbook includes multiple plays that are
appropriate to the situation, whether it is at a team, project, program,
division, or enterprise level.

• To create such a DevOps transformation playbook, you need three

core ingredients:
1. A clear definition of the target state (business goals and drivers)
2. An understanding of the current state (current capability and maturity)
3. A determination of the best path to take, or plays to run (risk-value
investment balance)
Identifying the Target State (Business Goals and Drivers)
• 1. Role of IT in Supporting Lines of Business (LOBs):

• IT systems are the vehicle for delivering business value to customers

and users.
• Examples of business value include: hailing a taxi, operating a weapons
system, paying taxes, or managing payroll.

• IT enables feedback loops:

• Understanding how users consume and interact with business capabilities.
• Identifying new or enhanced features to improve value.
2. IT's Challenges and Shadow IT:
IT often struggles to keep up with LOB needs, leading to shadow
IT.

• 3. Key Deliverables Expected from IT Departments by LOBs:

General Expectations:
• Velocity: Fast delivery of systems.
• Agility: Ability to adapt quickly.
• Innovation: Development of new capabilities.
• Quality: Reliable and effective solutions.
• Lower cost: Cost-efficient systems.
3. Specific Business and Technology Requests:

• Business Requirements:
• Faster time to value.
• Speedier deployment.
• Lower cost/time for delivery and testing.

• Technology Requirements:
• Increased test coverage.
• Better environment utilization.
• Reduced deployment-related downtime and issues.
• Minimized rollbacks of deployed apps.
• Faster defect reproduction and resolution.
• Lower mean time to resolve (MTTR) production issues.
• Reduced defect cycle time.
• 4. IT's Need for Transformation:

• IT must continually evolve to meet changing LOB demands, addressing:

• Performance.
• Scalability.
• Cost-effectiveness.
• Responsiveness.
 Solution
• The solution, of course, is to undergo a DevOps transformation that enables IT departments
to adopt the necessary practices, automation tools, and organizational and cultural change to
deliver applications and services with velocity and agility, and become innovative by being
able to deliver rapid experimentation.

• One of the core goals of DevOps is to achieve maximum efficiency with an application
delivery pipeline by optimizing the pipeline.

• This need for innovation, in turn, drives the need to adopt new technology platforms and
processes that are designed for innovating at speed—for example, a Cloud-based “Platform
as a Service” (PaaS) that inherently delivers all the necessary DevOps services.
 Assessing the Current State
• To start assessing current maturity, let’s start with some core questions about
your organization’s capabilities:

1. Are you able to rapidly deliver new, innovative applications and to

leverage modern architectures?

2. Are you able to modernize existing applications to allow for faster

delivery and innovation?

3. Are you able to adapt culture, tools, and processes to help you succeed?
• Properly addressing the challenges in these areas requires a three-step
process:

1. Identifying the inefficiency or waste

2. Identifying the root causes of the inefficiency or waste

3. Developing a plan or play to address the root causes

Identifying the Inefficiency or Waste with Value Stream
Mapping

• “Anything that depletes resources without adding customer value”.

• This waste comes in several forms, most of it caused by process and

governance overheads placed on the practitioners, and extra steps
added to processes
 Examples of Waste
 Unnecessary process steps
 Unnecessary rework
 Unnecessary features
 Building the wrong artifact or process
 Transforming an artifact constructed by someone else
 Waiting for someone else to act on an action or task
 Waiting for an approval
 Waiting for an environment
• Most of the waste happens during handoffs between stakeholders,
especially across functions, and when a practitioner waits for someone
else to act.

• Another source of waste at the handoffs is the artifacts being passed on

from one stakeholder to the next not being “usable as is”.

• The artifacts require the receiving stakeholder to modify or transform

the artifacts before they can be used or need to return them to have them
reworked.

• Lean methodologies refer to the metric measuring this as %Complete

and Accurate (%C&A)
 Value Stream Mapping
• The most effective way to identify these sources of waste and inefficiency.

• A tool to identify waste and inefficiency in processes.

• The primary purpose of VSM is to visualize the entire process, from the start to the finish.

• To understand how value is created, and to identify bottlenecks, inefficiencies, and

opportunities for improvement.

• In the context of DevOps, doing a value stream mapping exercise involves looking at the
flow of requests Starts with incoming requests and ends with applications running in
production.
• Types of requests
 New requirements
 Enhancement requests
 Change requests
 Bug fixes
 Policy changes
 Configuration changes
 Content updates

• They include essentially anything that causes a change to the

application running in production
• End Goal:

• Reduce waste or eliminate non-value-add work to improve delivery pipeline

efficiency.

• Replace inefficient processes with better alternatives.

• Key Elements to Examine:

• Artifacts: Items moved through the pipeline (e.g., requirements, code).

• Stakeholders: People responsible for each process step.

• Environments: Systems or stages where processes occur.

• Processes: Steps for moving artifacts through the pipeline.

• Sources of Waste:
• Inefficient processes.
• Manual processes.
• Incorrectly formatted artifacts.
• Inefficient handoffs between stakeholders.
• Stakeholders lacking access to needed artifacts.
• Time spent on unnecessary tasks or artifacts.

• Approach to Improvement:
• Perform root-cause analysis to identify why waste occurs.
• Implement solutions to remove inefficiencies and enable continuous
improvement.
 Using a Value Stream Map

What is VSM?
• A method to visualize and analyze the flow of value through a delivery pipeline.
• Helps identify bottlenecks and waste in processes.

• Two Ways to Visualize Processes

• Activity-Centric:
• Focuses on the operations and their order.
• Best represented by flowcharts or IDEF diagrams.

• Artifact-Centric:
Focuses on work products (artifacts) and their state transitions.
Treats artifacts as state machines undergoing transformations.
 Steps to Conduct a VSM Exercise
• Analyze Activities and Artifacts:
• Track an artifact through the delivery pipeline.
• Observe how stakeholders transform artifacts and create new ones.

• Identify Waste and Bottlenecks:

• Conduct in-process analysis to determine sources of inefficiency.
• Capture bottlenecks in a value map.
 Key Metrics in VSM

• Process Time:
• Time spent performing the work.

• Lead Time:
• Total elapsed time from when work becomes available to when it is
completed.

• % Complete and Accurate (%C&A):

• Measures the quality of work handed off between stakeholders.
 Types of VSM Exercises
• In-Depth VSM:
• Multi-day or multi-week effort.
• Involves detailed measurements of wait times, process times, and practitioner
activities.
• Common in manufacturing for optimizing labor-intensive processes.

• Overview VSM:
• Half-day to one-day workshop.
• Focuses on identifying major bottlenecks in an exemplary delivery pipeline.
• Conducted with executive leadership rather than practitioners.
 Outcome of VSM Exercises
• Root-Cause Analysis (RCA):
• Analyze bottlenecks to identify their root causes.
• Address root causes as part of the DevOps adoption roadmap.

• Streamlined Processes:
• Use VSM insights to reduce waste and improve efficiency.
Implications for Value Stream Mapping (VSM)
• Inherent Complexity:
• Software delivery involves iterative and non-linear activities, which can
complicate VSM compared to linear assembly lines.

• Quality Metrics:
• Software delivery incorporates quality measures like % Complete and
Accurate (%C&A) that are less relevant.

• Stakeholder Dynamics:
• Software pipelines require alignment across diverse teams (developers, testers,
operations) with differing priorities.
 Challenges with Value Stream Mapping (VSM) in Software

• Variability: Process and wait times in software delivery are highly

variable, making detailed VSM less effective.

• Focus Area: Overview VSM, aimed at identifying major bottlenecks,

is more suitable for software pipelines.
 Conducting a Value Stream Mapping Workshop
• A value stream mapping workshop is best carried out with executives who have decision-making
ability.
• VP or executive owner of the line of business
• VP or executive owner of application development
• VP or executive owner of Quality Assurance (QA)
• VP or executive owners of operations

• In addition, other key stakeholders can also add value to the workshop but are optional, such as
executives from the following departments:
• Security
• Enterprise architecture
• Program Management Office (PMO)
• Product/offering management (if it exists)
• The workshop is done as a series of exercises, with a facilitator driving
and guiding the executives who are participating.

• Here is the recommended set of exercises to run:

Identify business goals for the customer that is driving them to adopt or consider DevOps
as a practice.
Identify IT initiatives that are already underway or planned for DevOps. These initiatives
are then mapped back to the business goals to clarify alignment.
Create a value stream map to identify bottlenecks and inefficiencies found by the
executives that are preventing them from achieving identified business goals.
Identify a prioritized list of three to four capabilities that can help them address the
identified bottlenecks.
Create a roadmap of adoption for those best practices—with milestones, time frame
(dates), and identified challenges to their adoption.
 Best way to create a value stream map
• Take one artifact, typically a new requirement, through the delivery
pipeline
• The artifact (new requirement) as stakeholders execute processes on it to
change its state and then hand off to other stakeholders.
• As this happens, for each stakeholder and handoff, you need to identify
any source of waste.
• Waste comes in two main forms,
1. Wait times—When a stakeholder is waiting for an action or for an artifact
handoff, from another stakeholder
2. Overproduction or wrong production—When a stakeholder changes the state of an
artifact that is unnecessary or that does not add any value to the end deliverable
 Diagnosing the Root Cause

• Purpose: Identifies the underlying reasons for bottlenecks and

inefficiencies rather than addressing surface symptoms.
 Common Bottlenecks and Their Root Causes
• Tool Integration Issues:
• Symptoms:
• Wait times occur as artifacts transition between team members.
• Lack of visibility and coordination among team members.
• Difficulty collaborating across team boundaries.
• Root Cause:
• Absence of an integrated delivery pipeline that facilitates seamless transitions and visibility.

• Lack of Standardized Environments:

• Symptoms:
• Disconnected development and testing environments that differ significantly from production
environments.
• Multiple independent technology stacks requiring separate management.
• Inability to deploy applications based on factors like risk, value, and technology fit.
• Root Cause:
• Lack of standardization and uniformity across environments, leading to inefficiency and errors.
 Actionable Insights
• Integrated Delivery Pipelines: Implement tools and practices that ensure
visibility, coordination, and streamlined handoffs between team members.

• Standardized Environments: Use standardized, automated environments

that closely mimic production to reduce errors and increase efficiency.

• Balanced Resource Allocation: Shift resources strategically to support

both innovation and maintenance, ensuring balanced delivery pipelines.

• Focus on Business Capabilities: Align delivery pipelines to enable

business-wide capabilities rather than isolated application releases.
 Transformation Plays
• Choosing the Right DevOps Capabilities
• Focus on root causes of bottlenecks to select appropriate DevOps capabilities.

• Consider business, technical, and organizational factors before adoption, such as:

 Ability of the project team to consume the process and tool changes
 Ability of the broader organization to consume the organizational changes
 Investment available to fund the adoption
 Project timeline
 Time available to show results
 Executive buy-in and sponsorship
 Practitioner buy-in
 Cultural inertia
 Areas to Address for Each Bottleneck

• Process improvement.
• Automation tools.
• Environments and platforms.
• Culture.
 Adopting Transformation Plays
• Key Challenges:
• Addressing the productivity dip during change.
• Overcoming cultural inertia.

• Minimizing the Productivity Dip:

• All changes result in an initial drop in productivity ("the dip").
• Success depends on:
• Proper planning to minimize the dip.
• Utilizing experienced DevOps coaches.
• Setting clear goals and KPIs for productivity improvements.
• Importance of KPIs:
• Identify KPIs before the transformation begins.
• Use baseline metrics to measure progress.
• Define clear success goals for post-transformation productivity.

• Critical Success Factors:

• DevOps coaches play a vital role in guiding teams.
• A well-planned roadmap ensures smoother transformation and
faster recovery from the dip.
• Align transformation efforts with business drivers and measurable
KPIs.
 Initiating Adoption with Pilots

Start Small with Pilot Projects

Goal of Pilot Projects

Measure Success with KPIs

Assign DevOps Coaches

Project Selection Criteria

Scaling Adoption
 Overcoming Cultural Inertia
• Understanding Cultural Inertia
• Inertia is the resistance to change ingrained in an
organization’s culture.

• Common symptoms include:

• “This is the way we do things here.”
• Processes and approvals with unclear origins or purposes.
• Reports and artifacts that are no longer relevant but remain in
place.
• Responsibility divided along organizational lines, leading to
silos.
Steps to Overcome Inertia
Examine inefficiencies in artifacts, processes, and governance.
Identify and address the root causes of bottlenecks and waste.

Role of Leadership
•Executive leadership must actively sponsor and lead the transformation.
•Provide support and protection for practitioners driving change.