Organization refactoring: Event Storming and DDD injection - part 2
The key to successful DDD and Event Storming injection is to wait for the perfect challenge. Otherwise, we’ll have no choice but to hack the organization!
This post is the second half of the story. If you haven’t already, start by the beginning!
3. Look out for the next business challenge
To convince domain experts to join an Event Storming, you’ll need to highlight what’s in it for them!
💡 Remember 1st rule of DDD: Don’t speak of DDD. Wait for the good business challenge to suggest Event Storming.
Don’t try to sell the technical benefits of DDD. Instead, wait until you spot something that Event-Storming could help domain experts. That’s the best moment to suggest a workshop to fix their problem. Here is a non-exhaustive list of problems Event Storming is very good at:
- What will our next increment be?
- What prototype should we build to de-risk Non Functional Requirements?
- Should we organize as feature teams or component teams?
- What are the bottlenecks in our way of working?
- What architecture should we use to maintain our competitive advantage?
- Should we build or buy this component?
- Should we rewrite or refactor this component?
The trick is to highlight that it is only 1 or 2 intense days to get the great answer they need. The alternative is to go through many email exchanges and one to one meetings. It usually takes weeks, if not months, to make a very average decision. Compare the 2 alternatives to make the value of Event Storming obvious. Don’t let availability be an issue; be open to accommodate people’s schedules. For example, you can split the workshop into 2 hours slots over a few days.
You might not convince them the first time 😞
Sometimes, by losing a battle, you find a new way to win the war.
If they chose the emails and meetings path, keep notes of what happens. Try to keep track of all the meetings and email exchanges that went into the decision. Measure how many days it took to reach a consensus. If you can, measure how valid the decision was (or not). At the next business challenge, suggest Event Storming again. Show what happened last time. Be patient; time plays on your side.
Other strategies
That’s how we brought Event Storming at Murex. From hesitant first tentatives, it has become one of the architects’ main tools.
Barry Sullivan suggests a similar strategy in Introducing DDD to your Company.
💡 Event Storming is viral. Yesterday’s attendees are tomorrow’s organizers :-)
Unfortunately, sometimes, domain experts remain out of reach. The Paris DDD Meetup went over this question in DDD From the trenches. People came up with corporate hacks:
Seduce an expert
- With a burning question
- Bribe them with a free lunch or their favorite chocolate
Fake it till you make it
- Bring in another expert somewhere
- Buy a book and play the expert yourself
The Trojan horse
Do you remember Bastien, who asked the question in the first place? You might be wondering how he managed in the end?
The latest news I had was that he used a hack of his own too! We could call it the Trojan Horse hack. A developer moved position from dev to product. He became the perfect entry point to the domain experts 😉
Get started!
DDD has a lot to offer:
- happy users
- more maintainable systems
- fewer bugs
- faster evolution
- a more sustainable pace
Event Storming is excellent at injecting DDD in your organization. Unfortunately, asking domain experts to spend 2 days in a workshop won’t work. Still, with some practice, preparation, and patience, you can get your domain experts on board!
Start practicing today! Here is the guide.
Leave a comment