Re: [eventstorming] New to Event Storming. Facilitation questions

[Alberto Brandolini]

Hi Matt, welcome to this group!

On 6 Apr 2020, 17:21 +0200, Matt Klepeis <mattk...@gmail.com>, wrote:

Hello!

I recent came across Eventstorming and immediately I felt like this was the tool we needed to pull our design process together.  I have now been involved in three seperate event storming sessions with our group and I have the following observations/questions.

1)  Our sessions have started to take the form of "Lets walk through the user experience" and we end up documenting every since thing the user does, where all of the minute data elements come from as well as of the user "clicks".  I feel like this is convoluting the process.  In my opinion "menu element X was selected" is not a domain event, but maybe I'm wrong. 

Walking through is just one of the steps, and usually not the first one, of Big Picture ES format. ‘ButtonClicked’ becomes an event only as long as there’s somebody else interested In this event downstream. "Menu element X is selected” doesn’t sound like a domain event, in most cases.

While designing a process and/or a piece of software a more efficient interaction is to treat the design process as a collaborative game: completing every flow, making sure the grammar is respected and so on.

2)  I also feel like our sessions have turned into a very long grooming session.  I believe event storming is to be a tool to help lay out how something works/should work to establish a domain but then after the layout is complete groups of stickies can then be groomed for additional implementation details. 

Sounds like boring. Every modelling tool will have a decreasing ROI after a while, so if the discussion is going nowhere, better stop it and take a break, and possibly another perspective.

The main goal of ES is to make an interdisciplinary conversation possible, on neutral ground. So that business, tech and UX can merge their perspectives. This requires losing some precision of each tribe’s vocabulary. I haven’t been in your sessions, but I smell an unbalanced perspective.

3)  Members of the group are trying to diagram decision logic in too much detail.

This will always happen. I call this behavioural stereotype “the driller”, you need to have a different perspective in your modelling team. “The pragmatic” is the one that will cut the discussion short, with something like “this is only happening 0.0001% of the times”. If you don’t have this perspective in the team then good luck! 

Still the collaborative game approach mitigates this, because you’ll never going to finish if you keep exploring.

I’ve seen something similar - I mean when you say diagramming - in a session where the internal expert needed to explore the whole decision tree before laying down the next step, while my approach was to take a single branch and complete the flow. I was totally in ‘lean startup mode’  but the expert was totally on the other side.

 

4)  How long should Event Storming take?  I've been in some sessions where we documented an entire process after a few hours.  I've been in others where we are going on 14-15 hours over 2 weeks for a very complex process.  Is there a general rule of thumb here?  

It really depends on the format. Big Picture is usually constrained by people availability to be one full day.

Process Modelling and Software Design session don’t take longer than one day, but can get shorter. Of course it depends on the process! 

But discipline plays a role too! I’ve run a live modelling session at DDDEurope with the main purpose of showing how fast it could be, when given discipline is applied. “Rush to the goal” (focusing on the baseline and marking every alternative branch with a HotSpot, meaning “Not Now!”) is my favourite approach to deliver something in a time box. But the interesting part of the session was the incredible amount of people asking for side topics and corner cases.

No surprises: that’s what our colleagues do. But we need a strategy not to get swamped.

Cheers

Alberto

Thanks!

--
You received this message because you are subscribed to the Google Groups "EventStorming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eventstormin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eventstorming/2ecff848-5623-4489-9fd5-058ae8d770fb%40googlegroups.com.

[Matt Klepeis]

Thanks so much Alberto I appreciate your feedback!

I started having a retrospective with the senior level individuals that were involved in the process today and it went well.  I am on the technical/architecture side of things and another technical leader and myself are really driving this initiative.  Our business partners had great feed back in the retrospective and said they didn't think they would have a challenge convincing their leadership of the value of putting the time into getting the process right and they would like to start using ES for all of their upcoming initiatives (very exciting for me). 

We do have some resistant personalities on the technical side but I think it's because they are new to DDD and haven't seen how to connect the dots from the model to implementation.  They will be brought kicking and screaming if necessary :)

Some additional items that came out of the retrospective were 

1) We can't wait for the lock down to end so we can do this in an actual room.

2) As I briefly mentioned in my earlier post I feel like we were making everything an Event.  This is something that I know we will get better at over time.

3) We need to work on how to handle conditional logic (sometimes extremely nested conditional logic).  I think its very easy for individuals to want to start moving towards drawing logical flows instead of staying at the business process level.  I am advocating that we use these opportunities to take a look at the conditional logic to see if it can be simplified.  Or we simply throw up a purple sticky that denotes some processing of the data is done and then use stickies to represent the various final outcomes.  If we need to capture additional details about the inner workings of the purple sticky just so we don't lose the details of the conversation we can introduce another color sticky for "Additional Details"

