EventStorming was born as a massively in-person workshop to discover and model complex businesses and design event-driven software. But the old ways are no longer viable. After one year of experiments and discoveries in a forced-remote setting we know a lot more about what is still working and what is not.

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

2. About me
• Coding since 1982
• … but that’s not what I get paid for
• #DDDesign #Agile #Lean
#Complexity
• I invented
• I smell
• I run www.avanscoperta.it

3. 2013

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

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

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

9. I had opinions too!

10. 2020

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

12. Forbidden!

13. I had opinions too!
Dumb!

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

15. All I’ve got was…

16. Freetime

17. And a mission

18. Time to experiment!

19. Time to challenge
my assumptions
too!

20. Two articles
• One half empty
• One half full
• New Blog layout!

21. What happened to
Big Picture?

23. Flavour: Big Picture Workshop
Invite the right people -> Business, IT, UX
Provide unlimited modelling space
Surface, Markers, stickies, oxygen, etc…
Model a whole business line with Domain Events on
a timeline.
A big “That will never work
in my organisation” type of
objection is expected here.
This hasn’t
changed in the
meanwhile

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

25. The hidden value of proximity
Multiple Parallel conversation
Low Friction Tools
High Commitment and Focus
Team-Building side effects
Emerging Time Management (The escape room effect)
Third-Time approach (Rugby Style)
🙂

26. The Dark Side of Remote
Single - often annoying - conversation
Extra friction due to the tech stack
Lower Commitment
Almost no team building, the opposite quite possible
Zoom Fatigue -> need smaller slots.
"Gotta Go” approach
☹

27. What could be delivered in
1 day, now takes 3 (half)
days or more….

28. So I checked for alternatives…

29. But we had commitment!
• Public Trainings -> Stopped
• Private Trainings -> Stopped
• Workshop Consulting -> Stopped
• Event Organisation≤-> Stopped
• Software development …

30. Time To experiment!

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

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

33. They make a difference!

34. They make Too Much
difference!

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

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

37. Manage your
energy!

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

39. Unlimited modelling space
Visible Grammar
Visual Clues and
anchors
Multiple modelling
perspectives

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

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

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

43. Asynchronous contribution
• Asynchronous update becomes
handy
• But meta-information become more
relevant
• Still Synchronous wrap up is
necessary

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

45. Updated
Recipe
(Honest)

46. Incomplete is the new
default state

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

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

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

50. What About Process
Modelling?

51. It just happens!
https://www.dropbox.com/s/i2vrvdplwieizop/
Screenshot%202021-04-07%20at%2017.12.44.png?dl=0
The surroundings
are just
scratched
Core processes
are validated with
sophisticated
grammar

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

53. Process Modelling during validation
Facilitator is having more responsibilities:
Being a scribe during validation requires miro fluency
Doing 2 rounds of validation seems like a waste of
time
Process Modelling grammar gets introduced earlier

54. Process modelling standalone
More precise commitment
Different strategies are possible: (split and merge/
Comparative Modelling)
Longer term Artefact: this is who we are!

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

56. What About software
Design instead?

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

58. Cooperative Games
Loved this one!

59. 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. Every component should be Reasonably consistent
6. Boundaries should be visible

60. It used to look like this…

61. Now it’s more like this…

62. Or this!
(A little more CQRS/ES)

64. Software design grammar

65. Enabling Constraints

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

67. Software design was already
happening remotely, simply
it was not a ‘storming’

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

69. My personal recipe…

70. 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 them into a backlog (Miro Magic here!)

71. Easy transition to BDD testing
• Given Event(s)
• When Command
• Then Event(s)
• And Read models
Preconditions
Trigger
Outcomes
Scenario: Registering one attendee to a public training clas
s
Given a public training class has been schedule
d
When I register attendee Random Attendee to the training clas
s
Then attendee Random Attendee should be registered to the training clas
s
And the attendee should be visible in the training class dashboard

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

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

74. That’s life!

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

77. What works for YOU?

78. 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?

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

80. Don’t ask me…

81. Ask your team

82. “What do you really need?”

83. The question is the
challenge!

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

85. Exploit remote
opportunities

86. Summary
It’s about time

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

88. Be Honest!
Not a single thing is “Guaranteed to Work”
…but hey! What are the alternatives?

89. Remote doesn’t
mean ‘forced to
digital’
Paper is STILL BETTER to explore,
sketch, and think.

90. Thank You!

91. References
• www.eventstorming.com
• EventStormers on Google Groups
• https://groups.google.com/forum/#!forum/eventstorming
• LeanPub book in progress:
• http://leanpub.com/introducing_eventstorming
• Blog:
• https://medium.com/@ziobrando
• http://ziobrando.blogspot.com
• Twitter: @ziobrando
• Trainings & Workshop facilitation: info@avanscoperta.it
• http://www.avanscoperta.it