Event storming recipes

20,786 views
22,270 views

Published on

Collecting requirements or understanding a large system seems such a long and demanding activity. We can do al lot better than this: unlimited modelling space and all the key stakeholder in the same room, with some special spice. :-)
Domain-Driven Design has never been so efficient. This is where DDD meets Kanban, TOC and Management 3.0.

Published in: Self Improvement, Technology
3 Comments
66 Likes
Statistics
Notes
  • Talking about the Big Picture vs Detailed Model... one does not exclude the other. But they happen at different moment in time. A first high level eventstorming might clarify the whole context and goals, while a second focused round will drill into the mechanics. But I have to admit that the tool is flexible enough to let me take last minute changes, when I discover that there is a different problem/goal from the one originally stated.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Many things together: depending on the people in the room, the discussion might be focused more on the technical side than on the process side. When investigating on value generation, I try to steer the discussion around the different personas/roles involved and to the value created for/by them. This leads to more Domain Events, not necessarily turned into software.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Love the concept! I did try to use the Event Storming approach into a Service Design context. I always start the domain exploration with a stakeholder map and a system map which basically map all the actors (people) and the actors (services and data info flows). Tackle the problem from the event part of the domain is really really effective and appealing, but the struggle I found is mostly related to the fact that the event domain is too broad to be manage along with other different activities strictly related to our field. People and services are de facto outside your modelling system: they are causes and effects, you can work with them, but their relationships are not physically tracked. On the other side, the big picture is ensured only if the model is somehow comprehensive or complete to a good enough level of detail, but as far as I understand, it is better to subdivide the domain into several areas and try to model them in depth, instead of having a big less accurate modeling. An interesting approach I use, is to use event storming not for domain analysis, at the beginning of the strategic thinking, but at the end of the analysis, after the user research and the service blueprint. With the service blueprint I map the backstage flows my project will require. Usually I don't have time to explicitly visualize the As-Is, therefore small focused session of Event storming are good to bridge the designed blueprint with all the "technical" part of the project: requirements, stories and definitions. In order to be effective I do sacrifice the big picture, but at that stage, it should be / has to be already clear to all the stakeholders (hopefully).
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
20,786
On SlideShare
0
From Embeds
0
Number of Embeds
9,037
Actions
Shares
0
Downloads
206
Comments
3
Likes
66
Embeds 0
No embeds

No notes for slide

Event storming recipes

  1. 1. EventStorming recipes @ziobrando
  2. 2. What’s Eventstorming Let me show you…
  3. 3. #CDays14 – Milano 25, 26 e 27 Febbraio 2014 Video!
  4. 4. What’s Eventstorming All the key stakeholders in the same room with an unlimited modelling space using stickies as Domain Events
  5. 5. But basically…
  6. 6. it’s a party Let me show you…
  7. 7. who should we call?
  8. 8. you missed the party
  9. 9. but also…
  10. 10. You’re invited to the next one
  11. 11. hack the place
  12. 12. no sitting
  13. 13. Ubiquitous body language
  14. 14. Domain Events
  15. 15. along a timeline
  16. 16. Let the magic happen!
  17. 17. no UML No BPMN NO …
  18. 18. Model affinity
  19. 19. Domain events are just a sweet spot
  20. 20. next steps
  21. 21. incomplete is a legitimate state
  22. 22. When should we stop?
  23. 23. The real constraint…
  24. 24. Make the party memorable
  25. 25. What are we seeing exactly?
  26. 26. system view
  27. 27. Different people make a different party
  28. 28. in small companies…
  29. 29. Code coverage?
  30. 30. http://www.businessweek.com/articles/2013-04-18/faq-reinhart-rogoff-and-the-excel-error-that-changed-history
  31. 31. look for things that matter
  32. 32. who’s with me?
  33. 33. gotta do something!
  34. 34. are you ready for it?
  35. 35. What about remote eventstorming?
  36. 36. What about remote toga party?
  37. 37. Ok, seriously
  38. 38. Wrapping up
  39. 39. but…
  40. 40. leave it around, for a while…
  41. 41. chaotic eats sequential for breakfast
  42. 42. Creative collaboration
  43. 43. meaningful conversation with domain experts?
  44. 44. ©  Alberto  Brandolini  2009 experts  help  us   to  understand and  we  help   them
  45. 45. choose your role
  46. 46. Find an observation point
  47. 47. Model storming?
  48. 48. sorry about that
  49. 49. © Alberto Brandolini 2013 Event Storming expected outcome steered towards a canonical model partially defined steps model affinity given problem type
  50. 50. © Alberto Brandolini 2013 Model storming unpredictable outcome no canonical model notation incremented iteratively ! no predefined problem type
  51. 51. Don’t postpone people
  52. 52. questions?
  53. 53. Tkanks! @ziobrando
  54. 54. References EventStormers community on Google+ https://plus.google.com/u/0/communities/ 113258571348605620818 ! Introducing Event Storming: http://ziobrando.blogspot.com/2013/11/introducing- event-storming.html

×