TEXAS

DEVOPS

INFLUENCING A DEVOPS CULTURE

T E X A S

D E V O P S

M E E T U P

SPEAKERS INTRO

Darryl Bowler (Co-Organizer of Texas DevOps)

Anthony Barnhart (Co-Organizer of Texas DevOps)

AGENDA

• Why is Culture a Critical Element of DevOps

• Link between culture and organizational performance

• What are the Key Component of a DevOps Culture

• Diagnosing Culture

• How to Change Culture

PART 1:Why is Culture a Critical

Element of DevOps

WHAT IS ORGANIZATIONAL

CULTURE?

Culture indicates the „way of life‟ for

workers who often take its influence for

granted (they simply accept it).

• How things get done around here

• Beliefs and Values

Culture is stable over time and it resists

quick changes (the status quo prevails) due

to the interwoven threads.

CORPORATE CULTURE THREADS

CORPORATE CULTURAL APPROACHES

WHY USE A CULTURAL MACRO

FRAMEWORK?

The Denison Model

• Based on 20 years of research

• How corporate culture impacts business performance

• Empirical, Quantitative and Qualitative

• Frames the how we influence a DevOps culture based on

real research (Macro and Micro)

WHAT THE RESEARCH

REVEALED: LINK BETWEEN

CULTURE AND PERFORMANCE

DISTILLING THE MODEL

Adaptability Creating

Change

Customer

Focus

Organization

al Learning

Patterns,

Trends,

Markets

Mission Strategic

Direction &

Intent

Goals &

Objectives

Vision Direction,

Purpose,

Blueprint

Consistency Core Values Agreement Coordination

& Integration

Systems,

structures,

Processes

Involvement Empowerment Team

Orientation

Capability

Development

Commitment,

Ownership,

Responsibility

THE PARADOX OF DYNAMIC

CONTRADICTION

• Tension between the

opposing dimensions of the

model

• External vs Internal

• Stable vs Flexible

• Consistency vs Adaptability

• Mission vs Involvement

CHARACTERISTICS OF A

GENERATIVE CULTURE

(2015 STATE OF DEVOPS) DEVOPS

DEVOPS – THE LINK BETWEEN

CULTURE AND IT

• DevOps is ALL about culture

• Culture

• Automation

• Lean

• Measurement

• Sharing

PART 2: What are the Key Component

of a DevOps Culture

WHAT ARE THE KEY COMPONENT OF

A DEVOPS CULTURE

Learn to Trust

Understand Motivations

Eliminate Blame

Embrace Smart Failure

Focus on Bottlenecks and Flow

Eliminate Unplanned Work

Be Continuous

Form Dedicated, Cross-Functional Teams

Love Transparency

Build Autonomy, Mastery and Purpose

1. LEARN TO TRUST

• Core to DevOps culture

• Dev / Ops / QA / Business

• All groups must believe in each other

"The first dysfunction is an absence of trust among team members. Essentially, this stems from their unwillingness to be vulnerable within the group. Team members who are not genuinely open with one another about their mistakes and weaknesses make it impossible to build a foundation for trust.“ – Lencioni

• Trusting teams admit their weaknesses and mistakes

2. ELIMINATE BLAME

• Blame is the Kryptonite to trust

• Blame Eliminates

• Openness

• Collaboration

• Blame exacerbates silo‟d behaviors

• Blame prevents teams from focusing on the real problems

3. EMBRACE SMART (FAST)

FAILURE

• Lean concept – Fail fast

• Minimize wasted / expense of a failed idea (waterfall)

• Constant testing of hypothesis

• Driving a culture of smart failure breeds innovation

• Implies high trust and a safety net

4. LOVE TRANSPARENCY

• Improve knowledge flow and transparency

• Eliminate knowledge hoarders

• Hoarders restrict flow of work

• Example are people that attribute job security with a

process ( such as deployment) or tool and “hide”

information

5. FOCUS ON BOTTLENECKS

AND FLOW

• Take a systems view of flow

• Theory of constraints

• Eliminate bottlenecks

• Align Devs / Ops /QA to prevent local optimization

• Example practice on putting Devs on call for their software

6. UNDERSTAND MOTIVATIONS

• Motivations drives behaviors

• Understanding motivations helps understand behaviors

• Behaviors can me misunderstood as

• Personality clash

• Sabotage

• In reality could have a legitimate reason

• Helps minimize conflict and increase team gel

7. BUILD AUTONOMY,

MASTERY AND PURPOSE

• Psychology of motivation

• Intrinsic and extrinsic rewards

• Intrinsic examples

• Autonomy

• Sense of achievement

• Extrinsic rewards

• Pay rise

• Promotion

• Bonuses

PART 3: Diagnosing Culture

DIAGNOSTIC PART 1

