Event Storming

Building the right thing

Schedule

  1. The problem - 10 minutes
  2. Why event storming - 5 minutes
  3. Big picture - 5 minutes
  4. Process level - 3 mins
  5. Design-level - 2 mins
Event storming: building the right thing - @skleanthous

But first a story:

experiences from my career

Why event storming?

Event storming: building the right thing - @skleanthous

It fixes everything! (almost)

  • No more silos
  • Everyone has a voice
  • Clarity on what's going on
  • Shared understanding
Event storming: building the right thing - @skleanthous

What is it?

  • Highly collaborative modelling session
  • Focusing on the events of a system
  • Immensely powerful
Event storming: building the right thing - @skleanthous

What makes it useful?

  • Discussions!
  • Focusing on events is natural
  • Shared understanding
  • Easy to experiment and refactor
Event storming: building the right thing - @skleanthous

Why not something else?

Others mainly lacking:

  • Brainstorming
  • Ease of refactoring
  • Different scopes
  • Ability to involve SME's
  • Gated access to information
Event storming: building the right thing - @skleanthous

Big picture event storming

Event storming: building the right thing - @skleanthous

What is it?

  • An exploration of the problem space
  • Focus on discussion!
  • Shared understanding

→Importantly, it solves most of the problems I mentioned in my introduction

Event storming: building the right thing - @skleanthous

Who participates in it?

  • Founders
  • Subject matter experts
  • Analysts
  • Product team
  • Users!
Event storming: building the right thing - @skleanthous

Process level event storming

Event storming: building the right thing - @skleanthous

What is it?

  • Collaborative workshop to model processes
  • Narrower scope than big picture \ "zoomed" in
  • Clear boundaries defined
  • Often the right level to drive development
Event storming: building the right thing - @skleanthous

Who participates in it?

  • Product team
  • Business Analysts
  • Subject matter experts
Event storming: building the right thing - @skleanthous

Software design event storming

Event storming: building the right thing - @skleanthous

What is it and who participates?

  • Collaborative workshop to agree on software design
  • Entire product team participates:
    • SME's
    • PO's
    • UX
    • dev team
Event storming: building the right thing - @skleanthous

Thank you


Savvas Kleanthous

You can find this presentation here: https://skleanthous.github.io/presentations/

Twitter:
More to come. Follow me on Twitter for more details.

As a junior problem 1: PM required features done PM told BA's BA's spoke to SME's to get requirements BA's analysed requirements BA's spoke to architects Architects did their thing Requirements + architecture were pushed to dev team

Outcome: Missed deadlines, wrong functionality delivered, many bugs, unhappy customers.

Later in life: BA was part of the team But architecture was external Discoveries did not change design or approach Better than before, but more missed deadlines, overtime, again unhappy customers, bugs

Awesome? Nope.

Later in life: Agile won, but as a knee-jerk reaction to big-up-front planning it seems as if the world rejected entirely the notion of up front design. We lost conceptual integrity entirely. Decisions were only locally optimized, and the network effect of communication across departments exploded. Dependencies from other departments started becoming show-stoppers. No visibility -> chaos

Yes, you guessed it, better than before, but still problematic: + Feedback now exists and is considered - No real communication across departments - No visibility of what other teams are doing - Localized decisions need to be repeated in other teams - Loss of conceptual integrity: different parts implement different patterns, or behave slightly different. It feels like a disjointed bundle of pieces