The document discusses lessons learned from transitioning collaborative modelling practices like EventStorming to remote formats. It describes how the author initially stopped all in-person workshops and trainings due to COVID-19. Through experimentation with online tools over 18 months, the author discovered both challenges and opportunities of the remote format. Some key lessons included the outsized impact of digital divides, the importance of asynchronous contributions alongside synchronous sessions, and the ability to leave modelling sessions permanently visible and accessible online. The author outlines various formats and how they may be used remotely or in hybrid formats going forward.

1. Redesigning Everything
Lessons Learned in Remote Collaborative Modelling
Photo by Andreas Chu on Unsplash
@ziobrando
avanscoperta

2. 2013

3. • Started Writing the book
• It seemed the obvious thing to
do.
2015

4. “Put all the Key
people in the
same room”

5. Have them build an Event-
Based model of the whole
business

7. 3 main formats
Big Picture
Corporate retrospectives, organisation reboots, big
architecture redesigns, project kick-offs, startups.
Process Modelling
New processes and services, startups
Software design
Closing the gap to software.

8. Why Should I run an
EventStorming?

9. Plenty of reasons!
Massive learning upfront
Better team engagement -> Connecting with real
stakeholders and their needs
Risk reduction (political impediments and
contradictions)
Highlighting Bounded Contexts -> Microservices
Red carpet to Event-Driven Architectures
I just like being in a room full of colours

11. I had opinions too!

12. 2020

13. “Put all the Key
people in the
same room”
Forbidden!

14. Forbidden!

15. I had opinions too!
Dumb!

16. Business wise…
• Public Trainings -> Stopped
• Private Trainings -> Stopped
• Workshop Consulting -> Stopped
• Event Organisation≤-> Stopped
• Software development …

17. All I’ve got was…

18. Freetime

19. And a mission

20. Not my
favourite sport
Still trying to
be good at it
Not “that”
good, it’s a
metaphor!

21. Time to experiment!

22. Time to challenge
my assumptions
too!

23. Two articles
• One half empty
• One half full
• New Blog layout!
April 2020

24. Then Finally, 18 months later

25. Massive re-discovery
• Faster exploration of massively complex domain
• Overwhelming amount of human-side information
• (body language, ego clash, etc.)
• Possibility to address it: -> Side Conversations
• Italian-Style team building: -> Dinner Together
Please don’t
bullshit me with
breakout rooms,
thanks

26. Here we are!
Photo by Alexander Schimmeck on Unsplash

27. What happened to
Big Picture?

29. Outcome (big Picture):
The whole process is visible
Massive learning (crossing silo boundaries)
consensus around the core problem
Events: Building Blocks
of our business
storytelling
Hotspots: key
issues in our flow
Boundaries:
Between main
phases
Systems: whatever we
interact with
People: doing things
Ideas: to improve
the system
VOTES: on what
to change first

30. A Giant-Sized Puzzle
• Notation designed for easy onboarding of non-technical
people
• Incremental Notation: Progressively injecting precision
• Emergent structure: Chaos -> Validated Narrative - Value
added Layers
• Solving the puzzle triggers deeper learning
• Triggering interesting conversations -> Conflict Visualization
• Seeing the light!

31. We checked for alternatives…

32. So we started experimenting on
ourselves
• Limited familiarity with online tools
• No digital backup of our old processes
• Nothing to lose anyway

33. New
Tech
Stack
•Large second
screen
•Stand-up Desk
•New Laptop
•Better
Microphone
•Hi-res Camera
•New Light

34. Tech stack does make a
difference!

35. Tech stack does make Too
Much difference!

36. Stack effect
• Technology affects
emotions
• And subconscious
perception of other
human beings
• Consultants buy
appropriate hardware,
employees use what is
provided.
Low internet
speed
Video is
switched off
Empathy is
gone
Emotional
Zoom fatigue
on everybody
Increased
probability of
being labeled
an […]
No double
screen
Missing
details
Continuous
Clarification
Single
conversation
bandwidth
Bad
microphone Cracking
sound
Unconsciously
labelled as
annoying
Missing
immediate
feedback
Lower
Throughput
Increased risk
of blindness
Just a matter
of money

37. Kahneman still rules!
• WE can describe zoom fatigue as “the
result of continuously turning system
one (cheap) brain activities into
(exhausting) system two ones.

38. Manage your
energy!

39. Energy Management
3 hours is the maximum achievable
No “final sprint”
Multiple sessions are needed
Asynchronous contribution is possible, but…

40. This problem is here to stay
• Build the context as an
asynchronous journey?
• Wishful thinking.
• Build tools and recipes to
streamline decisions?
• Massive amount of work
upfront, but slowly pays
off.
Zoom fatigue limit
Build the
context
Discuss Decide

