jan de vries - how to convince your boss that it is devops that he wants

How to convince your boss that it is DevOps that she wants

• 11.00 – 11.45 The great transformation7 surprising experiences -> 7 best practices

• 12.00 – 12.45 Appreciative InquiryBuild – or even rebuild – organizations aroundwhat works, rather than trying to fix what doesn’t.

2 parts

1

Happy to talk in front of an agile audience!

The great transformation7 surprising experiences -> 7 best practices

Intro Jan de Vries

3

• Fan of Agile• DevOps evangelist• Business IT Consultant at insurance company a.s.r.• Convenor Enterprise DevOps group (uniting members of

ASL BiSL Foundation, ITSMF and Agile Consortium)• Member Scaling Agile group at Agile Consortium• Trainer BiSL, ASL, ITIL, FSM, ISM• Blue Ocean Defined Demand expert• Chairman Clarity User Society

Huh? Part 1

c

How iterative is your software process?

c

How often do you release to your customer?

The result and the consequences

Tijd

Tester: discovers defects thata developer introduced 3 months ago

Developer: what did I build 3 months ago?

Designer: what did I design 6 months ago

User: what did I ask for long time ago?

Manual activities:• Preparation and tuning of

scenarios• Acceptance tests• deployments• conversions

Why not release more often?

600Why not automate?

No business case

Because we don’t do it

often enough

So we keep the frequency low:• Saves time for Dev and Ops• Increases stability

Huh? Part 2

Project based organisation

Product based organisation

• A multidisciplinary team that is fully responsible forcontinuously developing and maintaining a service

Business Service chain

Pla

tform

#1

Pla

tform

#2

Pla

tform

#3

Pla

tform

#n

Infra

stru

ctur

e

DevOps, the team basics

• Development AND Operations in 1 team per businessline (or part of it)

• Development, Business Information Management (BiSL), Application Management (ASL) and IT InfrastructureManagement (ITIL) in 1 team per businessline (or part of it)

• You build it, you run it. Eat your own dogfood• DevOps finishes what Agile started, because every PSI goes

to production.• Extra flavours: BusDevOps and Enterprise DevOps

14

DevOps teams in stead of projects

Because of the direct relationship with the customer there is less need to start projects. A very large part of the requirements is being realised throughchanges.

In stead of staffing projects

Bring the work to the scrum team•No resource shuffling•Reliable velocity•Clear Cost of Ownership per business line

Headline from the future

2017

SCRUM finally breaks through

Number of newly launchedprojects decreased with 80 % in the last 2 years.

Blow up silo’s, to create DevOps teams

17

Strategic Alignment Model Enhanced

S

T

O

B I T

S

T

O

B I T

DevOps

S

T

O

B I T

BusDevOps

S

T

O

B I T

Enterprise DevOps

S

T

O

B I T

CIO influence....

S

T

O

B I T

... applied in the board

?

S

T

O

B I T

Huh? Part 3

Integration of management track and technical trackBased on a whitepaper of XebiaLabs

?

Huh? Part 4

What is more important?Mean Time Between Failure as long as possible?Mean Time To Repair as short as possible?

29

• Failure is not acceptable…. But it will happen!• MTTR is more important than MTBF (John Allspaw)• Time spent on facilitating an efficient and effective response to

failure >= time spent at preventing that failure.• Focus on MTBF: only for space hardware and embedded

medical devices• Focus on MTTR: everything else

What is more important? MTTR or MTBF?

Huh? Part 5

No time for technical debt and improvements

http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/

Source: Brian Teunissen, Inspearit

4 input sources for the backlog

Technical debt

backlog

Improvement

backlog

Tasks

With time for technical debt and process improvement

http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/

Bite the bullet

http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/

Huh? Part 6

Provisioning in the last decade

• Software is eating the world -> Infrastructure as code• We can generate DTAP-environments on demand. Treat them like that

3 weeks 100 milliseconden3 minuten

Huh? Part 7

Fully automated to productionWho is against that?

39

So, I don’t dare to mention

• The Chaos Monkey (resilience testing -> anti fragility)

• Continuous Delivery as code (the pipeline sits in a file)

• The dismissal of testing (-> scripting)

40

The great transformationWhat got us started with DevOps

Straight Through Processing %

%

In the old days Nowadays

Formula 1 in IT -> DevOps

44

Source: Car and Driver, K.C. Colwell / Bryan Christie Design

