© Lamri Ltd 2014© Lamri Ltd 2014

Making DevOps Business as UsualGraham Dick

Lamri

20th November 2014

© Lamri Ltd 2014

IT and OpsThe Agile revolution

– Has brought Dev closer to the Business,

in an attempt to deliver Value faster

– But there is a cost ….

Business Customers

Dev

Ops

services

Agile closes the gap

gap

The DevOps movement has emerged in response to this gap

• The cost

– Is a gap between Dev and Ops.

Symptomized by

• Excess work in progress

• Excess Service fragility

• Long project wait lines (shadow IT)

Tension /

Back-

pressure

Drives local

optimisation

© Lamri Ltd 2014

What does DevOps look like?

Ops

Dev

Sharing to enable improvement• Of ideas and problems

• Of success stories

Automation• Continuous integration / Testing

• Continuous delivery / deployment

• Version management of all environments

• Proactive monitoring of application health

Culture• No-blame

• Freedom to experiment

• Local accountability

Deploy code 30 times more frequently

25% respondents report deployment times reduced to less than 1 day; 50%

reduced to less than 1 hour

50% reduction in failures following changes

75% of respondents able to restore service in under 1 hour (12 times faster than

lower performing peers)

Measurement• Deployment frequency

• Lead time to change

• Meantime to recover from failure

2014 State of DevOps Report

© Lamri Ltd 2014

Talk about Culture

Leadership(style, values, habits)

Strategy(goals, success measures, rewards)

Structure(roles/responsibilities, organisation)

Processes(policies, operations, value chain, business processes)

People(values, beliefs, attitudes, norms, habits)

Culture

Introduction to ICAgile – Ahmed Sidkey Feb 2014

© Lamri Ltd 2014

Talk about Culture

Leadership(style, values, habits)

Strategy(goals, success measures, rewards)

Structure(roles/responsibilities, organisation)

Processes(policies, operations, value chain, business processes)

People(values, beliefs, attitudes, norms, habits)

Change

Culture

Introduction to ICAgile – Ahmed Sidkey Feb 2014

© Lamri Ltd 2014

For widespread DevOps adoptionIts not just Dev and Ops who need to change

Executive

Management

Finance

End Users

Project Sponsor

Line Management

The delivery

team

The ops

team

Who is touched by changing tools or process?

3rd party solution

component

© Lamri Ltd 2014

DevOps depends on people …How receptive are they?

Early

Adopters

Active

Resistors

Late

Adopters

REMEMBER - this spread applies to the team AND external stakeholders

© Lamri Ltd 2014

Add in delivery pressure and listening goes down!

Early

Adopters

Active

Resistors

Late

Adopters

1 Barriers to DevOps Adoption

38%

31%

16%

Lack of collaboration between silos

Cultural barriers to working together

Resistant to change

1 Serena

© Lamri Ltd 2014

Driving DevOps at scale meansKnowing the reason for change

Wh

at?

•“Two-minute elevator spiel” (Tom Peters) – keep to 30 secs

•The reason to instinctively support this project

•Normally based around a threat or opportunity

•Encapsulates the real reason for doing this

Go

od

exa

mp

les

•“Unless we start hitting our milestones, we will not exist”

•“Improve the margin by reducing wasteful rework”

•“We face a huge increase in business demand for change”

•“Prove we’re better than the outsource providers”

© Lamri Ltd 2014

Executive

Management

Finance

Higher initial spend;

early risk exposure

can challenge

perceptions

The delivery

team

Focus on deployed

software is more

satisfying …. Fun ….

O&M

Greater release frequency

can be threatening – but

greater collaboration

allows O&M needs to be

better understoodDevOps makes life a little

easier – focus on deployed

software provides a more

objective view of progress

Management

Selling to the wider set of stakeholdersWhats in it for me?

Who is touched by changing tools or process?

End Users

Frequent releases help

ensure key customer needs

are met

Project Sponsor

© Lamri Ltd 2014

Demonstrating strategic alignment attempting this helps discover whats important to key

stakeholders

•Increase profitable sales

•Operational cost reduction

•Perception of the brand, “squeaky clean” etc

Deliver IT projects reliably to enable the business

strategy to launch XXX services in XXX timeframe

Benefits

Deployed improved working practices, base on DevOps

principles

Desired

outcomes

High level

deliverable

• Lead time to change

•Deployment frequency

•Customer satisfaction

Measures

Agree the measures early and follow through

© Lamri Ltd 2014

Drive demand for DevOpsBringing key elements of practice to life drives and sustains DevOps

Current Situation Desired Situation

Senior

Management

Dev Teams

Development

Management

Pro

ce

ss

Ma

na

gem

ent

Senior

Management

Quality

Delivery Teams

(DEV & OPS)

Pro

ject

Ma

na

gem

ent

Feedback

Feedback

Govern

ways of

working

Support

using

process

Govern

Coach /

Review

Community that

drives demand for

process adoption

Govern

DevOps adoption critically depends on

individuals

DevOps adoption supported by and in