41. Playing by the new rules

42. Unlimited modelling space
Visible Grammar
and instructions
Visual Clues and
anchors
Multiple modelling
perspectives
Exploration log

43. Unlimited Modelling space
• We could embrace multiple perspectives on the same
board
• Business Model Canvas, value Proposition canvas,
Wardley Maps, User Story Mapping
• We could make the Evolution Progress Visible.

44. Ongoing experiments
Replacing Project wikis with Miro altogether:
The single learning point for newcomers is the board
Sharing the board with different teams: biz / UX and
tech.

45. Discover as you go
• We eventually dropped “finishing” along the way

46. Asynchronous contribution
• Asynchronous update becomes
handy
• But meta-information becomes
more relevant
• Synchronous wrap up is still
necessary

47. Stratification
• Copy and move on became our standard
• With a few little glitches…
• Easy to add new layers of information
☹
🙂

48. Updated
Recipe
(Honest)
Teams and areas

49. Incomplete is the new
default state

50. Current state
Redesigned business lines -> Done
Redesigned Workshop Format -> Done (and still
evolving)
Designed Startups -> Done
Transformed my organisation -> Done

51. Lessons Learned
It takes more time
Digital Divide matters more than many want to admit
Unlimited space provide options (Layers and Multiple
tools)
Asynchronous is useful, but people need to be heard.
There’s a massive hole in collaborative strategic
decision making, and we might have a few things to
say… :o)

52. Lessons Learned (cont.)
Digital Divide is shifting more weight on the
facilitator
We cannot ask participants to be fluent in Miro
-> facilitators will have more responsibilities.
Engagement will be affected.

53. Human Dynamics
• Big Picture is mostly DISCOVERY
• From CHAOS to CLARITY
• Superimposed structure is a LIE
Photo by Timon Studler on Unsplash

54. As-is vs To-Be
• Big map of the status quo.
• Need to “agree” on the
current state before
designing significant changes
• Corporate Reboot, KickOffs,
• Big map of the future
• Future state stability
validated on narrative
• Designing new businesses, or
new working ways
Should Be
• The current state plus a tension towards a goal.
It doesn’t have
to be polite, or
polished. It has
to work!
Sorry for the
colors!

55. Real world is not squared

56. Incremental Notation
• Key tool for onboarding new people
• Key tool for experimenting while modelling
• The Model Storming meta model:
1. Visualize something
2. Observe the outcome
3. Pick the next key information you need to see
4. Find a suitable notation, and go to step 1.

57. What About Process
Modelling?

58. Collaborative Design
Collaborative discovery will look like a piece of cake.

60. Used to look like this…

62. Color Grammar is not
incremental
It used too be incremental in the early days…
improvements happen!

63. Process Modelling Grammar
• Emojis as first class citizens.
• A grammar designed to enable a conversation -> POLICIES

64. How to make Specialists
with different BackGround
cooperate towards a
common goal?

66. Cooperative Games!
Loved this one!

67. Game Rules: EventStorming Design
1. Every Path Should be Completed
2. Colour Grammar Should be Respected
3. Every Stakeholder should be reasonably Happy
4. Every HotSpot should be addressed

68. Enabling Constraints

69. Investigate Policies
How is our system supposed to react to given events?
Whenever [Event] then [Command]
“We need a lilac between the orange and the blue”
Policy

70. This is where everybody lies

71. I am shaping the
conversation, more than
the code.

72. Emoji == Visible Value
• Money is not the
only currency
• Value delivered is
also great for
chopping into user
stories
• Deeper conversation
when the value is not
clear.

73. Process Modelling
• It works like a charm to design new business
• Starting from scratch -> Together with BMC / Wardley
Maps etc.
• Redesigning old ones -> you see EXACTLY what needs to
change

74. Board Game Approach:
Better cross-background collaboration
Quick Time-boxed temporary leadership
Adaptive rule of conduct
Silent feedback, Deferred feedback, Narrator and scribe,
Turn-based, Ensemble Modelling
Emergent strategies:
Rush to the goal, Chess-like Openings
It’s your team, not the rulebook.

76. Need Diversity in order to
perform

77. What About software
Design?

78. What about The
Aggregates?

79. Expansion Set!
For Experienced Players ;-)

80. Game Rules: EventStorming Design
1. Every Path Should be Completed
2. Colour Grammar Should be Respected
3. Every Stakeholder should be reasonably Happy
4. Every HotSpot should be addressed
5. Aggregates should be coherent (meaningful set of
commands, Events, states)
6. Bounded Contexts should be visible.

