Capture Activities and Steps
This is a continued blog post series you can find the first post here.
Chapter 4 simply continues the 7 step cycle in the ADDR process, presented in earlier chapters. For each job story we go into details and define each step that needs to be performed in order to full fill the outcome of a digital capability. And notice that it becomes clear that a digital capability can contain multiple steps.
To clarify. You Identify activities for each job story. You then define steps for each activity.
Event Storming
In Event Storming you place business events as stickie notes on a timeline.
The important thing here is to have a conversation. Event storming helps here, since you visualize what you are talking about. The chapter gives a concrete examples and concludes that a real world team managed to identify several things missing from the specification during the event storming session.
Event storming get’s explained. Also detailed instructions how to facilitate an event storming workshop are provided. The chapter spends a good amount of effort to explain this including tips and variants that the author has found useful. If you don’t know event storming this is a really good introduction.
Another useful resource is https://github.com/ddd-crew/eventstorming-glossary-cheat-sheet
Some Advantages of doing an event storming session are listed:
- Shared understanding of requirements and scope of the problem being modeled
- Shared understanding of the workflow processes, business rules, and constraints
- Establishment of a shared domain vocabulary, replacing multiple terms with a ubiquitous language
- Identification of unknowns that require follow-up and clarification prior to software design and development
- Identification of boundaries within the solution, useful for scoping team efforts and division of labor to minimize cross-team dependency coordination
- Prior to API and microservice design and implementation to help establish outside-in design thinking
- Prior to software design and development to clarify assumptions and address open questions
- After clearly documenting desired outcomes, typically through the use of job stories, discussed in Chapter 3
- When all roles are represented in the session
- When embarking on a significant scope of effort or one that spans multiple teams
When is event storming not effective:
- The business process is well known and documented, as results will likely produce the same insights.
- The scope of the problem is small enough that the identified business requirements are sufficient and complete.
- The business requirements have not yet been identified. In this case, start with constructing job stories, covered in Chapter 3, to clearly define the desired outcomes and parties involved.
- Business stakeholders cannot attend or do not see value in the exercise. While development teams may still conduct a session, doing so may lead to modeling a process based on too many technical assumptions that do not meet business needs.
- Software delivery has begun, and delivery dates are fixed. If the teams are early enough in the delivery process, the output of the session may be used to make software architectural and design adjustments prior to a release. Otherwise, teams will be forced to proceed with existing decisions rather than the insights obtained through an Event Storming session
Why is visual Collaboration helpful?
Above image from Jeff Patton illustrates this.
We thought we agreed. But when visualizing things we realize that we didn’t.
Therefore: Do some kind of visual collaboration. Jeff Patton’s User Story Mapping or as suggested by James: Event Storming.
Notice that event storming is heavily inspired from User Story Mapping.
When you need to go into more details including talking about specific business processes, at this level I would recommend the process level event-storming format. If there is a situation where it s a domain expert that has all the knowledge and not so mush the developers. An interview style event storm can be a good choice. This means you compromise on the original event storming format where every one adds stickies on the canvas.
In the interview style event storm, a facilitator interviews the domain expert and at the same time adds stickies to the canvas. The facilitator can also chose to get help from a person who act as a modeler, who add the stickies.
Going Deeper
In case you need to work out specific business rules or multiple examples a useful technique is example mapping. Here you clarify what is going on with concrete examples.
This is common practice also taken from user story mapping. Example mapping is often suggested as an additional add on to enrich event storms and event model’s. Example mapping looks something like this:
Its recommended to agree with a Domain expert up prepare examples up front. Its a good opportunity for other people to ask questions.
Summary
We are in the alignment phase of the ADDR process. Visual Collaboration tools are recommended. Specifically Event Storming.
The tangible out put of this process step is a table capturing Activities and steps.
Given the reader has time I would recommend reading Jeff Patton’s book “User Story Mapping” as a supplement to knowing event storming. Also Event modelling is a promising technique to supplement the ADDR process in some way.
