(This was Issue #14 of my weekly āEvent Modeling & Event Sourcingā Newsletter)
This time we are neither talking about Event Sourcing, nor are we talking about practical Event Modeling - we are talking about how Event Modeling can help your team with minimal effort from your side.
Before that! Big announcement for me. The course āImplementing Eventsourcingā is now live.
We go through the whole process described in my book āUnderstanding Eventsourcingā - lecture by lecture.
There will also be a discord to discuss, learn and grow.
How I wish I had this bundle (course + book) 5 years ago.
Also there is a new full chapter āHandle the organizationā in the Book - just released! Iām constantly adding new chapters in my āMissing Chaptersā Initiative.
The Common Objections
Talking about Event Modeling, what I hear often is, āour developers donāt have time to move stickies aroundā.
By modeling the system, āwe do all the work twiceā.
Adjusting the model for each new requirement, āthat simply takes too much timeā
āOur code and our model constantly run out of syncā
We tried Event Modeling, āit simply doesnāt fit our use case. We are different.ā
Is this your Team?
I completely get it. Youāve heard about Event Modeling, maybe youāve even tried it, but it simply feels like too big of an investment. You got all these deadlines looming above the team. No time to try something new with an uncertain outcome.
But how can you still benefit from Event Modeling? Even without all this upfront investment?
Listing the benefits, it still is appealing.
More accurate software plannings Clearly described requirements - no questions asked in development effective software slicing - allows parallel work without stumbling over each other all the time (merge conflict hell.. anyone?)
Event Modeling isnāt an āall or nothingā approach. Just start small.
Here are a few things I would recommend starting today.
And just to make it clear - the tool you use for Event Modeling is not important - if Miro, consider my Miro Tooling, if your company does not work with Miro - start with drawio
Prepare Refinements
Use Event Modeling to streamline your Refinement meetings. At its core, itās a tool to enhance communication and collaboration.
Have you ever sat through a Refinement where someone opens ticket after ticket, expecting you to estimate each oneānumbers that you might later be held accountable for? Instead of getting stuck in this cycle, take a different approach: model each ticket step by step before the Refinement. This takes just 10ā15 minutes but makes a huge difference.
By attaching a modeled flow to each ticket, you can quickly review it and focus on open questions (typically marked with a red sticky note). This way, every Refinement Meeting starts on a completely different noteāwithin a minute, everyone is up to speed and ready for a focused discussion.
Discuss User-Stories
Use it as a discussion tool - we are doing something called āQuick Designā in most projects.
Before a story or a feature goes into implementation, the developer quickly presents the technical solution to the team or a group of interested developers.
Itās like a quick peer review that helps identify blind spots and distribute knowledge.
Make meeting notes
There is literally no meeting where I do not have a Board open taking notes in the form of an Event Model.
Whenever a meeting gets stuck, I can share my screen and just ask āIs this what we are discussing?ā Best thing that can happen is, someone steps in and corrects my understanding.
We are right back in the discussion - but with even more focus and clarity. And everybody is back on track.
Build Documentation one flow at a time
Ever wondered how to document your system and your flows?
Instead of writing endless text and diagrams in confluence pages, just model every feature in a few minutes on a high level, so that everybody can get a five minute summary if interested.
One thing to try - Build common understanding using āByte Size Architectureā-Sessions
Event Modeling is a perfect combination to āByte Sized Architecture Sessionsā.
The idea is simple.
Schedule one session per week.
Pick one part of the system.
Let everybody model it on their own - itās perfectly fine to make mistakes or model it completely wrong. Make sure nobody sees the diagrams of others.
The Goal is to get a high level overview of how the team currently understands the system. This is how you find misconceptions and wrong assumptions. Itās crazy how often there is a completely different understanding of a system even within a team.
After that, model the final flow at the end together. Event Modeling works great for this.
Goal is to have one small part of the system modelled and documented after each session.
Sometimes itās good to have a facilitator to run these sessions - I can help you with this. Just answer to this E-Mail, letās have a chat how that might help.
Weāll record a new episode of our āEvent Modeling & Event Sourcing Podcastā every sunday.
Want to work with me?
Join the Weekly Event Modeling & Event Sourcing Updates, so we can stay in touch.
Iām looking for Teams that want to try Event Modeling in a safe environment. I want to work with them for one day on a concrete domain problem in a workshop.
The goal is to find out, how your Team will benefit from the structured communication Event Modeling provides.
If your Team could be a fit - just quickly reply to this E-Mail. Iām looking forward to hearing from you!
Martin Dilger
Join the Agentic Engineer Program
Apply Spec-Driven Development Hands-On - Event Modeling, Event Sourcing, and AI Engineering with autonomous agents.
Book a Call Today
Want to talk through how Event Modeling could work for your team or project? Letās have a quick, no-pressure conversation.