The Agility Series — 6 — Cure Translations & Save Big
I am going to describe something that happens all the time, preventing agility in software, wasting money, and frustrating Product Owners, end users, developers, and the business just because there is no one with their eye on a certain ball.
Understand this, use the technique, save money.
It is that simple.
I was in a client working through a particular issue. The business needed to track a process in their flow called an “increment”. Years earlier, the team took the stories written and implemented the feature with the ability to track an “increment”.
The solution kept working as long as it did not have to process a couple of key use cases. They noticed the algorithm functioning in such a way that the intended outcome would fail every time there was a user using the system with certain conditions. Conditions that stretched the limits of the definition of an increment.
Turns out the business definition of an increment of process had that increment starting far earlier than the technical staff implemented. The business definition of an increment ended later for the business than tech thought as well. SO, for the implementation, the tech awareness was driving the design rather than the domain itself.
This went on for about 3 or 4 years because the business thought technical staff had the business definition. The technical staff thought the business had the technical definition. It is a hidden missed translation. Unhide these, and you can save a bunch of money on your car insurance. (This was not for an insurance company!)
Then I came along. Someone told me there is this unsolved mystery. I love these. At work, I live to solve software issues no matter how they started, who started them, or how impossible they are to solve. The more difficult it is, the more I get energized. I just know, from experience, I can resolve these issues.
To begin the process, I went to the Domain Experts, often called Subject Matter Experts (SME), and took the time for about 2 days to work through the flow. I laid down all the potential events, the way they triggered one another and what those events meant to the increment. I then went to the tech team and asked them to map their events with me. They gave me a map that almost made the same sense as the business, but there were about 3 disconnects between the definitions from business and technology.
Once I figured those out, then I need to determine which parts of the current system are acceptable as they are, which are inaccurate, and which don’t exist in the way the business needs them. It turns out, the original solution missed the mark so badly, that a rewrite of that subsystem was required to get the business benefit of the feature the way the Domain Experts explained is required if they were going to help their profit margins.
All along the way, there was infighting, cross team fighting and stonewalling. I won’t go into those specifics, but I highlight it as a symptom to look for. If the teams are not getting along, it is time to look at a deeper misunderstanding.
Leveraging all of the knowledge gained, I proposed a system that was both technically feasible, even if it required a considerable reengineering effort, and satisfactory to the business to gain the benefit of tracking this increment of business flow.
The Tactic In Short
- Eventstorming The Domain: Eventstorm the intended process with the domain experts. In this case we need no other people in the room. No distractions. No angry developers. No other person other than the people who know exactly what the software should do.
- Eventstorming the Technology: Eventstorm the actual implementation as it is currently. No Domain Experts. No developers guessing. Just the ones who know exactly how the software is actually working (or not!).
- Ask the Domain Experts what they think of the technical representation. Note the required changes.
- Ask the Technologists what they think of the Domain Representation. Not the required mods
- Create a cooperative version by blending the right elements of the two.
- Present the solution in a working meeting. Explain to everyone the backstory and what has happened to get us to this point.
- Sell the final solution and request a final design session to make the functional model.
- Present the model to Domain Experts and explain it.
- Implement the working solution that really meets the needs.
And there you have it. You can save money by eliminating the translation layer, one that is often in error. Take time to learn what the Domain needs. Let Domain-Driven Design (DDD) work for you. It’s not hard, just takes a little effort to save a bunch of money.