One item that might be great for the book, and apologies if it is in there I am reading three different books at the moment and haven't finished yours :), most of the examples and videos I come across on the web don't include the user experience.  I feel like most of the examples start with the event "User submitted a Request" and then from that point on its here is all of the behind the scenes stuff that happens in the process to accomplish that task.  I traditionally work on the service tier of the applications I maintain so that makes perfect sense to me.  I think more examples that include the user experience would be great.  For example a business process that includes more direct user interaction and multiple views presented to the user.  Maybe conditionals that determine which data/view is returned. 

Thanks again for your feedback.  I'm sure you'll be hearing from me more as we continue to work through this!

-Matt

To unsubscribe from this group and stop receiving emails from it, send an email to events...@googlegroups.com.

[Yves Lorphelin]

on the point of 

> 3) We need to work on how to handle conditional logic (sometimes extremely nested conditional logic). 

A trick you can use in a Big picture Scenario is to treat the complex logic as a black box:
For the process as a whole you're only interested in the input & output,

but mark it with a HotSpot sating "Deep Exploration Needed in another session"  so that the concern of that particular person is addressed visibly.

To unsubscribe from this group and stop receiving emails from it, send an email to events...@googlegroups.com.

[Alberto Brandolini]

Il giorno mar 7 apr 2020 alle ore 01:51 Matt Klepeis <mattk...@gmail.com> ha scritto:

Thanks so much Alberto I appreciate your feedback!

I started having a retrospective with the senior level individuals that were involved in the process today and it went well.  I am on the technical/architecture side of things and another technical leader and myself are really driving this initiative.  Our business partners had great feed back in the retrospective and said they didn't think they would have a challenge convincing their leadership of the value of putting the time into getting the process right and they would like to start using ES for all of their upcoming initiatives (very exciting for me). 

We do have some resistant personalities on the technical side but I think it's because they are new to DDD and haven't seen how to connect the dots from the model to implementation.  They will be brought kicking and screaming if necessary :)

Don't underestimate this resistance. It may backfire later if they don't see any solution to their current pains. "Everything will be better after this" may not be enough.

Make the objections visible and part of the conversation. Maybe this won't be addressed during the session but will be important later on.

 

Some additional items that came out of the retrospective were 

1) We can't wait for the lock down to end so we can do this in an actual room.

2) As I briefly mentioned in my earlier post I feel like we were making everything an Event.  This is something that I know we will get better at over time.

Yelling "does anyone care about this ButtonClicked??!!" can work remotely too.

 

3) We need to work on how to handle conditional logic (sometimes extremely nested conditional logic).  I think its very easy for individuals to want to start moving towards drawing logical flows instead of staying at the business process level.  I am advocating that we use these opportunities to take a look at the conditional logic to see if it can be simplified.  Or we simply throw up a purple sticky that denotes some processing of the data is done and then use stickies to represent the various final outcomes.  If we need to capture additional details about the inner workings of the purple sticky just so we don't lose the details of the conversation we can introduce another color sticky for "Additional Details"

That's what people are good at! I mean you may be asking to pro soccer players, "let's play basketball instead!" if they're used to feel good in what they do, they might not appreciate being taken out of their comfort zone in public. That's one reason why I push onto the collaborative game analogy: in a game you may try new things.

 

One item that might be great for the book, and apologies if it is in there I am reading three different books at the moment and haven't finished yours :), most of the examples and videos I come across on the web don't include the user experience.  I feel like most of the examples start with the event "User submitted a Request" and then from that point on its here is all of the behind the scenes stuff that happens in the process to accomplish that task.  I traditionally work on the service tier of the applications I maintain so that makes perfect sense to me.  I think more examples that include the user experience would be great.  For example a business process that includes more direct user interaction and multiple views presented to the user.  Maybe conditionals that determine which data/view is returned.

Point taken, in the meanwhile... the facilitation driver is to emphasize the role of Read Models and/or UIs as supporting the which decision am I taking here? the decision drives the need for given data to be displayed in a given way. Sometimes we just need to understand which data, other times the layout is key, or implicit data is key (like a big splash picture of an island on a travel website). We also factor in how we want the user to decide, providing a rational or emotional message or a combination of the two. 

Alberto

 

To unsubscribe from this group and stop receiving emails from it, send an email to eventstormin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eventstorming/3dc42a47-42b7-4d61-81d3-4983e7dbf273%40googlegroups.com.

--

Alberto Brandolini
Phone: +39-347-6005027

E-mail: alberto.b...@gmail.com
Twitter: @ziobrando

Company: http://www.avanscoperta.it
Blog: http://ziobrando.blogspot.com
Linkedin: http://www.linkedin.com/in/brando