1 Million Orange Stickies later - Devoxx Poland 2024

•

0 likes•301 views

About 10 years after the original proposal, EventStorming is now a mature tool with a variety of formats and purposes. While the question "can it work remotely?" is still in the air, the answer may not be that obvious. This talk can be a mature entry point to EventStorming, in the post-pandemic years.

More Related Content

1 Million Orange Stickies later - Devoxx Poland 2024

1. 7 100. 1.000 avanscoperta

2. About me running www.avanscoperta.it (strategic consulting and training) Modelling (almost) everything with sticky notes, markers and a paper roll. Calling this stuff

4. 2013 • First Blog Post About EventStorming • One single path from business to aggregate discovery • The beginning of a long journey

5. 2019 • Growing Momentum • Many practitioners -> Many Ideas • Many different formats: • Big Picture / Process Modelling / Software Design • Retrospective / Induction / Startup Design / More… • Running out of Orange and Lilac post-it worldwide.

6. 2020

7. 2020 • “Put all the key people in the same room”… • 98% of our business became illegal overnight • And forced us to reinvent the workshop!

8. 2024 • In-person is an option again • But many organisations turned to remote • … without understanding the consequences • https://www.slideshare.net/slideshow/all-the-small- things-xp2024-bolzano-bozen/269646051

9. Big Picture EventStorming Making sense of a huge mess

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

11. Hey! Shouldn’t we focus on a specific area? nope! Well… you can, but you’ll miss a lot of the potential

12. Establish a timeline Some facilitator tricks will kickstart the discussion quickly (2-3 mins to get the ball rolling)

13. Explore with domain Events

14. The shape of the organization

15. The knowledge distribution

16. Nouns will fool you And will probably fool LLMs too!

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

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

19. Standard Recipe Chaotic Exploration Breaking the ice, laying down the initial structure Enforce the timeline Triggering conversations, emergent boundaries People and Systems More details for precise storytelling Explicit walkthrough Validated narrative

21. CLARITY

22. People are afraid of breaking invisible things

23. Let’s make everything visible

24. Bonus outcomes

25. Big Picture EventStorming Aimed at collaborative discovery -> issues are visualised, not resolved. Scalable (with tricks) 12 -> 20 -> 35 -> 50 peopleMassive Learning Honest Map of as/is or Plausible map of future state Official Outcomes: massive learning, bounded contexts, alignment Unofficial outcomes: business learning the business, spot the enemy Enterprise projects don’t fail because of technology; they fail because of politics

26. Validated Narrative enables cheap layers

28. This is what I see: A clear business narrative Political Consensus A massive blocker

30. Toppings - (A menu, not a sequence) Explore Value Multi-currency Value-Stream Mapping alternative Problem and Opportunities + Arrow Voting Consensus over the most important problem to solve Emergent Boundaries All the information is already under your eyes Team Boundaries Do they match with the emergent boundaries?

31. Emerging context boundaries

32. An Item needs to have an approved description and a high quality image before being added to the catalog Just give me a valid URL and I’ll start tweeting about it

33. Under our eyes.

35. Can we do it remotely?

36. In-person experience Big Results in ONe Day Commitment to finish Full Day In Person High Conversation Throughput Peer Pressure Lo Fi Deeper Learning Experience $ Localized conversations % Early Results & Full Focus

37. Micro-Laziness as a key facilitation tool Wall accessibility Markers availability Sitting or standing

38. From Problems to solutions Constraint Problem Solution Side Effect Pandemic IN Person is Banned Move to Digital (Miro + Zoom) Friction in Execution Working on Miro No Miro Fluency 20 min warm up Delayed Results, smaller Timeframe Working on Zoom Zoom Fatigue Shorter Chunks, only Half Day Delayed Results, more chances for opting out New to Miro Friction with Tools More active facilitation More Passive Participation Active Facilitation No space for reactivity Heavily Scripted Boards Decreased Ownership Zoom & Miro Delayed Results Anticipated Sorting Higher Chance of mistakes Each side effect affects the overall perception of value

39. Remotely… Disappointing Results No Commitment to finish 3 Half Day Sessions Remote Low Conversation Throughput Limited Peer Pressure Digital Shallow Learning Experience Centralized conversations Delayed Results Open to distractions More Passive role Still better than the alternatives, but …we know what it could have been

40. By Javier Somoza, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=48092778 Can I make Carbonara with cream?

41. Remote Big Picture 🙂 Improved Facilitation Techniques 🙂 Modelling tools (MIRO) becoming more pervasive 😒 Still Nowhere close to the in-person interaction 🙁 Big risk of opting out before value is delivered.

42. There’s still a reason for the toga party

43. Do yourselves a favour: run it in-person

44. Can we do it hybrid?

45. Process Modelling Making sure we’re doing the right thing

46. Some Assumptions We’re working on the most compelling problem The problem has a solution in Software and/or Process Key Experts are available Business people, from the departments involved Technical Experts: Software and Service/UX Designers Note: assumptions can be broken, if you’re aware of the consequences.

47. Scope: Key Process Command Domain Event Domain Event Read Model Domain Event Read Model Preconditions Outcomes The flow to discover Please Note: Our scope is a unit of understanding, not necessarily matching with units of delivery

48. Now what?

