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.

1. The Gordian knot
@ziobrando

2. Let’s start from here
• The Science of Lean Software and
DevOps.

3. What is Science Saying?

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

6. Just Hire some
DevOps, where’s the
problem?

7. What about MicroServices?

8. Microservices
• More frequently adopted between high
performers
• No significant differences according to
which type of architecture teams were
building or integrating against.

9. Microservices are not
enough!

10. I was the only
person in a
microservices conference
to do event-driven
customers are
asking me to help them
coordinate microservices
deployment

11. Microservices
are just like
SOA
We
screwed up
SOA, we’ll screw
up microservices
in the very same
way!!!

12. Scary

13. Technology Relevance
• Not as much as we’d like :-)
• The main differentiating factor is…
Loose coupling!!
Bounded Context
Bounded Context

14. Weren’t Microservices and
Loosely coupled supposed
to be the same thing?

15. Stop
splitting
around
data!

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

18. Westrum Classification
• Pathological (power-Oriented)
• Bureaucratic (Rules-Oriented)
• Generative (Performance-Oriented)

19. This is where things get
weird

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.

23. The bus ticket
A little journey into stereotypes

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.

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

29. Design choices define
interactions that shape
culture

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”

31. A winning behaviour?

32. 2 Thinking Tools

33. The Pink Check
Thinking Tool #1

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?

39. Bounded Contexts
As units of clear
responsibility

40. Purpose (Again)

41. A team with a
clear purpose is a
formidable
weapon

42. The Feedback Check
Thinking Tool #2

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

45. Delay is part of
the (good|bad)
feedback cycle

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

52. The sadness
machine scenario

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

54. I’d never work in a place
like that!

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

58. Negative Feedback and
Delay
Speed Matters

59. A Kafka-style punishment System
Well Done!
A Reward Deprivation System

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
!
!
!
!
!
!
!
!
!
!

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

66. Fear
That’s what you’re designing for!

67. This job will
allow you to experience
a continuous state of
fear, anger and guilt
Not to
mention
frustration
And despair
too!

68. Good Developers are OK in
paying for their own
mistakes
They hate paying for
somebody else’s ones

69. Safety
Responsibility
Pride

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?

71. SummarySummary

72. Buy a Copy of this
book!
Buy a copy for your boss too!!

73. SummaryEverything is
connected

74. Emotions
Matters

75. Your Architectural Choices
will shape Interaction and
Culture
Remember the bus?

76. Bounded Contexts
• Unit of
language
consistency
• Unit of purpose
• Unit of
responsibility
• Unit of pride

77. Safety Matters

78. Horizon Alignment
LOng Term Goals
Long Term engagement

79. Find your purpose
And amazing things will happen

81. References
• www.eventstorming.com
• LeanPub books:
• http://leanpub.com/introducing_eventstorming (still growing)
• https://leanpub.com/ddd_first_15_years
• Blog:
• https://medium.com/@ziobrando
• http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation: info@avanscoperta.it
• http://www.avanscoperta.it