In early 2018 Nassim Nicholas Taleb, one of the foremost thinkers of our time, published a new book: Skin in the game. About hidden asymmetries in daily life. Jan de Vries translates this book towards DevOps, as he did before with Taleb’s book Antifragile. It explains why some concepts work and others don’t. It’s like turning on the light in your DevOps environment. And it helps you to improve your (IT) organisation in the right direction. This talk contains practical tips and tricks that can be applied instantly.

1. September 27, 12.00 - 12.30
Enterprise DevOps
working group
Jan de Vries
working groups
agile scaling,
agile leadership
& por4olio
management

2. Realising the power of Antifragility is like
turning on the light in the DevOps room
explaining why
concepts work or don't work
Code of Hammurabi
Mesopotamia, 1754 BC
DevOpsdays
Riga, 2018
Evolution of moral symmetry

3. Code of Hammurabi
• Best known one is code #229: "if a builder builds a house
and the house collapses and causes the death of the owner
of the house - the builder shall be put to death."
• Golden Rule: Treat
others the way you
would like them to
treat you
• Silver Rule (Negative
Golden Rule): Do not
treat others the way
you would not like
them to treat you.
Code of
Hammurabi
Rules in many
religions
and cultures
• Skin in the Game: the
situation in which
high-ranking insiders
use their own money
to buy stock in the
company they are
running
Warren Buffet
Evolution of moral symmetry

4. Nassim Nicholas Taleb
“If you give an opinion, and someone follows it, you are morally obligated to be,
yourself, exposed to its consequences.”
If you have no skin in the game, you shouldn’t be in the game.
These books explain why
concepts work or don't work
2012 2018

5. • “If you develop software, and someone else will operate
the software, you are morally obligated to be, yourself,
exposed to its consequences.”
• Or even better: as a team operate your own software
• People in a one silo don't have skin in the game of
another silo
DevOpsSilo's
Translated to software
The silo era is ending,
let's expedite

6. Conway's Law (1968)
Definition:
• organizations which design
systems ... are constrained to
produce designs which are copies
of the communication structures
of these organization
Siloed organisations build siloed systems
Continuous Deployment
Definition of Done
• built
• tested
• deployed on pre-production
• UAT performed
• deployed to production
• feature toggled on
• accessible for the customer
• used by the customer
• first feedback from the customer
Continuous
Deployment
Agile only
Agile only
Definition of Done
• built
• tested
You will never fully convince someone
that he is wrong; only reality can

7. You will never fully convince someone
that he is wrong; only reality can
Agile only
Agile only
Definition of Done
• built
• tested
Waterfall
Waterfall
Definition of Done
• realising that you traveled in
the wrong direction for 2
years....
Contin
De
• built
• tested
• deployed
• UAT perfo
• deployed
• feature to
• accessibl
• used by th
• first feedb
You will never fully convince someone
that he is wrong; only reality can
Continuous Deployment
Definition of Done
• built
• tested
• deployed on pre-production
• UAT performed
• deployed to production
• feature toggled on
• accessible for the customer
• used by the customer
• first feedback from the customer
Continuous
Deployment
(fr)Agile only
Agile only
Definition of Done
• built
• tested

8. Variable
Gain
Pain
The concept of antifragility
Variable
Gain
Pain

9. Variable
Gain
Pain
• Definition: anything that has more
upside than downside from random
events / shocks is antifragile; the rest
is fragile
• to judge the (anti)-fragility of a system
is to ask whether it is accelerating
towards harm or benefit
Nonlinearity

10. Variable
Gain
Pain
Variable
Gain
Pain

11. Variable
Gain
Pain
Variable
Gain
Pain
Concave Convex

12. Variable
Gain
Pain Concave Convex
Frown or smile

13. Number of
deployments
per month
Gain
Pain
CONTINUOUS
DEPLOYMENT
IS ANTIFRAGILE
The Third Way
Technical and
Organisational Debt
Technical & Organisational Debt
make you fragile