best interests of organization

Ops Teams

Ops

Management

Quality

Project

Management

© Lamri Ltd 2014

Drive demand for DevOpsIdentify practice leads

• Senior staff taken from the line

• Part / full time role

• How we “work here”

• Harvest improvements from project retrospectives

• Championing it across the organisation

• Ensure project staff suitably skilled

Pro

ce

ss

Ma

na

gem

ent

Senior

Management

Quality

Delivery Teams

(DEV & OPS)

Pro

ject

Ma

na

gem

ent

Feedback

Feedback

Govern

ways of

working

Support

using

process

Govern

Coach /

Review

Govern

© Lamri Ltd 2014

How does Practice Leads approach

work?

• Staff– Organisationally

managed by practice lead

– Funded by projects

– Embedded in project & ops teams

• Ensures– Maintain delivery focus

– Identify and share best-practice

– Stick to / Enhance the processes

– Enhanced visibility into project risk

Project 1

Project 2

Project 3

Project n

Practice Leads

© Lamri Ltd 2014

Adopt Service Thinking

Service 1

Service 2

Service 3

Service n

Helps address culture

“you build it you run it”

Common approach to delivery

Encourages cross-skilling, common ownership of code

Start to think in terms of annual team plan

Business & technical environments

Approach to doing work

Plan in skills improvement

Fill Timebox with Points

from the Prioritized Backlog

Points Based

Sizing

Monitor In Points;

Work is Countable

velocity and estimating errors

used to refine estimation basis

© Lamri Ltd 2014

Drive demand for DevOps“Quality” & “Management”

• Quality team– Independent of

projects

• Carrot and stick

– Ask: is the project/function working the way it intends?

– Provide coaching

– Harvest improvements

• Accountable for project success– Our approach is the least-risk way

of delivering

– Support / facilitate

– Remove obstacles

– Support team’s continued use of practices that work even in times of stress

– Process compliance is important

© Lamri Ltd 2014

Implementing

Adopting guerrilla tactics

Fun

ctio

n 2

Functio

n 1

Delivery

capability

Functio

n 3

Functio

n 4

Initiative 4

Initiative 3

Initiative 5

Initiative

6

Initiative2

Initiative1

• People want to improve the

organisation

• Many improvement initiatives

Overwhelmingly good stuff

• Find the needy and the willing

Who are they?

How can you hook them in?

• Form alliances

• Don’t take over the world

• Much can be delivered through

existing initiatives

• Ownership stays with the people

that know the work

DevOps

© Lamri Ltd 2014

If we want the benefits from DevOpsstrip out silos to make the organisation more Agile

• Adopting DevOps in a typically complex setting– Isn’t just going to happen

• Recognize it’s processes/tools/attitudes that require– Widespread adoption

– Sustainment over time to maintain their relevance

• It’s a change programme …– Needs selling

– Needs funding

– Needs delivering

– Needs sustaining

© Lamri Ltd 2014© Lamri Ltd 2014

Lamri Ltd

7 Mowbray House

Olympic Way

Richmond

North Yorkshire

DL10 4FB

graham.dick@lamri.comp +44 (0) 1748 821824

© Lamri Ltd 2014Conspires to make collaboration harder

Organisational Benefits …only realised when we have DevOps at scale

• Waves of mergers & acquisitions,

rationalisations, cost-cutting, investment etc etc

– Multiple Dev centres

– Multiple Ops centres

– Organised by line of business, by technology

LOB Dev 1IT Ops 1

LOB Dev 2

LOB Dev 3

IT Ops 2

• Personal networks – that used to ‘get stuff done’

– are stressed, or don’t exist at all

• Poorly aligned management, Misaligned toolsets,

training and backgrounds

© Lamri Ltd 2014

Scaling DevOps – multi project; location;

geographyneeds consistent answers to many questions

• What versions & platforms constitute this release?

• What does this version do?

• What steps do we need to take to go-live whilst maintaining service delivery?

• Who do we need to inform?

• How do we resolve incidents and prevent their re-occurrence

• How do we ensure our people have the skills needed to work in the new ways?

• When will we deliver; what might go wrong?

• How well are we performing?

Build &

unit testPlatform test

Deliver to staging

Acceptance test

Deploy to production

Post deploy tests

• Many of these questions are

answered with a mix of tool and

process

• Either work out your own

solutions for consistency and

completeness

• Or look to best practice models

(CMMI, ITIL etc)

© Lamri Ltd 2014

In Conclusion

Level 5 OptimisingDevOps

Track and use performance data to optimise processes and

automate manual steps

Level 4 Managed DevOps

Dev & Ops – use of metrics to understand and resolve problems. The relevant

developer called to fix problems.

Level 3 Fundamental DevOps

Process, automation & metrics shared across projects / services.

Hand-off issues reduced. Learning from experience

Level 2Projects /

services use automation -differrently

Little sharing of approach / tools so issues at handover. “React”

and firefight when problems occur

Level 1 No DevOps yet Fire-fighting, finger-pointing