MAP END-TO-END VALUE STREAM

(CONCEPT TO CASH)

Quantify each step in the process based on

the dimensions of:

• Adaptability

• Mission

• Involvement

• Consistency

VALUE STREAM EXAMPLE: BEFORE STATE

(CONCEPT TO CASH)

Business owner has a new idea

5 minutes elapsed time

5 minutes valued added

Business owner and product owner

agree on new feature

30 minutes elapsed time

30 minutes valued added

SCRUM team agree it can

go into the next sprint

1 day elapsed time

30 minutes valued added

Integration (merging) of new

software

1 day elapsed time

QA Test Team

2 days elapsed time

1 hour valued added

Retrospective and Review

2 hours elapsed time

2 hours valued added

From conception to release

candidate

6.5 days elapsed time

2.5 days valued added

4 days of potential waste

Team creates new feature

2 days elapsed time

2 days valued added

Staging at UAT

0.5 days elapsed time

CHANGING RITUALS, HABITS

AND ROUTINES

Preserve and Strength

Invent and Perfect

Unlearn and Leave Behind

Rethink and Try Again

Good

Bad

Old New

MAP CULTURAL SYSTEM

Identify sources of culture

Power and politics

Role of leadership

Understanding motivations

motivational theory

Needs

BMOD

Reward system

MATURITY MODEL

Practice Binary Configuration Environment and

Deployment

Compliance

Management

Testing Data Management Configuration

Management

Level 4 (A)

Optimizing:

Focus on

Process

Improvement

Teams share knowledge

regarding integration

problems and resolve

them, with automation,

faster feedback and

visibility

All envs managed

effectively. Provisioning

fully automated.

Virtualization used if

applicable

Operations and delivery

teams regularly

collaborate to manage

risks and reduce cycle

times

Production rollback

rare. Defects found

and fixed

immediately

Release to release

feedback loop of

database

performance and

deployment process

Regular validation that

CM policy supports

effective collaboration,

rapid development and

auditable change

management process

Level 3 (B)

Quantitatively

Managed:

Process

Measured and

Controlled

Build metrics gathered

and made visible and

acted on. Builds are

accelerated and

incremental. Build audit

shows matching source to

executable.

Orchestrated

deployment managed.

Release and rollback

process tested.

Application health

monitored and

proactively managed.

Cycle time monitored

Quality metrics and

trends tracked.

Nonfunctional

requirements

defined and

measured

Database updates

and rollbacks tested

with every

deployment.

Database

performance

monitored and

optimized.

Developers check-in to

mainline at least once a

day. Branching used for

release.

Level 2 (C)

Continuity:

Automated

processes

applied across

the application

life cycle.

The technology stack is

coordinated for consistent

binary creation and server

configuration.

Fully automated self-

service push button

process for deploying

software. Same process

to deploy to every

environment.

Change management

and approval process

defined and enforced.

Regulatory and

compliance conditions

met,

Automated unit and

acceptance tests,

the latter written

with testers.

Testing part of

development

process

Database changes

performed

automatically as part

of deployment

process.

Libraries and

dependencies

managed. VC usage

policies determined by

change management

process.

Level 1 (D)

Repeatable:

Process

documented

and partly

automated for

individual Team

Regular automated build

and testing. Any build can

be recreated from source

control using automated

process.

Automated deployments

to some environments.

Some configurations

versioned.

Painful and infrequent

but reliable releases.

Limited traceability from

requirement to release.

Automated tests as

part of story

development.

Changes to database

with automated scripts

versioned with

application

Version control used for

everything required to

recreate software:

Source code, build and

deployment scripts

Level 0 (F)

Regressive:

Process

unrepeatable,

poorly

controlled and

reactive

Manual processes for

building software. No

management of artifacts

and reports

Manual process for

deploying software.

Env specific binaries.

Envs provisioned

manually

Infrequent and unreliable

releases

Manual testing

after development

Data migrations un

versioned and

performed manually

VC not used or check-

ins are infrequent.

PART 4: How to Change Culture

THE PATH TO CHANGE

Mayr's Organizational Management

KOTTER’S APPROACH

Establishing a Sense of Urgency

Creating the Guiding Coalition

Developing a Vision and Strategy

Communicating the Change Vision

Empowering Employees for Broad-Based Action

Generating Short-Term Wins

Consolidating Gains and Producing More Change

Anchoring New Approaches in the Culture

TEXAS DEVOPS

START YOUR JOURNEY TODAY

• Decide that changed is needed

• Find a compelling reason that resonates with the organization

• Do initial assessment to see where you are

• Perform self-diagnostics and make comparisons with similar firms

• Map the gap, current state -to- future state

• Build roadmap

• Implement program

• Review – Reassess

• Iterate