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 | ||
| Data | Y | N | |
| Method | Qualitative/Quantitative | Qualitative | |
| Delays | Measured | As queue S/M/L | |
| Symbology | Simple to complex | Simple | |
| Orientation | Default Left to Right | Default Right to Left | |
| Roles/Actors | Y | Y | |
| Quality | Y | N | |
| Lead time | Y | N | |
| Rework | Y | Y | |
| Waste | Y | N | |
| Triggers | N | Y | |
| Activity | Y | Y | |
| Issue | N | Y | |
| Question | N | Y | |
| Areas identified | Hotspots | Hotspots, Bounded context, Subdomain | |
| Extensions | Tools, Artifacts, Data flow | Read model, Aggregate, External system, Policy | |
| Core unit | Activity | Event | |
| 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+ | |
| Software design | N | Y | |
| Market dynamics | N | Y | |
| Superpower | Visualized and improved work flow and performance | Visualized event flow and complexity | |
| Resources | iSixSigma | awesome-eventstorming |
Fascinating comparison; I need to try Event Storming!
The difference in quantitative aspects seems fundamental. Are you saying a software VSM may not need as much quantitative focus as you'd expect traditionally?
Sorry I missed this initially Brice! I think there's value to quantifying wherever possible. The reason so many value stream issues persist is a lack of introspection, analysis, and measurement - so I doubt the cure is an approach that doesn't involve empirical data. But yes, I don't think a VSM needs a lot of data and detail to be valuable, and you can always adjust the scope of mapping to when you start seeing diminishing returns.
Another factor is that this comparison puts traditional VSM against Eventstorming, but almost nobody uses traditional VSM in software. My approach, for instance, is a hybrid between VSM and Eventstorming leveraging the strengths of each. I think Eventstorming is a bit too focused on software and UX to use it as a tool for workflow improvement, and the lack of timing reinforces that. It's a tool to visualize event flow and complexity, but not work flow and performance.