Inspired by a recent discussion in The Decision Model Group1, this month’s column focuses on the emerging role of decision models on Agile projects. While Chapter 6 of our book, The Decision Model: A Business Logic Framework Linking Business and Technology, introduces a connection between decision models and Agile development, The Decision Model Group takes it one step further based on recent experiences.
First, the Big Question: Agile and The Decision Model?
Agile development is an approach that evolves requirements and software through iterative deliverables. One of its principles is to deliver working software frequently, often through a series of two to three week iterations.
The Decision Model (TDM) is a model for the full and rigorous specification of logic.
Therefore, on one hand, a decision model contains a complete and rigorous set of detailed logic leading to a conclusion (normalized and analyzed to remove logic anomalies and tested against test data). On the other hand, agile development embraces changing requirements, preferring shortened timeframes to software delivery.
Do They Belong Together?
This is exactly the question raised in the LinkedIn group and addressed generously by people with experience. It turns out that The Decision Model and Agile development are perfect together. There are flexible options for agile delivery of decision models of all sizes and complexities.
What People are Asking
The discussion started with the following statement from a popular participant in the group, Nick Broom:
Suleiman Shehu suggested, “There is a very interesting white paper at KPI website called FirstSTEP, Accelerating and Perfecting Requirements which outlines a methodology for developing all the functional or business requirements in a series of iteration for developing all the required models (including The Decision Model) together with an iterative simulation/ visualization of all the scenarios using a product such as iRise.”
Another participant is also moving into the world of iterative development, including decision models:“The developers have since changed their development approach to building ‘skeletal’ code, and will add functionality over time. Because of the more agile approach we just today came to an agreement with our developer friends to model in a ‘skeletal’ way.”
Four Recommendations for Decision Models in Agile Projects
The experiences shared in the group range from a very large complex project, to one using decision models as rules engine templates, to one in which decision models serve as analysis tools, and to projects in many different industries.
Below are four important recommendations that arose within the discussion group, along with related experiences.
Recommendation #1: Recognize that not every decision model fits into one iteration.
As pointed out earlier, a decision model stands behind one task in a process model. This suggests its development will fit within one iteration. However, some industries and processes have more complex decision models than others. When this is the case, the skeletal decision model provides insight into how to break it into segments.
Related Experience
Nick Broom shared the following as an example of real-world experience:
Given the complexity of the model, it could not have been delivered in its entirety within one iteration, suggesting that ‘Calculate Fund Value at Death’ is actually an epic story, not a true user story. If I truly wanted to ensure that I could analyze and subsequently deliver these rules within single iterations, I need to break this down into smaller stories.
Therefore, if I break it down further, it may be sensible to break it down in terms of fund type. So my user stories might be ‘Calculate Inflation-Protected Guarantee Fund Value at Death’, ‘Calculate Moneyback Guarantee Fund Value at Death’ and so on for each fund type. So in the same way as code would be iterated for each subsequent story, so would my Decision Model, but fundamentally, the complete model is not delivered within a single iteration in this example.”
Recommendation #2: Use the skeletal decision model as the foundation for agile development of decision models.
Experienced agile decision modelers recommend creating skeletal decision models as early as possible, such as during scoping, a proof of concept prior to agile scrums, or model storming.
Larry Goldberg explains, “A skeletal decision model is simply a high-level guess at what the model may contain.” Therefore, this means a skeletal decision model is a decision model diagram (visual representation of related Rule Families) that you create before you populate its Rule Families. At the highest level, it may contain only the conclusion fact types for the Rule Families. These may be all you know. At a more detailed level, it may contain all condition fact types for the Rule Families if you invest the time to guess at these. A hybrid skeletal decision model is sometimes useful. This is one for which you populate one or more Rule Families to gain a better understanding of their complexity and, more importantly, how they reveal more of the decision model structure.
Whether high-level, detailed-level, or hybrid, a skeletal decision model, you do not need to know all of the detailed logic to take a guess at its initial structure.|
Related Experience
Kathryn Clarkson in the group shared the following real-world experience:
Larry Goldberg, whose decision model experience includes insurance, finance, mortgage, logistics, and others, shares his own experience: “Typically we complete a skeletal model before we start creating the detailed Rule Families to help us understand the approach we wish to take with a particular Decision Model, and this is often done for the critical Decision Models during the scoping step of the project.”
Recommendation #3: Divide complex skeletal decision models into segments and assign segments to iterations.
Let’s look at a simple example for one way of dividing a skeletal decision model into segments.
Using Figure 1 as an example, the decision is “Determine Student Financial Aid Eligibility.” Apparently, there are three types of financial aid as indicated by the condition fact types in the Decision Rule Family. These are scholarship, loan, and work-study program. Because each of these conditions appears in the Decision Rule Family between the solid and dotted lines, each of them has a supporting Rule Family. Therefore, the skeletal decision model in this figure has three corresponding branches. One branch contains only a supporting Rule Family, another contains a supporting Rule Family and one below it, while a third branch contains a supporting Rule Family and two below it.
This kind of structure is common, especially in very complex decision models. A very complex decision model may have many branches. Alternatively, it may have only a few branches but each branch may contain many levels. In such complex decision models, the branches exist because the conclusion for each one derives from logic that differs from the conclusion for the others. The logic may differ by the quantity and depth of the branch of Rule Families and may involve different fact types as conditions. As is often the case, each branch represents a logical business subset, such as one kind of financial aid package, one type of investment fund, one kind of loan program, or one type of insurance policy.
Therefore, a natural way to divide such a skeletal decision model among iterations is to assign each branch as a whole to an iteration and assign the entire decision to yet another iteration. For this figure, this kind of division results in four iterations and four User Stories: one for scholarship, one for loan, one for work-study program, and one for the decision in its entirety.
Figure 1: Partial Skeletal Decision Model Divided and Assigned to Iterations
Related Experience
Larry Goldberg shared the following real-world experiences:
Recommendation #4: Determine how far you really need to develop each decision model segment or full decision model.
An innovative approach is to deliver skeletal decision models in one iteration that will serve as the template of fact types behind a decision. Populate these with detailed logic in a (possibly much) later iteration.
Related Experience
Kathryn Clarkson shared a real-world experience related to this recommendation.
Five Steps for Building a Skeletal Decision ModelSince a skeletal decision model is a useful technique in Agile projects, this section explains how to build one.
Step 1: Identify a business decision for a decision model
Start by selecting a business decision. Create an octagon to represent it and create the Decision Rule Family, which at this point contains only the conclusion fact type.
For our example, let’s use the decision to “Determine Person’s Likelihood of Defaulting on a Loan”(Figure 2).
Figure 2: Decision Icon and Decision Rule Family
Involve the business right away. Lead them in contemplating fuzzy ideas about the conditions that should play a role in the business decision. This may involve facilitated sessions, legacy code inspections, interviews, or document reviews. Place these fuzzy condition ideas in the Decision Rule Family. For now, place them below the solid line and above the dotted line. It is helpful to indicate them in red because they are merely fuzzy ideas at this time.
For example, our business experts propose two fuzzy conditions behind the business decision to “Determine Person’s Likelihood of Defaulting on a Loan.” These are employment history and a combination of mortgage and other debt. See Figure 3.
Figure 3: Decision Model with Fuzzy Ideas for Conditions
Explore the fuzzy conditions by asking business experts to explain them further. Determine which are likely to have a supporting Rule Family. Create appropriate supporting Rule Families.
For example, our business people believe that Employment History will need a supporting Rule Family. Therefore, Figure 4 adds that supporting Rule Family. The business experts also want to separate mortgage debt from other debt. This is good news because a data professional points out that a Person’s Mortgage Situation and Person’s Miscellaneous Loan Assessment are data elements used in existing systems. Figure 4 shows them below the dotted line in the Decision Rule Family.
Figure 4: Two Supporting Rule Families
Continue conversations with business experts to modify the fuzzy conditions, refining them until they are tangible. Decompose them, name and define them, along with domains. Reuse fact types already in the community glossary, wherever possible.
Depending on the project, it may be important not to limit these to data elements in data models, databases or other electronic form. This is true if the project is to include all condition fact types the business decision needs, regardless of whether they are physically available.
Add these fact types to the appropriate Rule Family. If no one knows yet if their values are available in persistent data storage, they belong between the dotted and solid line.
For example, our business experts decide that Employment History is determined by Person’s Years at Current Employer and Person’s Number of Jobs in Past Five Years. The data professional points out that these exist as persistent fact types, so Figure 5 shows them below the dotted line in the correct Rule Family.
Figure 5: Refined Condition Fact Types
Repeat steps 2-4 until you reach a level in the decision model where all condition fact types are below the dotted line. This means there are no more supporting Rule Families.
Wrap UpSkeletal decision models are important deliverables whether your project is Agile or not. Skeletal decision models help business people focus on the bigger picture of the criteria needed to make a decision not the details. In this way, skeletal decision models elevate the practice of business rule management to the strategic practice of business decision management.
However, in Agile projects, skeletal decision models play an additional role. They are the basis by which you can assign them (or pieces of them) to specific iterations in ways that make business and logical sense. Yet, this is just the beginning of their value.
Skeletal and populated decision models become living business artifacts. It is through these that the business can continue to envision, accommodate, validate, and test business logic changes over time.
“Business people easily recognize that business value is not found in the individual business rule or business logic statement, but in entire business decisions. Therefore, entire Decision Models (even without details) emerge as the asset that drives toward business objectives.” (von Halle and Goldberg, 2009).
Reference:
- All readers are invited to join the LinkedIn Group called “The Decision Model.” In this group, you can ask questions or simply listen to what people and organizations around the world are doing with The Decision Model.
