The conceptual model for Disciplined Agile® (DA™) is shown in Figure 1, using a notation based on the Unified Modeling Language (UML). As the name implies, a conceptual model depicts major concepts and the relationships between them within a specific domain. The DA domain concepts are depicted as boxes and the relationships between them are depicted as lines. The cardinality of the relationships are depicted on the ends of the lines using common UML notation such as 1..*. Given the nature of the DA tool kit, the model shows how concepts in DA (the left-hand side of the model) relate to concepts external to DA (the right-hand side).
Figure 1. The DA conceptual model (click to enlarge).
The best way to understand DA’s conceptual model is to start with an overview of the concepts:
- Process blade. A process blade encompasses a cohesive part of your overall organizational way of working (WoW). Each process blade addresses a specific organizational capability, such as Data Management, Continuous Improvement, or Vendor Management. Process blades are sometimes called process areas, key process areas (KPAs), or business functions.
- Process goal. The DA tool kit takes a goal-driven approach (some people like to call this a capability-driven approach or even a vector-driven approach). The purpose of DA’s goal-driven approach is that it guides people through the process-related decisions that they need to make to tailor and scale agile strategies, given the context of the situation that they face, to achieve the outcomes that they desire. Examples of process goals include Form Team, Accelerate Value Delivery, and Evolve Way of Working (WoW). Process goals are summarized by process goal diagrams. Process goal diagrams are also used to summarize the practices associated with process blades.
- Technique (DA). A technique is a practice or strategy, such as weighted shortest job first (WSJF), aggregate measures, and test-driven development (TDD). Techniques in the DA tool kit summarize techniques described in “external” sources, see below. Our goal in DA is to summarize each technique and to describe there tradeoffs, thereby putting them into context to enable you to identify which techniques are most appropriate given your situation.
- Additional resource. DA techniques will refer to sources of more detailed information, such as articles, books, and videos. These supporting references provide the details to learn a technique if needed.
- Technique (external). Techniques in DA refer to existing techniques – agile, lean, and traditional - that are captured by a wide range of sources. For example, Agile Modeling techniques such as inclusive tools & techniques, active stakeholder participation, and look-ahead modeling are referenced by DA. DA puts these techniques into context and Agile Modeling describes them in detail.
- Methodology. We apply this term broadly to include methods, frameworks, body of knowledge (BoKs), standards, and similar collections of related techniques and supporting ideas. Such methodologies include, but are not limited to, SAFe®, Scrum, PMI’s PMBoK Guide, ITIL, and many more. DA is a hybrid, putting techniques from a wide range of methodologies into context.
Now that we understand the key domain concepts, we can explore the relationships between them. To do so, let’s start with a technique on the DA side of the diagram. A technique will appear on one or more process goal diagrams. For example, active stakeholder participation appears on the goal diagrams for Address Changing Stakeholder Needs, Produce a Potentially Consumable Solution, Accelerate Value Delivery, Deploy the Solution, Intake Work, Enterprise Architecture, and Product Management.
A process goal will provide context for a given technique. For example, active stakeholder participation is applied by address changing stakeholder needs to explore an evolved requirement, whereas it is applied for validating a successful deployment in deploy the solution. As a result of these different contexts, the description for a given technique as well as the tradeoffs may vary between process goals.
In DA a technique overviews and puts into context techniques that are captured within methodologies. Note that there may be different versions, with different names, of a given DA technique. For example, in DA we use the term coordination meeting, whereas externally they are referred to as coordination meetings, Scrum meetings, stand up meetings, and daily stand ups to name a few. The challenge is that each methodology uses its own set of terms, and that there isn’t a standard set of agile terms as a result. In DA we strive to use clear, pragmatic, and agnostic terms wherever possible.
An external technique will be part of zero or more methodologies. Coordination meetings appear in several methodologies, hence the plethora of names. Some techniques did not originate in a specific methodology, mob programming being an example. Then again, some people will argue that mob programming is a methodology in and of itself. Regardless, in DA we consider it a technique, and a surprisingly good one at that.
April 2022