49. A different job Big picture is for discovery -> Disagreements are OK Here we are Looking for an agreement -> Consensus is HARD

51. How to make Specialists with different BackGround cooperate towards a common goal? Without a Danger?

52. Idea: Cooperative Games Massively influential on me

53. Game Rules

54. Process Modelling Game Rules 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

55. Every Path Should Be Completed

57. Colour Grammar is respected

59. Events: getting more precise every round Hotspots: Open issues in our flow Policies: reactive logic External Systems: that we interact with People: doing things Read Models: The data needed to take a given decision Commands: or actions

60. Colour-puzzle Thinking Policy User User Command Read Model External System Domain Event Command

61. Do we ALWAYS need a Policy? Yes, My game, my rules

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

63. This is where everybody lies

64. Ambiguity does not compile

65. Policies spectrum IMPLICIT POLICIES: without an explicit agreement EXPLICIT POLICIES: assuming everyone is following them AUTOMATION: Listeners, Sagas, Process managers Policy User Policy

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

67. Exploring Value 😀

68. UML was not designed to support a conversation

69. UML was not designed to support an interdisciplinary conversation

70. Process Modelling EventStorming

71. Extracting User Stories Sometimes, it can be as easy as connecting commands to 😁

72. Extracting acceptance tests Great, we’re done! Not Yet! Can we flesh out some examples with names and numbers?

73. Good old BDD Format: Given (one or more past events) When triggering command Then resulting Event(s) And observable read model

74. Build Large Visualisation Tools

76. Can you do it remotely?

77. Remote Process Modelling 🙂 Reduced loss compared to big Picture 🙂 The artefact could be made available to a larger audience. Slower, anyway. 😒 More active facilitation necessary 🙁 The human touch is still missing.

78. Software Modelling From Business Need to Implementation

79. What about The Aggregates?

80. Expansion Set! For Experienced Players ;-)

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

83. Colour-puzzle thinking - again User Command Read Model External System Domain Event Command Policy Aggregate

84. OBSOLETE!

85. On a surface… Events: getting more precise every round Hotspots: Open issues in our flow Policies: reactive logic External Systems: that we interact with People: doing things Read Models: The data needed to take a given decision Commands: or actions Aggregates: State machines, or independent components

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

87. 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… Please Note: Timeline representation is suboptimal for OOD, but necessary to keep business stakeholders in the conversation.

88. What the business sees Your Territory

90. We need to give up something as individuals in order to succeed as a team

91. A single tool won’t be enough to solve everything So you can go for multiple visualisations around the same problem

92. Happy Stakeholders Well …reasonably happy!

93. Challenging value Every step can create or destroy value for given users Discovering multiple currencies Discovering new opportunities Discovering inconsistencies

94. The Thing with Value…

95. Dealing with Value Money is the Obvious one But it’s a Zero Sum Currency :-/ More interesting currencies follow: Time, Stress, Anxiety Joy, Reputation, Satisfaction …

96. HotSpots are addressed But Not Now!

97. The Perfect Team Does it even exist?

98. Competences Business From different Sides Software Design User Experience & Service Design …

99. What about attitudes?

101. Need Diverse Attitudes in order to perform

102. Strategies & Complex Moves This is more up to you…

103. Openings

104. Openings Start from the beginning More natural Easy to get Swamped Start from the end (Reverse Narrative) Lean, but less discoveries Not so natural for newbies Explore with Events -> Then Connect Needs Strict Timeboxing

105. I use all of them!

106. Team Agreements

108. Team Strategies Temporary leadership Narrator and scribe Swarm: Everybody on the problem Mob: One on the problem, everybody on feedback. Silent feedback only Split & Merge

109. Can you do it remotely?

110. Remote Software Design 🙂 Reduced loss compared to big Picture 🙂 The artefact can became long-lasting for frequent small sessions 🙁 Kick-off is less participatory 😒 More active facilitation is necessary 🙁 Risky on the human side

111. Takeaways

113. is my pizza: You can add your toppings With the notable exception of database tables and pineapple

114. From vision to detail (and back) Big Picture Events Hot Spots, Systems, People Conflicts, Goals, Blockers, Boundaries Process Modelling Events + Policies, Commands, Read Models Value Proposition, Policies, Personas, Individual Goals Software Design Events + Aggregates Aggregates, Policies, Read Models, IDs

115. IN person or remote? Format Colocated Weakly remote Natively remote Big Picture In Person FTW IN Person Use gatherings! Or… Use your patience and do it remotely Process Modelling In Person In Person KickOff, then decide as you go. Multiple remote sessions Software Design In person, turn online after delivery In person Kick-Off, remote refinements Multiple frequent remote sessions Organization

116. Thank You!

117. References • www.eventstorming.com • EventStormers on Google Groups • https://groups.google.com/forum/#!forum/eventstorming • LeanPub books: • http://leanpub.com/introducing_eventstorming (still growing) • https://leanpub.com/ddd_first_15_years • Blog: • https://medium.com/@ziobrando • https://blog.avanscoperta.it • http://ziobrando.blogspot.com • Twitter: @ziobrando • Trainings & Workshop facilitation: [email protected] • http://www.avanscoperta.it

1 Million Orange Stickies later - Devoxx Poland 2024

Related slideshows

More Related Content

1 Million Orange Stickies later - Devoxx Poland 2024