I spent some time today mapping out the similarities and differences between Value Stream Mapping and EventStorming. It's remarkable how similar they seem, and I think the way I've been doing VSM is very close to an EventStorming approach. I don't think you could go wrong with either one, but there are several key differences that will dictate the right tool for the job in any situation.
EventStorming, as you'd expect, is about events. It's also centered on the concept of queuing and its effects. That's a very different focus from Value Stream Mapping's emphasis on measurement, quality, and value. Where they converge, is a shared focus on flow.
In cases where an organization is just starting out, I think the best recommendation I'd have is to use whichever term and approach seems to resonate best with key sponsors and leadership. Use what will get results, leverage the path of least resistance, build momentum.
|Value Stream Mapping||EventStorming|
|Delays||Measured||As queue S/M/L|
|Symbology||Simple to complex||Simple|
|Orientation||Default Left to Right||Default Right to Left|
|Areas identified||Hotspots||Hotspots, Bounded context, Subdomain|
|Extensions||Tools, Artifacts, Data flow||Read model, Aggregate, External system, Policy|
|Focus||Work/Quality/Value flow||Software event flow, queuing|
|Sequence||Current state, Ideal state, Future state||Current state, Issues, Questions|
|Scope||Org to Team||Domain to Application|
|Levels||Ecosystem, Org, Release, Sprint, Process||Big picture, Process modeling, Software design|
|Parent||Lean Process Modeling, 1920+||Domain-Driven Design, 2004+|
|Superpower||Visualized and improved work flow and performance||Visualized event flow and complexity|