82. Not so different…

83. Investigating Aggregates
State Machine Logic
Focus on BEHAVIOUR, not DATA
Postpone NAMING
Don’t fall in love with your intuition
Aggregate

84. Symmetries on the timeline
Do
something
…possibly the
something
Policy Command Aggregate Domain
Event
Policy
User
External System
Command
Policy
Command
User
Domain
Event
External System
Domain
Event
Read Model
Policy
Command
Aggregate
Domain
Event
Policy Command Aggregate Domain
Event
Read Model
Probably the same aggregate…
Probably the same Policy…

85. It used to look like this…

86. Not so different when going online

87. Reframing expectations
• Can you model everything? -> HARD
• Can you make a little improvement? -> EASY
• Can you make a little improvement without convincing
us? -> FAST

88. EventStorming is a conversation
facilitation tool that makes
software design more obvious

89. OK, but how do I get from
this to software?

90. My recipe…

91. Easy transition to User Stories
• Highlighted Value to Stakeholders helps seeing the end
of a User Story… 🙂
• A command or an Event can be the start.
• Easy to spot them on the playground
• Easy to extract and prioritise them

92. Easy transition to BDD testing
• Given Event(s)
• When Command or external Event
• Then Event(s)
• And Read models
Preconditions
Trigger
Outcomes

93. Wireframes
• They can be added on-the-fly instead of Read Models…
• … but you got to be quick!

94. Early Prototyping
• Once I see the flow, I become impatient to see working
code
• Once I see working code I realize there are exceptions to
the flow.

95. That’s life!

97. But it works for me…
A DDD practitioner with >35 years of
coding experience, running his own company
in the multiple roles of Business Owner,
Product Owner, Lead Architect and User.

98. What works for YOU?

99. What works for you?
Did The team join the modelling session? (They should)
Do you need intermediate documentation? Why?
How many companies are involved?
How much time between exploration and
implementation?
How good|Flexible|Specialized is your team?

100. I might
know
this…
Process
<a href='https://www.freepik.com/photos/business'>Business photo created by jcomp - www.freepik.com</a>
But I have no
idea about
this side!
Skills
Project Size
Domain
People
EventStorming
DDD

101. Don’t ask me…

102. Ask your team

103. “What do you really need?”

104. The question is the
challenge!

105. Every tool should prove
itself useful!
(Directly or indirectly)

106. Squeeze and Drop
• Force your team to transparency and proximity for a
time-boxed experiment.
• Add a moderate sense of urgency.
• See which practices get dropped and which ones emerge.

107. Exploit remote
opportunities

108. Summary
It’s about time

109. Keep Experimenting
Not a single thing is “Guaranteed to Work”
But dedication usually make things work

110. Choices
Photo by Alexander Schimmeck on Unsplash

111. Maybe a little simpler now

112. Big Picture
In person to:
• see the whole (including
people).
• kick-off change
• build a team
• Make things happen
Online to:
• Address safety and health
concerns
• .
• …
.
Full-immersion
makes a hell of a
difference.
End of the story
But you need
to feel safe.

113. Process Modelling
In person to:
• see the whole (including
people).
• kick-off change
• build a team
• Make things happen
• Deliver quickly
Online to:
• Allow asynchronous
contributions
• Build a digital information
sharing hub
• .
• …
.
Kick-Off with an in-
person workshop, then
move maintenance to a
Digital format
Go
physical when
you feel the
need.

114. Software Design
In person to:
• Learn how to play the
game
• See team dynamics
• Leverage colocated speed
• build a team
Online to:
• Quick Sessions between
remote team
• Align implementation to
living documentation (to be
maintained).
• .
• …
.
Adjust the
workshop to your team
needs and constraints. But
Choose after
experimenting

115. Respect your brain
Your brain is the constraint

116. Collaborative Games
Can make magic happen!

117. Remote doesn’t
mean ‘forced to
digital’
Paper is STILL BETTER to explore,
sketch, and think.
https://neurosciencenews.com/hand-writing-brain-activity-18069/

118. Thank You!

119. References
• www.eventstorming.com
• EventStormers on Google Groups https://groups.google.com/forum/#!forum/eventstorming
• Awesome EventStorming https://github.com/mariuszgil/awesome-eventstorming
• LeanPub book:
• http://leanpub.com/introducing_eventstorming
• Blog:
• https://blog.avanscoperta.it << Cool new stuff!
• https://medium.com/@ziobrando
• http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation: info@avanscoperta.it
• http://www.avanscoperta.it

120. • Book still in progress
• A lot of content is pre-covid
• Extra content added for
remote approach
• Aiming to be the first book
whose second edition will be
published before the first.
2021