14. Technical and
Organisational Debt
Organisational Debt
• organisational model
does not fit
operational model
• silo's
• hand-offs between
teams
• politics, fear and ego
Technical Debt
• is what you feel the
next time you want
to make a change
(Gene Kim)
• invested more in
MTBF than in MTTR
Tinkering in IT
The third way, continual experimentation and learning

15. Time
Change
in
value
Antifragile tinkering
The Unicorn Club

16. Time
Change
in
value
Fragile tinkering
Time
Change
in
value
Decreasing Technical Debt and
Organisational Debt

17. Technical
debt
backlog
Improveme
nt
backlog
Tasks
The 4 colour backlog
Product
backlog
Defect
backlog
Technical
Debt
backlog
Improvement
Backlog
Source: Brian Teunissen, Inspearit
www.linkedin.com/pulse/measuring-velocity-producing-milk-shoveling-dirt-brian-teunissen
Source: Brian Teunissen, Inspearit
If you ask your customer
www.linkedin.com/pulse/measuring-velocity-producing-milk-shoveling-dirt-brian-teunissen

18. For your customer's own
good
www.linkedin.com/pulse/measuring-velocity-producing-milk-shoveling-dirt-brian-teunissen
Bite the bullet
www.linkedin.com/pulse/measuring-velocity-producing-milk-shoveling-dirt-brian-teunissen

19. The Chaos MonkeyRisk Management
The Chaos MonkeyRisk THEATRE

20. ▪ Latency monkey
▪ Janitor monkey
▪ Conformity monkey
▪ Chaos gorilla
Antifragile in IT

21. DevOps teamsSoftware projects
!42
Allan Kelly
Building a tunnel or a bridge with a temporary team
Building software with a temporary team
#no projects

22. • The most destructive idea known to
software development: temporary
organisations
• Disbanding teams destroys
- Knowledge
- Capability
- Performance
Source: Allan Kelly
PROJECTS
ARE FRAGILIZERS
Skin in the game is missing
in projects
Source: Nijland and Berghout, 2002
Skin in the OPS game is missing

23. Number of tasks
coordinated
in a project
Gain
Pain
SOFTWAREPROJECTSARE FRAGILE
Turning followers
in to leaders
Top down
management
Top down management is missing skin in the game:
• It is easier to macrobullshit than to microbullshit
• bureaucracy is a construction by which a person is
conveniently separated from the consequences of
his or her actions

24. Command and control
is not fast enough
• Push authority to the
information level in stead of
pushing information to the
authority level
• Make sure that people who
are closest to the
information
• are technically competent
• have organisational clarity
• understand priorities

25. Decentralise decision-
making
• Centralise strategic decisions: Infrequent, Long-lasting and
Provide significant economies of scale
• Decentralize Everything Else: frequent, time-critical, require
local information
Source: Scaled Agile
Source: Sogeti
Gain
Time
Pain

26. Fragile
Fragile

27. Fragile
Robust

28. Robust in IT
Resilient

29. Resilient
Antifragile

30. How to become less
fragile, even
antifragile in IT?
From fragile to antifragile software
–continuous deployment
–chaos engineering
–canary releases
–A/B testing
–auto scaling
Source: Bilgin Ibryam
https://developers.redhat.com/blog/2016/07/20/from-fragile-to-antifragile-software/

31. Is antifragility a choice or a must?
• Speed - Time to market
• Manoeuvrability - continuously linking
business opportunities and threats with
technical developments
Speed....
• Jeff Bezos, in his April 2017 letter to Amazon
shareholders, highlights making not just “high-quality”
decisions but “high-velocity” decisions. They go hand
in hand. “Most decisions,” writes Bezos, “should
probably be made with somewhere around 70 percent
of the information you wish you had. If you wait for 90
percent, in most cases you’re probably being slow.”
Choosing not to fail fast comes at a price. “If you’re
good at course correcting,” Bezos continues, “being
wrong may be less costly than you think, whereas
being slow is going to be expensive for sure.”

32. G-LOC (G-Force induced Loss Of Consciousness)

33. Thank you