This document discusses key concepts for building high-performing systems, including DevOps, microservices, and organizational culture. It emphasizes that technology choices influence culture and that culture is a key factor in performance. Bounded contexts, loosely coupled systems, and alignment of goals across teams and over the long term help promote autonomy, mastery, and a clear sense of purpose. Feedback loops and organizational structures should support seeing the impact of work, learning from mistakes, and continually improving.
4. DevOps works!
“The findings from our research program shows clearly that the value of
adopting DevOps is even larger than we had initially thought, and the
gap between high and low performers continues to grow”
5. DevOps key traits
• Frequent code deployments
• Fast lead time from commit to deploy
• Fast recovery from downtime
• Lower Change failure rate
• Up to 46 times more
frequently
• Up to 400 times
faster lead time
• Up to 170 faster
mean time
• 5 times lower
change failure rate
8. Microservices
• More frequently adopted between high
performers
• No significant differences according to
which type of architecture teams were
building or integrating against.
16. Entities to microservices
As ugly as the code can be, the IDE works fine inside
the monolith
The moment you migrate, refactoring becomes an
order of magnitude more expensive…
…and you’ll never perform it anyway, because budget
will over by then.
17. Culture as a Key factor
You can’t just “go DevOps” in a vacuum
20. Culture
CULTURE is a GIVEN, there’s nothing we can do about
it
CULTURE or “MENTALITY” as an ALIBI.
CULTURE as ORTHOGONAL and INDEPENDENT from
other concerns.
21. What is Culture?
I don’t need a precise definition, I just need an actionable one
22. Culture is the cumulative
effect of a winning behaviour
within a given context
Winning Examples plus Imitation is a formidable combo.
25. Taking a bus: Scenario A
Tickets can be purchased in shops and vending
machines
Multiple entry points on the bus (to speed up
boarding operations)
Easy to jump on without ticket
CHEATING is for low-risk gamblers.
26.
27.
28. A Different Scenario:
Payment on the bus enforces a single entry point.
If I don’t pay, everybody is looking at me.
CHEATING is for losers
30. Trying to introduce good practices
“I am the only one in my team doing TDD”
“My tests are frequently broken because I am the only
one running them”
34. Yes! I mean This Pink!
Autonomy
Mastery
Purpose
https://vimeo.com/15488784
35. Scenario: The Builders team
Great Team.
Great product, growing on the market.
Positive feedback loops. (more on this later)
36. The Pink Check
Autonomy?
It’s Us, We Built it, We know every corner of it. Plus
…it’s tested.
Mastery?
Damn Yeah! We made mistakes, but we keep improving
the codebase. We are in control.
Purpose
Keep on Rocking!
37. Scenario: The caged team
Great Team (same team as before).
New product: “let’s use this platform to speed up
time!”
6 months later…
3rd Party Platform
! ConformistOur Core
38. The Pink Check
Autonomy?
Not Any More: the platform is constraining their
options.
Mastery?
Not Any More: platform is suggesting to do “dirty
things”
Purpose?
… pay the bills?
43. Exploring your feedback loops
Which are the feedback channels?
How can we know we’re doing a good job?
Who are we making happy?
Are we learning the right things?
How does (good|bad) feedback arrive?
How Long should I wait for (good|bad) Feedback?
44. Feedback Check: DevOps
Feedback from Users & Metrics, Right After we
release.
Mistakes are removed quickly (lower cognitive load,
accelerated learning)
Learning can sparkle new ideas in quick cycle.
(Feedback has business-specific delays.)
46. People won’t improve a system
if they won’t stay around long
enough to see the benefits
Have you ever repainted a hotel room?
47. Time vs Time
Time to enjoy the benefits of a given action
My life expectancy in a system
Annoyingly, short term goals tend to beat long term ones…
48. DevOps works!
“The findings from our research program shows clearly that the value of
adopting DevOps is even larger than we had initially thought, and the
gap between high and low performers continues to grow”
Yep, same slide from the beginning. It’s intentional
49. If the loop is too long,
systems won’t improve
AT ALL
Long release cycles are slowly killing your organization
50. Homework
Run the Feedback Check on the following topics
Refactoring
Test-Driven Development
Architecture Migration
Getting a training
And on the different Roles in your organisation…
51. Whenever my team ask
anything I try to fulfil
their requests
It’s so
exhausting to achieve
anything with our boss that
we only ask stuff that he
can’t possibly refuse
53. Sadness Machine Scenario
Product teams working on new features
National teams Working on Local Version
Site Teams working on customisation
Lead Time?
9 months
6 months
6 months
55. Pink Check
Autonomy?
No: can’t deliver value independently.
Mastery?
Does it matter? They won’t catch me anyway.
Purpose?
Actively prevented from having one.
56. Positive Feedback :-)
15 month on average before releasing a feature in
production.
No direct contact with the end user
Working on specifications
Releasing to a middleman (positive feedback cannot be
really trusted)
57. Negative Feedback :-(
Bad feedback can happen at any time… after release
No or little control on the reason
Always disconnected
60. Real case Scenario #2
Microservices architecture
New Service dependent on 12 external services.
Synchronously
External services completely unreliable
SLA requested
61. Pink Check
Autonomy?
No: at the mercy of a dozen of enemies
Mastery?
Will it matter? They’re asking to build on sand…
(offensive BTW)
Purpose?
Survival
62. !
Our Service
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
3rd Party Service
Conformist
!
!
!
!
!
!
!
!
!
!
63.
64. Positive Feedback :-)
Really low probability of working things.
No direct contact with the end user
Working on specifications
Releasing to a middleman (again!)
65. Negative Feedback :-(
Bad feedback can happen at any time… for a dozen of
reasons. after release
No or little control on the reason
Always disconnected
70. Loosely coupled -> AUTONOMY
How many meetings to we need to AGREE on
something?
How is this affecting purpose?
How many externals are we depending upon?
How is this affecting autonomy?
How many trade-offs?
How is this affecting mastery?