>
Software developers are often obsessed with terms precision . This is remarkable because ambiguity does not compile and doesn't pass tests either .
However, there are situations where this obsession for precision might get in the way of a successful conversation:
-
In a Big Picture EventStorming , the different perspectives must clash. Enforcing precision too early in the exploration phase might exclude interesting dissonant voices from the conversation.
-
Adherence to a specific conceptual model upfront will exclude what's not part of that perspective, which can be relevant.
-
The distinction between a User and an Actor or a Persona isn't really that interesting. There are better topics to discuss during an EventStorming.
-
Choosing a specific model/notation will also favour one party over another one.
Clearly state that you won't provide precise definitions on purpose , and the goal is to include different viewpoints in the same conversation. The assumption that definitions must be precise is widespread, so you need to state that rules are different here.
The agreeable sentence "Ok, but we have to define what an actor is" could be addressed like: "Sure, we will!" But now there are more interesting things to do.
However, if clashing interpretations increase the pressure for a clarifying definition, then make both interpretations visible: maybe you're just discovering that you have two equally valid concepts behaving differently in that given portion of the flow.
During the workshop, I'll let a visible legend be the explicit reference for the current meaning of a piece of notation. At the same time, I'll try to dumb down the language up to the "we need a blue one after a lilac one" instead of the more precise "we always need a command as a consequence of a policy" .
Having a simple example as a reference is usually more effective than a precise definition, but keep in mind that a single example will never cover all corner cases.