This week I got to facilitate my first big picture EventStorm with the business partners in one of the domains for which my team owns the application. This was specific to a fraud investigation team who is responsible for check, ACH, and other card fraud. It was a really interesting experience and I learned a lot.
I re-did all the keys and guides based on my experience and the additional information I gained from Alberto’s and Paul’s respective books. Overall things went pretty well considering we only had 2 hours and I received a lot of positive feedback, but there are some things I would change in the future.
Instead of having a single key for all the elements, I made individual keys for each of the components so I could reveal them individually as we went. I also created a poster with some ground rules based on something I read (maybe it was called Deep Democracy?? I need to look again), basically that no one has a monopoly on truth, we agree to learn together, and the point of working together is to start a conversation and strengthen our relationship.
I decided we would try to do as much of the Big Picture concept of an EventStorm and not really break into the design portion since we weren’t working on the particular application for a while. Started by having them put up events. I did notice it was hard for that group to write events in the proper past tense format, so that was a note I have as a take away to try to address in future sessions. The chaotic exploration /slash/ slient working time went reasonably well, but I noticed when I opened it up for discussion and refactoring there was a hesitancy to remove or replace anything that they had already stuck up there - I will plan to tell everyone in the future that the amount of garbage we create is a measure of success and learning to help solve that problem. One thing I did notice was a lot of discussion about hypotheticals or details about how systems worked and what systems were involved well before they truly understood the events. There were a couple… let’s just call them troublemakers who wanted to do their own thing and only get involved in a limited capacity otherwise. I will have to find some facilitation tricks to deal with that in the future. I think one thing I will do next time is if someone is monopolizing conversation and explaining a lot verbally, ask them to show me where that information is on the events so we can address it. I also need to let them know if they want to introduce concepts not to try to figure out how to add them, but to let me know and maybe we can introduce additional concepts early. They really wanted to talk about external systems, and for some reason kept trying to express their existing system as an external system instead of just recognizing the events we were creating were part of their existing system, so the system itself doesn’t need to be represented.
Something else I noticed was that folks started writing on the paper - which I should have warned against and stopped as soon as I saw it - and suddenly their creativity and willingness to move things around went through the floor! I know Alberto talks a lot about how the size of the modeling space will impact mindset and approach, which is why we try for the unlimited modeling space concept - but it became clear to me that I need to warn people not to draw on the modelint surface or do anything that might limit them. All the materials I provided were movable, removable, replacable, and changable. Sticky notes and post-it tape/roll - so in the future I will be a bit more specific about that up front.
I also observed that things start to fall apart a little bit or collapse a bit once I tried to introduce the concepts of external systems and actors/people in the system. I need to see if there’s a better way to have that make sense and start being effective. I felt like the external systems were being put up at a rate that was way heavier than I expected, and they seemed to self-restrict and start trying to represent multiple external systems on a single sticky. I think if we had discussed and focused on the flow we could have found some specific ways to fit the external systems in without overdoing it. The actors/agents piece I think just wasn’t well understood. I’ll need to re-evaluate that part and do some further reading and research to figure out how to make that aspect work a bit better.
Overall it went really well. I got a lot of positive feedback from the business partners that participated and from the folks on the development team as most of them had never worked in that domain space or with that application. I’m going to keep exploring what others have done in the EventStorming space and getting ready for the big one with all the folks who are traveling to kick off this project. I am curious about how the results of an EventStorm might turn into a Story Map and if there’s some way to migrate work that way. I also started looking into Story Storming and Example Mapping - I think there could be some cool ways to combine these techniques or have them flow from one to the other - maybe an EventStorm to understand the domain space, then a Story Storm to actually create all the relevant stories to include in a Story Map, and then Example Mapping to help ensure the team understands all the rules/policies around what they are creating… it’s still too soon for me to have a unified process for all of these, but I’m adding these to my list of places to explore in the future.