I’ve run numerous workshops in recent years. It’s intriguing to see different ways people solve the same problem. Some start from general vision and go into details, some the other way. Each approach has advantages and disadvantages. I want to share some conclusions based on my practice and how I work with modelling, design, etc. The first stage of working with a completely new functionality is the creative stage. We don’t know much about the problem and tooling stack. We find dots and connect them. A suitable method here is good old brainstorming. Here are a few rules for making it effective: there are no stupid ideas, we don’t criticize; we focus on our ideas, not other people’s, we generate as many ideas as possible, when we run out of ideas, we should still try to grind a bit longer and tell ourselves to generate 2-3 more. It’s like running; often, the best results occur when we pass the first fatigue threshold, however, it is important to set a maximum duration for brainstorming. It should be an intensive and productive meeting. There’s no point in making it an endless one. You can always organize several sessions. That is why tools such as EventStorming, Event Modeling and other sticky-notes-based tools are so popular. They allow us to throw our ideas onto the wall, crunch them and stimulate discussions. Having a good mixture of people at such a meeting is essential. We should have people of all sorts: programmers, business people and testers. We’re discussing the general vision at the early stages here, so every perspective counts. Yet, it’s also essential to not have too many people and care for mental health. Doing continuous brainstorming sessions can be draining and ineffective. We need to let our thoughts sink in. I’m personally an introvert, and I’m emotionally exhausted after a set of longer sessions and need time to recover (read more in Agile vs Introverts). Thus, after brainstorming, it is worth sifting out what we have found. We should group ideas by category. Even if some look like duplicates, discussing them before we throw them out is crucial. Often, such details contain grey matter, so details that can have a significant impact but are easy to miss. The brainstorming itself may concern specific functionalities as well as the global vision of the system. EventStorming divides this into “big picture” and “process/design level”. First, we look at the events that are essential from the overall system perspective, then we go lower (read more about the distinction between internal and external events on my blog: “Events should be as small as possible, right?”). Although the “big picture” indicates that in EventStorming, we move from general to specific, we also go the other way round. The starting point is finding events; they are granular and precise by definition. We’re shaping the business workflow by grouping and placing them in order. We can also find boundaries, language nuances and define bounded contexts. Having that, we can go down the rabbit hole again, breaking down processes int
