The document elaborates on the implementation of DevOps, emphasizing its role in enhancing organizational efficiency and responsiveness. It discusses strategies for convincing management on the benefits of DevOps, detailing the Appreciative Inquiry method as a means to identify and build on effective practices. The text also touches on various aspects of DevOps maturity, team structure, and the integration of development and operations for improved service delivery.

1. How to convince your boss that it is DevOps that she wants
• 11.00 – 11.45 The great transformation
7 surprising experiences -> 7 best practices
• 12.00 – 12.45 Appreciative Inquiry
Build – or even rebuild – organizations around
what works, rather than trying to fix what doesn’t.
2 parts
1
Happy to talk in front of an agile audience!

2. The great transformation
7 surprising experiences -> 7 best practices

3. 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

4. Huh? Part 1

6. c
How iterative is your software process?

7. c
How often do you release to your customer?

8. The result and the consequences
Tijd
Tester:discovers defectsthat
a developerintroduced 3
months ago
Developer:what did I build 3
months ago?
Designer:whatdid I design 6
months ago
User: what did I ask for long
time ago?

9. Manual activities:
• Preparation and tuning of
scenarios
• Acceptance tests
• deployments
• conversions
Why not release more often?
600
Why 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

10. Huh? Part 2

11. Project based organisation

12. Product based organisation

13. • A multidisciplinary team that is fully responsible for
continuously developing and maintaining a service
Business Servicechain
Platform#1
Platform#2
Platform#3
Platform#n
Infrastructure

14. 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 Infrastructure
Management (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

15. 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 through
changes.
In stead of staffing projects
Bring the work to the scrum team
• No resource shuffling
• Reliable velocity
• Clear Cost of Ownership per business line

16. Headline from the future
2017
SCRUM finally breaks
through
Numberof newly launched
projects decreased with 80
% in the last 2 years.

17. Blow up silo’s, to create DevOps teams
17

18. Strategic Alignment Model Enhanced

19. S
T
O
B I T

20. S
T
O
B I T
DevOps

21. S
T
O
B I T
BusDevOps

22. S
T
O
B I T
Enterprise DevOps

23. S
T
O
B I T
CIO influence....

24. S
T
O
B I T
... applied in the board

25. ?
S
T
O
B I T

26. Huh? Part 3

27. Integration of management track and technical track
Based on a whitepaper of XebiaLabs
?

28. Huh? Part 4

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

30. • 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?

31. Huh? Part 5

32. No time for technical debt and improvements
http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/
Source:Brian Teunissen,Inspearit

33. 4 input sources for the backlog
Technical
debt
backlog
Improvement
backlog
Tasks

34. With time for technical debt and process improvement
http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/

35. Bite the bullet
http://www.cibit.nl/nl/nieuws/blogs/melk-produceren-of-poepscheppen/

36. Huh? Part 6

37. Provisioning in the last decade
• Software is eating the world -> Infrastructure as code
• We can generate DTAP-environments on demand.Treatthem like that
3 weeks 100 milliseconden3 minuten

38. Huh? Part 7

39. Fully automated to production
Who is againstthat?
39

40. 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

41. The great transformation
What got us started with DevOps

42. Straight Through Processing %
%

43. In the old days Nowadays

44. Formula 1 in IT -> DevOps
44
Source:Car and Driver, K.C. Colwell/ Bryan Christie Design

45. 45
Car and Driver, K.C. Colwell / Bryan Christie Design
Anatomy of an F1 Pit Stop:
0:03 Is the Magic Number

46. 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

47. 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

48. 8 key differences between DevOps en
Traditional IT
48
Source:Mustafa Kapadia,IBM

49. DN
D
G
S
J
O
M
I
C
R
W
W
M
R
I
C O
D
D
G
S
N J R
D
O
S
D
G
C
N M
J
W
I
R J
C
D
G
I
M S
N O
W D
O C
S
N
I
WRJ
M
D
G
D
S W
J
R
M
I
N
C
D
G
O
D
DevOps maturity 01-01-2014
DevOps Building Testing Deploying Provisioning Reporting
J = ok J = in progress J = no change

50. DN
D
G
S
J
O
M
I
C
R
W
W M
R I
C O
D
D
G
SN
J
R
D
O
S
D
G
C
N M
J
W
I
R
J
C
D
G
I
M S
N
O
W D
O C
S
N
I
WRJ
M
D
G
D
S W
J
R
M
I
N
C
D
G
O
D
DevOps maturity 01-06-2014
DevOps Building Testing Deploying Provisioning Reporting
J = ok J = in progress J = no change

51. DN
D
G
S
J
O
M
I
C
R
W
W M
R I
C O
D
D
G
SN
J
R
D
O
S
D
G
C
N M
J
W
I
R
J
C
D
G
I
M S
N
O
W D
CS
N
I
WRJ
M
D
G
D
S W
J
R
M
I
N
C
D
G
O
D
DevOps maturity 01-10-2014
DevOps Building Testing Deploying Provisioning Reporting
O
C
O
C
O
C
O
C
O
C
O
C
O
V
V
V
V
V
V
J = ok J = in progress J = no change

52. Role of IT in an organization
Support the
business
Addedvaluetothebusiness
Impact on organization
Improve the
business
Innovate the
business

53. 53

55. 55

56. The great transformation
How to convince your boss of DevOps?

57. Abstract
• We all know that we could implementDevOps a lot faster if we only
would have commitmentfrom our boss.We all know that there is a shiny
businesscase for almostevery DevOpsimplementation
• And we all know that the whole company will reap the benefits regarding
speed,agility and stability once we implementedDevOps.Actually,it
provides good,fast and cheap at the same time. So, what are we waiting
for? What is yourboss waiting for? What is C-levelwaiting for?
• That’s something we will do research on in this workshop.We will also share
our research on this from the recentpast. The method we use is
Appreciative Inquiry.To tackle a problem,it discoversthe best practices
that work, the reason they work and how these combined practicescan
be used to avoid the problem ahead and create a strategic change.The
aim is to build – or even rebuild – organizationsaround whatworks,
rather than trying to fix what doesn’t.
• So we want to know what yourboss 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 AppreciativeInquiry insights of all the
attendees. 57

58. But first: what is the core problem?
Why is not every
organization, not everybody
in an organization working
agile / doing DevOps?

59. Tackling this problem

60. c c

61. 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

62. 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 key
elements that you hear in
the peak experience

63. 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

64. DESIGN: Planning and prioritizing
processes that would work well.
• How can we turn this exceptional dream phase into
our everyday experience?
• This expectional dream once existed. It may again
be reality
• Which scenario’s can we follow to get there?
• Which activities do we need to plan?
64

65. DEPLOY: The implementation (execution) of the
proposed design
• Activities to deploy the dream state in your
organization
65