45

Car and Driver, K.C. Colwell / Bryan Christie Design

Anatomy of an F1 Pit Stop:0:03 Is the Magic Number

Acceleration is not easy in the 21st century

• The most important contribution of management in the 20th century was the fifty-fold increase in the productivity of the manual worker in manufacturing

• The most important contribution management needs to make in the 21st century is similarly to increase the productivity of the knowledge work and knownledge workers.

Peter Drucker, 2000

Acceleration is not easy in the 21st century

Cuckoo effect

“Any foreign innovation in a corporation will stimulate the corporate immune system to create antibodies that destroy it.”

Peter Drucker

8 key differences between DevOps en Traditional IT

48Source: Mustafa Kapadia, IBM

DN

DG

S

JO

M

I

C

R

WW M

R I

C O

D

DG

S

N J R

DO

SDG

C

N MJ

WI

R J

C

DG

I

M SN O

W D

O C

S

N

I

WRJ

M

DG

D

S W

J

R

M

IN

CDG

O

D

DevOps maturity 01-01-2014

DevOps Building Testing Deploying Provisioning Reporting

J = ok J = in progress J = no change

DN

DG

S

JO

M

I

C

R

WW M

R I

C O

D

DG

SN

J

R

DO

SDG

C

N M

J

WI

R

J

C

DG

I

M SN

O

W D

O C

S

N

I

WRJ

M

DG

D

S W

J

R

M

IN

C

DG

O

D

DevOps maturity 01-06-2014

DevOps Building Testing Deploying Provisioning Reporting

J = ok J = in progress J = no change

DN

DG

S

JO

MI

C

R

W

W MR I

C O

D

DG

SN

J

R

D

O

SDG

C

N M

J

WI

R

J

C

DG

I

M SN

O

W D CS

N

I

WRJ

M

DG

D

S W

JR

M

IN

C

DG

O

D

DevOps maturity 01-10-2014

DevOps Building Testing Deploying Provisioning Reporting

O

CO

CO

CO

CO

CO

CO

V

V

V

V

V

V

J = ok J = in progress J = no change

Role of IT in an organization

Support the business

Adde

dva

lue

toth

e bu

sine

ss

Impact on organization

Improve the business

Innovate the business

53

55

The great transformationHow to convince your boss of DevOps?

Abstract

• We all know that we could implement DevOps a lot faster if we only would have commitment from our boss. We all know that there is a shiny business case for almost every DevOps implementation

• And we all know that the whole company will reap the benefits regarding speed, agility and stability once we implemented DevOps. Actually, it provides good, fast and cheap at the same time. So, what are we waiting for? What is your boss waiting for? What is C-level waiting for?

• That’s something we will do research on in this workshop. We will also share our research on this from the recent past. The method we use is Appreciative Inquiry. To tackle a problem, it discovers the best practices that work, the reason they work and how these combined practices can be used to avoid the problem ahead and create a strategic change. The aim is to build – or even rebuild – organizations around what works, rather than trying to fix what doesn’t.

• So we want to know what your boss is afraid of and what you have already tried to convince him that he is better of with DevOps. You will leave the workshop with the combined Appreciative Inquiry insights of all the attendees. 57

But first: what is the core problem?

Why is not everyorganization, not everybodyin an organization workingagile / doing DevOps?

Tackling this problem

c c

4 D’s

• DISCOVER: The identification of organizational processes that work well.

• DREAM: The envisioning of processes that would work well in the future.

• DESIGN: Planning and prioritizing processes that would work well.

• DEPLOY: The implementation (execution) of the proposed design

61

DISCOVER: The identification of organizational processes that work well

For the speaker:• Which ‘Peak experiences’ did you encounter in your work, in

specific projects, specific incidents? • What do you value most in yourself, your work, your

organization?• Which factors keep your organization alive?

For the listeners:• Focus on the story• Avoid discussions

62

• What are the keyelements that you hear in the peak experience

DREAM: The envisioning of processes that would work well in the future

• Which themes can be derived from these stories?• How does the future, based on these themes look like?

63

DESIGN: Planning and prioritizing processes that would work well.

• How can we turn this exceptional dream phase intoour everyday experience?

• This expectional dream once existed. It may againbe reality

• Which scenario’s can we follow to get there?• Which activities do we need to plan?

64

DEPLOY: The implementation (execution) of the proposed design

• Activities to deploy the dream state in yourorganization

65