Essence was created by the Software Engineering Method and Theory (SEMAT) community and approved by The Object Management Group as a standard in 2014. The basic of Essence is that “provides the common ground for defining software development practices” (see [R1-ES]) and also is intended to build and maintain an open library and marketplace of software engineering practices and education materials (see [R3-SMMS] ).
Essence is important, (see specification [R1-ES]), because:
- “Provide a common base that is useful for software engineering endeavors of all sizes (small, medium, and large)”
- “Enable method building by the composition of practices, so that methods can be quickly assembled by a project team to match their needs, experiences, and aspirations. Allowing the method to start small and grow as needed”
- “Support method agility, so that practices and methods can be refined and modified during a project to reflect experiences, lessons learned, and changing needs”
- “Support scalability including from one product to many, from one team to many, and from one method to many”
In this article I show how to describe DAD Essentials. Essentializing DAD is different from similar endeavors because Disciplined Agile (DA) is not a prescriptive method/framework like Scrum/SAFe. Instead, DA is a toolkit based on similar goals as Essence in that it is generative – both provide building blocks from which you can tailor and evolve a process that meets your needs.
The role of this Essentials is to provide an overview of the DAD guidance and over the capabilities that could be developed for each significant aspect (“Alphas”) of an Agile & Lean process. What is really happening on Agile/Lean adoption (and in any process improvement) is developing & exercising of new capabilities. What is specific to Disciplined Agile is that it provides guidance for developing the capabilities that team & organizations needs for their specific context.
DAD Essentials are presented here in cards format using the OMG/SEMAT Essence Language constructs as Alphas, Patterns, Resources, Activities, Work Products (see Glossary section below). Each “card” has a name, a description, and a list of capabilities for your team or organization to develop.
The following terms are used in Essence.
|Alpha||An essential element that is relevant to an assessment of the progress and health of the software engineering endeavor.|
|Patterns||A generic mechanism / complex concepts that are made up of several other elements|
|Resources||A source of information or content.|
|Activities||One or more approaches for carrying out some work to be performed and can recommend actions on alphas and/or work products in order to and relevance this work.|
|Work Products||An artifact of value and relevance for a software engineering endeavor.|
|Full delivery life-cycles|
Full, beginning-to-end, delivery life-cycle it is an explicit representation of how a software release will progress in time. The pragmatism and effectiveness of Agile (<> Waterfall) are based on realistic progress milestones with the evolution of working software toward a consumable solution. A team could have a reference lifecycle, but in a different context, they may need to use also other types of life-cycles.
Capabilities to develop:
- A reference life-cycle
- Support for Iterative-Agile, Lean, Continuous Delivery life-cycles
- Support for high incertitude deliveries
- Support for long term roadmaps (product, business, technology)
Consumable solution is more than working software. Consumable means that we meet stakeholder needs in the context constraints and it is usable, desirable, and functional. A solution implies that, as needed, we:
- Develop high-quality software
- Provide new or upgraded hardware/platform
- Change the business/operational processes which the stakeholders follow
- Change the organizational structure in which our stakeholders work
- Update supporting documentation
Capabilities to develop:
- Understand Consumable Solution
- Build using DAD guidance the Consumable Solution across life-cycle milestones, considering various life-cycle and practices options depending on context
|Adapt to Context|
DA supports two principles that motivate you to adapt your approach to your context:
- Context counts. People, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face.
- Choice is good. Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA framework presents people with choices through the application of process goal diagrams.
Capabilities to develop:
- Understanding Agile Scaling/Tailoring Factors
- Tailor WoW in context using DA Guidance
|Core Agile Practices|
Core Agile Practices will help you have a Lean process: they address the main sources of waste and have multiple benefits at the same time. It is not a coincidence that XP is based on some of them, Disciplined Agile and Agile Modeling refer them as critical practices. (See also references from Mary Poppendieck / Tom Poppendieck in “Lean Software Development”). Some core practices are:
- XP practices: Small Releases, Pair Programming, Simple Design, Refactoring, TDD, Coding Standards, and more.
- DA/Agile Modeling practices: Requirements/Architecture Envisioning, Architecture Handbook, Model Storming, Rolling Wave Planning, and many more.
- Method free practices: Clean Code/Architecture.
Interestingly, Essence describes in detail several dozen core agile practices in detail whereas Disciplined Agile puts several hundred agile, lean, and even traditional core practices into context. This is one of several reasons why Essence and DA are complementary to one another.
Capabilities to develop:
- Understand how and why you will eliminate waste
- Context usage: Core Agile Practices are not “best practices” and we still need to know the trade-offs and options for different context (See Adapt to Context alpha). Make experiments to see what works in your context
|Teal Teams and Organizations|
Optimize the whole: the Organization (and its constituents teams) represents that “whole” where the work optimization really makes sense. In Reinventing Organizations, Frederick Laloux presents the historical evolution of organizations from tribal to modern agile approaches:
- Red (Magic/Tribal): Impulsive, survival urgency
- Amber (Traditional/Agrarian): Authoritarian, formal hierarchy
- Orange (Scientific/Industrial): Task-oriented, profit/grow focus
- Green (Post-Modern/Information): Value-based, consensus/participative style
- Teal (Self-Organizing/Adaptive): Cellular organism with evolutionary purpose
Disciplined Agile use this model and propose as a goal the Teal organization (or at least Green): cellular, self-organizing, adaptive, aware, with evolutionary purposes. Most likely, your organization is a “rainbow” (e.g. Orange/Green/Teal). Context counts, different teams faced different situations and you can choose your strategy. You want to be at least Green because that will provide – through a participative & collaborative style – a solid foundation for further process improvement. Also, the DA Principle, Be Awesome has some expectations:
- Treat people with respect, honesty, be reliable and open
- Willingly collaborate with others
Capabilities to develop:
- Teams will offer psychological safety with clarity about roles and responsibilities
- Cross-functional skills teams, where T-skilled “generalizing specialist” is the most pragmatic, effective, efficient approach.
- Use collaborative work to envision, look ahead and just-in-time clarifications.
- Collaborative and continuous process tailoring and improvement, not only on retrospectives
- Inter-teams’ collaboration: Communities of Practices and Centers of Excellence, etc.
- Individual, team, enterprise and community level awareness
- Use pragmatic agile roles
- Address team and organization level scaling factors
|Guided Process Improvement|
The purpose of the Continuous Improvement process blade is to enable people within your organization to easily share their improvement learnings with one another in a systematic way. The technique of Guided Continuous Improvement (GCI) shows teams how to leverage the DA toolkit to speed up their process improvement efforts.
Capabilities to develop:
- Continuous improvement must be explicit and fundamental
- A base support for improvement should be running: life-cycles, collaborative work, retrospectives
- Kaizen strategy: continuous improvement should always be running in small steps and experiments. This lean strategy is fundamental for addressing problems complexity & incertitude.
- apply the DAD toolkit to adapt to context (see corresponding alpha) for process goals as: selecting a life-cycle, forming the team, addressing changing stakeholders needs.
- hire/listen experienced coaches
- make progress on adopting Core Agile Practices
- have explicit goal/guidance for Evolving your WoW
An Agile method such as Scrum, or a framework such as SAFe, can be a good start but it will have too few guidelines for choosing your way of working (WoW) in context or too little guidance for core Agile practices. DA provides the guidance for evolving your WoW and Essence the details regarding core practices. As Ivar Jacobson likes to say, this will enable you to break out of “method prison.”
|DA Principles||Delight Customers, Be Awesome, Pragmatism, Context Counts, Choice is Good, Optimize Flow, Enterprise Awareness|
|Agile & Lean Principles||DAD use Agile and Lean Principles intesively. Examples: Practices support and guidance, the Disciplined Agile Manifesto, Lean and Agile life-cycles etc.|
|Collaborative, Cross Functional Teams||Collaboration is a fundamental Agile and human value, and DAD supports that with several practices. Also, DAD promotes T-skilled “generalizing specialist” as an effective, pragmatic approach of cross-functionality.|
|Pragmatic Agile Roles||The DAD toolkit suggests a robust set of roles for agile solution delivery, roles that work well in real practice. DA propose also some secondary roles (less used, temporary or at scale)|
|Process Goals||DAD toolkit takes a light-weight, goal-driven approach to support adapt/tailor WoW to context. While process capabilities (goals) remain the same, you can use different choices and select different practices in a given context.|
|Scaling Factors||The context will permanently change and the Scaling Factors are significant aspects that will drive tailoring your element reflect the situation that you face.|
Guidance, Adapt to Context: Select Life-cycles
Solution delivery teams face different situations so one lifecycle will not fit all. DAD offers more options for Agile and Lean life-cycles and appropriate guidance:– The Agile Lifecycle: A Scrum-based Project Lifecycle
– The Lean Lifecycle: A Kanban-based Project Lifecycle
– The Continuous Delivery: Agile Lifecycle
– The Continuous Delivery: Lean Lifecycle
– The Exploratory (Lean Startup) Lifecycle
–The Program Lifecycle for a Team of Teams
Guidance, Adapt to Context: Select practices
For each factor of process goals, DAD toolkit proposes more options of practices with guidance about efficiency and tradeoffs in context.
Library of Practices
DAD toolkit offers a library of practice including both Core Agile Practices and options for each process goals.
Agile Modeling Core Practices are art of the DAD toolkit and where developed as complement to XP.
Agile Data Core Practices are used by the DAD toolkit
|Consumable solution Increment||The basic element for measuring progress. Also referred as “working software” or “product increment”. See “Consumable Solution” alpha for differences.|
|Work Items Representations||Is not reduced to Product Backlog: we can use Work Item List (improved backlog concept), Work Item Pool or others.|
|Definition of Ready||Eliminate waste: streamline the flow evolution from incoming work to WIP. DAD practices: Look Ahead Modeling and Look Ahead Planning.|
|Definition of Done||Eliminate waste: advance without technical debt, avoiding re-work and unexpected problems and interruptions.|
| Activities |
|Selecting a life-cycle ||Team activity: each release has a life-cycle choice. Preserving the one from the previous release or a model from an Agile Method (or even Waterfall) is also decision. Guidance & past experience will help.|
|Selecting practices |
per Process Goals
|Team activity: for each process goals the team will have its own choices. Preserving practices from previous releases or selecting others from some Agile methods is also a decision. Guidance & past experience will help.|
|Look Ahead collaboration||Looking ahead variants: envisioning the release, iteration look ahead and opportunistical look ahead before or inside the iteration. DAD offers collaborative practices for all of them and not only for iteration and daily planning. |
|Just in time collaboration||Just in time collaboration to clarify requirements, solution or other aspects. Example of practices: Pair Programming, Model Storming.|
|Lightweight Milestones Reviews||You can go beyond prescribed iteration level review in several ways. At the release level, you have the ones for the life-cycle milestones, including the one for proven architecture. At a smaller level, especially if you get the working software faster you could have automatic reviews (see Automatic validations).|
|Retrospectives||Improvement meetings, fundamental for continuous improvement. Collaborative work makes them effective. |
|Automatic validations||Include more kind of validations: automatic tests, automatic design check, and others. Fundamental for continuous integration, continuous delivery, and also for any form of often delivery/small releases.|
I want to thank Scott Ambler who started this Essentializing DA initiative and collaborated with SEMAT from 2009. Scott helped me with feedback and review of current materials. DA Essentialization began with the example of the DB Refactoring technique earlier this year.
- [R1-ES] Essence Specification 1.2 – https://www.omg.org/spec/Essence/1.2/
- [R2-SM] SEMAT (Software Engineering Method and Theory) – http://semat.org/
- [R3-SMMS] SEMAT mission statement: http://semat.org/mission-statement
- [R4-ESSDB] Essentialize DB refactoring – https://disciplinedagiledelivery.com/essence01/
- [R5] DA approach for organizations – Teal is the New Black
Use of Essence – Kernel and Language for Software Engineering Methods Specifications is the subject of Term and conditions & Notices found at https://www.omg.org/spec/Essence/1.2