Discovery & Delivery
In the discovery, we decide what to build, whereas we build, ship, and maintain it in the delivery phase.
In the Discoveryphase, we do discover the following:
the value (business value)
how the user will use it (usability)
if we can build it (feasibility)
if stakeholders can support it (viability)
As Marty Cagan said: "Discovery is very much about the intense collaboration between product management, experience design, and engineering."
There are many discovery techniques worth mentioning: Wardley Maps, Impact Mapping, Product/Lean/Startup Model Canvas, Context Maps, User Story Mapping. Here, however, we'll focus on Event Storming & Event Modeling.
After we know what to build, we need to deliver. That is when engineers implement, test, and deploy the solution. The solution must provide the insights that are the base for understanding if we have achieved key results. With Event Modeling, we can glue it all tightly with the discovery phase and streamline to extremes. Before we get there, we need to prepare the grounds, so let's go top-down.
| Phase | Modeling Technique | Building Blocks | Subjects |
|---|---|---|---|
| Discovery | Big Picture Event Storming | Events, Hot spots, Systems, People | Goals, Conflicts, Boundaries, Risks |
| Discovery | Process Event Storming | + Commands (Intentions), Views(Read Models), Policies, UI | Value, persona, business dependencies |
| Discovery & Delivery | Event Modeling (low and high fidelity) | + Swimlanes, Scenarios, Extensions: UX, Insights, Delivery, Planning | Software model by example that asserts usability, feasibility, value proposition & viability |
| Delivery | Design Event Storming | Everything in Process Storming + Aggregates, Business Rules | DDD model of software |
As you can see, some work must be done before Event Modeling and after. It is not a golden solution for everything.
How does Event Modeling glue Discovery with Delivery and vice versa?
The key ingredients of Event Modeling are single timeline stories that are visualized with easy-to-understand building blocks. Events and UI screens/mockups are part of them. They arrange the story in a sequence of frames - slices. It allows all participants (Product Managers, Designers, Tech Leads) to discuss and design a particular storyline. Once finished, it turns out that the design will correspond directlyto the source code. As a result, testing, implementation, and deployment become repeatable and entirely predictable.
After delivery, we need feedback: How can we know if we have succeeded? What events must occur, or what metric needs to change to genuinely say that our ideas worked well? Since we have a blueprint of our storyline that mimics our code, we can quickly point out which parts of our system should behave accordingly. So after running in production, we should know how well or bad our ideas turned out to be. The data gives us the proper feedbackfor the next iteration. As it is visualized, it becomes the magic glue that everyone on a team understands.
You can read more about: