Can we write successful enterprise software without challenging assumptions? Agile doesn't happen in a vacuum. Here's what I discovered using EventStorming as a blade to cut through business, software and organisation dysfunctions. From XP2017 Cologne.

1. The alignment
@ziobrando

2. About me
Very hard to explain my job to my mother
running www.avanscoperta.it
Modelling (almost) everything with sticky notes,
markers and a paper roll.
Calling this stuff

3. In the last years
• seen many more companies and ecosystems
• Went quickly to the core problems
• Started to see patterns
• #SelectionBias

4. Big Picture Workshop
Invite the right people -> Business, IT, UX
Provide unlimited modelling space
Surface, Markers, stickies
Model a whole business line with Domain Events

5. Establish a timeline
Some facilitator tricks will kickstart
the discussion quickly

6. Explore with domain Events

7. The underlying knowledge

8. Enforcing the timeline
Experts will usually post a locally
ordered sequence of events
But enforcing a shared timeline then
triggers long awaited conversations

9. Outcome (big Picture):
The whole process is visible
Massive learning (crossing silo boundaries)
consensus around the core problem

10. Outcome (big Picture):
Multiple storytellings
Incremental Notation #NoUML #NoBPMN
A language for different tribes #Lean #UX #Agile #SW

11. More specifically…
No scope limitation (paper roll)
Exploration of boundaries (External Systems &
People)
-> The BOTTLENECK is in the picture.
-> The CORE DOMAIN is in the picture

12. Awesome!
… now what?

13. 1. The shape of the problem

14. I might start here

15. But it starts from here

16. #BlameTheSilos

17. Silos must have a reason
Silos minimise the amount of learning
needed to be “productive”
unfortunately, the emerging
structure of silos is hardly
reversible
Even small organisations will tend to
become silos if not managed
otherwise
… if only we could
make learning
cheaper… ;-)

18. Asymmetry

19. And this is what you get

20. But fragmented knowledge
is only one ingredient

21. Let’s look at the outcome
There are recurring patterns in blockers
A clear business narrative
A massive
blocker

23. Recurring anti-pattern

24. “That’s our key class”
Big class with overloaded responsibility in the disputed land
between 2 (or more) Bounded Contexts

25. Nouns won’t helpEverybody agrees
what an order is?
Of course we do!
An order is an
order!
And has a
customer
too! Agreed!

26. Perfect recipe:
Talk with many people
Model Data-First (everybody agrees on
nouns)
Add some “Dogmatic DRY principle”
Repeat

27. The Big Ball of Mud
I swear it was a
monolith last time I
checked!!!

28. One solution
A Draft Model with
loose integrity
constraints
Constraints
implemented as
warnings
A Validation barrier (constraints
implemented as blockers)
An Execution Model,
with similar data
structure, but
different behaviour

29. Data-first modelling is
flawed
And we knew it from Long Ago… #DDDesign

30. Everything is a code smell
here!

31. follow the money
• Bad code is everywhere!
• Implementation flaws with the
highest negative impact on the
enterprise are mostly related to
missing or wrong bounded contexts

32. Wait! Monoliths and BBoM
aren’t necessarily the
same thing!

33. Monoliths mechanics
It takes little to worsen the code
It takes a lot of effort to improve it

35. LEGO Entropy laws
Mixing LEGO boxes takes seconds
separating LEGO boxes takes ages

36. Database Entropy laws
Make a copy of an important table and give it a
nontrivial name
Measure how much time is needed to remove it
#INeedToBeSure…

37. Asymmetry

38. People will try to improve
systems only if they’re
going to be around long
enough to see the benefits
Will you clean your hotel’s garden?

39. Asymmetry

40. We can’t hire good
developers
A portion of our
codebase is so bad that devs quit
the company whenever we ask them
to touch it

42. Most companies don’t
understand technical debt
until it’s too late
They might, but waiting their “permission” is a losing strategy

43. Refactoring stories won’t help you
• Product Owners will prioritise about what they know.
• Total transparency, but YOU are the expert.

44. …Hidden agendas, unclear
benefits, many other
reasons…

45. Asymmetry
Features bring revenues, refactoring reduce risk

46. If we could start from
scratch…

47. Conceptual boundaries

48. Implementation boundaries

49. 2. The Impediment

51. Some companies attacked
the problem
Some didn’t
You don’t mess with the Bottleneck #ToCot

52. A clear business narrative
A massive
blocker

53. The author of the original
software was still around

54. The dungeon master
• Authors of the original code
• Only ones knowing some areas
• Can’t be beaten on their own playground
https://medium.com/@ziobrando/the-rise-and-fall-of-the-dungeon-master-c2d511eed12f#.1koij6bk1

55. And then I
discovered…
Bias: I only recommend books that prove me right.

56. “indefinite
procrastination”
We finally opened up
that portion of the
code!!
WOW! It was
smelling bad in 2011!!
It was buggy as hell…
:-/

58. Guilt?

60. protection?

63. We have a few problems
here

64. In a talent-driven job
market, nobody cares
about your monolith

65. Thin red line
• Start a project with a data first approach
• Lack of control requires protection & specialisation
• few people become key, others retire or get minionized
Business grows on top of old code
• More responsibilities: less time to change it, harder to
make the call
• Hard to recruit seniors to finish the job

66. Thin red line
• Postpone evolutions of critical software
• prevent the organisation from getting new feedback
• -> how long are your iterations?
• Suddenly realise that the organisation is dumbed down
and blames IT for everything

67. They’re the same problem

68. We don’t have dungeon
masters: everything is developed by
contractors

70. People will try to improve
systems only if they’re
going to be around long
enough to see the benefits
Will you clean your hotel’s garden?

71. Accelerated Growth
• A few developers build up the foundations
• Success brings money -> Hiring frenzy #Scale #recruiting
• Hiring is too slow -> Outsourcing
• External code is now maintained internally.
• Builders -> controllers -> caretakers -> cleaners

73. 3. The business

74. Not a single business
vision wasn’t flawed
There is value in “discussing business”
…and “Don’t worry about it” isn’t the best answer

75. Transparency helps

76. People won’t self organise
around a system they don’t
understand

77. My personal experience
EventStorming +
Radical Transparency
A “culture” of rewarding exploration
a clear mission

78. Transparency is hard

80. Competing goals anyone?

82. “agile doesn’t work here”

83. The purpose of our
organisation is to make
money
so…

85. “agile doesn’t work here”

86. One more time: Agile
doesn’t happen in a vacuum

87. Purpose matters
Yep it’s Pink on Purpose

88. Good news: The Rise of
Good Companies

89. Conclusions
Sometimes you have to wrap-up

90. The curse of enterprise monolith
natural tendency
natural tendency

91. “It will pass”
is not a strategy

92. Monolith and dungeon
master are often the same
problem

93. The monolith is the
dungeon

94. Stop pretending that it’s
cheap

95. Events are way better to prevent it

96. can’t solve one ignoring
the other
#feelings & #Code

97. But the coding ecosystem
is OUR responsibility
Can’t delegate it to pixies

98. A clear business narrative
A platform for self-
organisation

99. Transparency & purpose
will make magic happen

100. Questions?
Every question is
welcome, except
“When will you finish
the book?”

101. Questions?
Thank you!

102. References

103. References
• www.eventstorming.com
• EventStormers on Google+
• https://plus.google.com/u/0/communities/113258571348605620818
• LeanPub book in progress:
• http://leanpub.com/introducing_eventstorming
• Blog:
• https://medium.com/@ziobrando
• http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation:
• http://www.avanscoperta.it