This week I facilitated a big project kick-off offsite (it was really onsite, but for some reason everyone called it an offsite!) meeting, and overall it went really well. Had about 18 people participating when everyone was in the room and really explored the domain space. There were some challenges and hiccups, I had to pull a lot of ideas out of my facilitator bag of tricks, but eventually we got where we were trying to go. I got a lot of positive feedback and I think the session helped to give business partners more confidence that the technology teams understand what they are trying to accomplish and that they are serious about redesigning these legacy systems to be more intuitive, functional, and useful. I think this also helped the senior leadership to see that their business folks do understand what they want to accomplish and can steer this in the right direction.
The room that the project manager had booked was not a great setup for EventStorming, and I couldn’t find any other rooms that would work better and available to switch to, so we had to make due. I had the facilities folks swap out the regular chairs for stackable chairs so we could get them out of the way when not needed. Instead of a big conference table this room had some smaller movable tables, so I pushed some out of the way/along the walls, and arranged the remainder into a large pod so during the parts where we were sitting we’d have somewhere to do so and set up laptops and work, but the set up ensured there was plenty of room for people to move around and work the modeling space. There was wall space (well technically windows) where I could hang the paper, it was maybe 4-5 meters of space which was going to be a tight constraint.
Everything started really well. I used the same meeting ground rules about no one has a monopoly on truth, that we work together for understanding, and to deepen our relationship - everyone was in agreement and was good with them so we got started. I had re-done all of the posters based on feedback from the previous attempts, and I think it helped create greater clarity and understanding up front. The chaotic exploration started and people were a little unclear why we were working solo, but events started getting posted rapidly. I think the updated poster helped because they were much more in line with the desired format than had happened the last session. Lots of events were posted in the 20 or 30 minutes of quiet time - even with some background understanding of the space, and I knew it would be a big domain, it was even bigger than I expected.
Before opening it up for discussion and to enforce the timeline, I hung another sheet of paper on the wall to expand the modeling space. The group had nearly completed filled the initial sheet with events, so we had to expand the space to give them more room to work. The discussion started going really well. I told them to dump the trash straight on the floor below the modeling surface and they started refactoring their work. Pulling down duplicate events, re-writing bad events, adding ones that had been missed, and ordering them along a rough timeline. The group did a great job and I heard a lot of discussion about why things happen the way they do, or whether things need to continue happening that way. Overall I think they all learned a lot from each other.
One of the biggest challenges facing this group was a very condensed timeline (1.5 days for the offsite) and what they wanted to accomplish in that time. EventStorming seems to work better if you can do 2 hour time blocks 1-2 times a day for multiple days in a row, and we were trying to cram as much as we could into the 10 or so hours we had. I think by the time we finished with the rough timeline the group was starting to lose some steam, mainly because of the size of the domain space and the number of events that were represented.
We next moved in to adding structure, and this is where we started to encounter some challenges. I added one more sheet of paper to expand the modeling surface again (vertically, since we had no more horizontal space to work with) to give them more space to work. I explained pivotal events and temporal milestones and asked them to consider that type and level of structure first, and then showed them swimlanes. They identified the pivotal events pretty easily, and it took some time but eventually they had some swimlanes on the first ¼ to ⅓ of the flow, but it was then time to break for lunch and things kind of stopped and didn’t pick up again after everyone ate. I think the biggest issues was the lack of horizontal modeling space, not having all the right people in the room, too much to accomplish in the time we had, and general brain drain and exhaustion. Without more space it became hard to refactor the events and add structure because there was too much going on to easily add the structure. There were not as many domain experts as I would have liked - we had Director, VP, and SVP level people in the room in spades, but the actual people who do this work day in and day out was limited to only a few, and I think this made the level of understanding and focus a bit more high level than could have made this really successful. As I mentioned before it was a lot to try to cram into a short period of time, and as a result I think mental energy was being expended to where people were feeling fatigued. Where we did get was a great start, but I feel like there was a next level we weren’t quite able to reach.
After the structure we tried to get into where do events come from - my attempt to fix the problems with agents & external systems from the last EventStorming session I ran - based on some things I saw where it combined people with actions/commands. This is when things really started to go off the rails. The business folks didn’t understand why there needed to be a blue “place order” sticky and then an orange “order placed” sticky - we tried to explain, but it didn’t click or go through. As a result the concept of actors/agents also collapsed because they said there were way too many to represent. I attempted to facilitate through it, but with no success. Even the BSA and architect tried to jump in and help me, but we couldn’t seem to break through. We wound up brainstorming a long list of external systems and just tracking them on another flip chart instead of putting them into place. This helped us to see how many external systems people are using, but not really map them to any of the events we had put up. I think again the space constraints made this too mentally taxing - they’d have to move too many stickies in too small of a space that I think their brains just kind of shut down at the idea of adding another layer onto the events.
When we tried talking about actors/agents again, we got redirected. There was a heavy focus from some of the more senior business people in the room that they felt it was really important to talk about “role attributes”. I wasn’t exactly sure what they meant and was having trouble wrapping my head around the concept. It seemed like it was agents/actors/people that they were talking about, but when trying to get them to add people to the events we had created there was a lot of resistance and pushback - this system could technically be used by anyone in the company, so they felt there would be too many to represent, or too many events that could be performed by multiple people. I expressed that really we only need to categorize specific types of actors, not all of them. I have experience and expertise in this domain so I understood where they were viewing it as more complicated so I said maybe the actors are just something like “employees”, “supervisors”, “analysts” (to represent their department), and that would be enough. That didn’t seem to click, and I was told that wasn’t the problem they were trying to solve. Certain people met certain criteria that would cause them to be treated a certain way, that’s what they meant by role attributes. I suggested we brainstorm the list of “role attributes”, but each time I tried to visually represent them I was told that wasn’t how they worked.
So I took a step back and said I was going to unveil the rest of the EventStorming concepts, that it was going to be a lot to take in, but that we hoped this would provide a solution to the problem they were trying to address. We unveiled aggregates, policies, and read models. I explained how they all worked, and showed them the “picture that explains everything”. I said, “It sounds like these role attributes might be policies - whenever someone meets these criteria then something specific needs to happen?” - it turns out this is exactly what they meant, but again there was resistance to this new concept and too much brain fatigue for this to click and be effective. So I started asking more questions and we tried to represent role attributes in multiple ways (a tree diagram, mapping out the various attributes as if it were a database table, etc.), but nothing really landed. So in the end we just had a large discussion where we talked about the different types of people, how they are identified, what some of the ‘roles’ meant, and they seemed satisfied with the discussion and understanding, even if there wasn’t really a clear outcome that we could take away.
As we started winding down the discussion I had them start putting up red stickies for their biggest problems, I gave each person 3 problem stickies to mark problems. Discussion on other topics continued and at the next break I gave out 3 green “opportunity” stickies to each person to write down ideas to put up what they see as the best ideas or greatest opportunities for a future design. Then finally as they were leaving the room I handed out small blue stickies that I had drawn arrows on - 2 per person - so they could vote/pick their problem and point their arrows at the key problems or opportunities that they felt would be most important to address in the future.
I learned a lot from this session and overall I think it went well and I got a lot of positive feedback. There were certainly some hiccups and we didn’t get as far as I hoped we would or thought might be possible, but overall I think we had a good outcome of more knowledge sharing and understanding. Also I think a lot of the business partners thought the space was relatively simple or they fully understood it. I got the impression that seeing everything laid out in front of them, realizing there are gaps in understanding and how they do things today, and even areas that people weren’t sure how they work or how they are supposed to work, really helped them realize how complex this space is and that it likely will not be as simple or fast to modernize the processes and underlying applications as they thought it would be.
The more I work with EventStorming the more power I see that it has. The more flexible I realize it can be. And I’m starting to wonder about ways it could be used for employee onboarding, running retrospectives, and other activities. I’m a bit disappointed that I haven’t been able to take it all the way to the level of a process design or system modeling exercise, but maybe we’ll move into that in the future. I’d really like to see some of the modeling concepts like policies, read models, commands, and external systems get added in to better understand how that helps development teams build the software solution.