Disciplined Agile Delivery (DAD) is a scalable Agile software delivery framework. It takes a people-first, learning-oriented approach to software development and delivery.
DAD stems from the collection of other practices and frameworks practiced by Agile software development teams, such as scrum and lean software development, and unifies them under one framework. It builds on these other agile methodologies by aiming to fill in the process gaps between them and ultimately develop an agile approach that streamlines IT work at enterprise scale.
DAD is part of the Disciplined Agile toolkit.
How did DAD come about?
Scott Ambler and Mark Lines are credited as the creators of DAD. The term was first outlined by Ambler in the 2013 white paper "Going Beyond Scrum: Disciplined Agile Delivery." The concept was solidified in Ambler and Lines' book "Choose Your WoW! A Disciplined Agile Delivery Handbook for Optimizing Your Way of Working," which is often cited as the central reference for the term. The authors developed the methodology by observing situations in which agility worked on an enterprise scale. They used these observations to conjoin the many disparate Agile methodologies -- scrum, Kanban, etc. -- under one unified process.
Ambler and Lines recognized that scrums could only solve problems at the team level and could not address the problems agile teams face stemming from beyond that scope. They also observed that some agile terminology was conflicting and unclear.
DAD laid the groundwork for the Disciplined Agile (DA) framework, which was developed in 2015 and became the disciplined agile toolkit in 2018. Two additional layers -- disciplined DevOps and disciplined agile IT (DAIT) -- were later added to the framework, creating a comprehensive approach to DevOps and IT processes in the enterprise. The DA framework is a group of agile frameworks with the same basic goals as DAD, and DAD serves as the foundation layer. The other layers are scaled-up versions of DAD in essence.
Core principles of disciplined agile delivery
The core principles of DAD are as follows:
- Delight customers. Disciplined agile principles -- and the Agile manifesto -- state that customer satisfaction is critical for success. The customer should be kept in mind during beginning phases of development and businesses should seek feedback post-deployment to maintain satisfaction.
- Be awesome. This translates to being motivated, engaged and engaging. This promotes dependability and trust on the team and in the larger organization. Also includes focusing on product quality from the very beginning as opposed to building it in later.
- Context counts. A team, the individuals it's comprised of, and the enterprise are all unique entities with unique goals and ways of working. None of them exist in a vacuum, and the environment's effect on the individual entity should be taken into account, as each entity affects one another.
- Agile principals are sometimes followed rigidly by the teams that practice them. Doing so sometimes require ideal conditions that are rarely consistently present in the real-world enterprise. DAD encourages teams to be pragmatic rather than idealistic, and not to follow agile strictly if there is clearly a more efficient way of doing things. For this reason, DAD refrains from "best practices" in favor of strategies for maximizing benefits.
- Choice is good. This essentially encourages teams to choose the strategy that maximizes benefits considering their circumstances. It promotes a middle ground between entirely experimental approaches and entirely prescriptive ones, giving teams a structured set of options, but not prescribing any one of them.
- Optimize flow. This involves keeping work in progress to a minimum, visualizing workflow, eliminating waste, continuous improvement and experimentation, and clearly defined metrics for success. It also signals a preference for stable, sustainable teams with low employee turnover.
- Enterprise awareness. This refers to the team understanding their place in the larger enterprise architecture. This includes knowing how a team's process and output affect external teams, and vice versa. Ideally, external team's work in progress should be leveraged to complete work if possible.
3 phases of the DAD framework
There are three main phases of the DAD framework that mark stages in product development. They are:
- Inception -- This phase involves the work upfront, at the beginning of the development process. This includes envisioning activities to help frame the project and determine its purpose. It's recommended that the inception phase be kept brief. The 2013 Project Initiation survey found that teams generally take twice the length of an average sprint/iteration in the inception phase.
- Construction -- This phase involves creating the product in increments. Teams may implement hybrid agile methods -- scrum, Agile Data, Agile modeling -- to create the solution.
- Transition -- This phase involves deploying the product to stakeholders. This phase should ideally be as short as possible.
After the transition phase, the cycle starts over again at the inception phase in a new delivery lifecycle.
There are six different delivery lifecycle types in DAD, and in each one, the three phases take on slightly different characteristics. The lifecycle types are:
- Basic/agile lifecycle: Scrum-based, iteration-based, includes milestones and a work item list instead of a product backlog.
- The Lean lifecycle: Kanban-based. The main difference between this lifecycle and agile/basic is that meetings and iteration planning sessions are held on an as-needed basis. In agile, meetings are prescribed and held consistently.
- Continuous Delivery: Agile lifecycle. This lifecycle is an evolved version of the basic/agile lifecycle. This essentially agile/basic but with shorter iterations.
- Continuous Delivery: Lean lifecycle. This is essentially the lean lifecycle with shorter iterations and more frequent releases.
- The exploratory lifecycle. Focuses on a "fail fast" philosophy, where many different strategies are attempted to get a picture of what the market wants. Best for situations in which the product is not yet clearly defined.
- The Program lifecycle. This lifecycle focuses on organizing teams of teams, or the rare large agile team.
Teams should choose their lifecycle type based on their abilities and needs. A team may sometimes choose a lifecycle type, but as the team matures and gets more experienced it should pick the lifecycle type for itself. Each lifecycle has different pros and cons.
Model team roles in DAD
DAD outlines five common primary roles that manifest in agile teams and organizations of all scales. They are:
- Stakeholder -- This is anyone materially impacted by a product's outcome. This could be a user, someone related to a user, a manager, a product owner etc. Anyone with a stake in the product's success fits this role.
- Product owner -- The product owner speaks for the customer. The represent the customers' needs to the stakeholders and team members.
- Team member -- This is a person who has a direct part in producing the product. Team members identify and perform tasks and track their statuses as they work. They work with the team frequently to minimize requirements, testing and documentation. They maintain the list of work items for the team to complete and communicate progress and ways of work to stakeholders.
- Team lead -- They act as a servant leader to the team, coaching and guiding them through technical management activities and creating the conditions for the team to be successful.
- Architecture owner -- They are tasked with the responsibility if minimizing risk posed by architecture. They typically have a strong understanding of the business domain as well as a technical background. They facilitate the overall design of the product. They remove impediments to the team and provides resources to help ensure success.
There are also several secondary roles that are context-dependent and sometimes temporary. They are often brought in to resolve scale issues. They are:
- Specialist -- larger teams, or teams working in more complex areas, may require a specialist. An example would be a business analyst that joins to help explore product requirements.
- Domain/subject matter expert -- sometimes introduced by the product manager to help answer team questions and explain specific requirements or the overall vision of the project.
- Technical expert -- introduced temporarily to solve especially difficult problems and/or transfer their skills to team members.
- Independent tester -- support DAD teams by working side by side with them and validating work throughout lifecycles.
- Integrator -- focused on integrating especially large teams that require a separate position to make sure they all function as a unit.
It is important to note that by no means are these roles fixed. Any person may occupy any role at any time, and in some cases may occupy multiple roles at once. Part of a self-organizing team's duty is to volunteer for and fill these roles as needed.
Examples of Disciplined Agile Delivery
DAD was created by software developers but can be applied to other types of work. Any agile team that needs to deliver a product under evolving circumstances can use it. One example might be a team of writers that is tasked with continuous delivery of web content over a period. The team could use DAD's agile and lean principals like Scrum and Kanban, and function as a self-organizing team to plan, construct and deliver content, using feedback loops to adapt on the fly. Another example might be in portfolio management, in which teams use DAD to achieve strategic objectives through selection and management of projects.
Several organizations claim success using DAD. One example of which is Openlink. In 2013, the company initiated a company-wide shift to lean and agile using Disciplined Agile Executive workshops to train staff and reform processes.
DAD vs. SAFe
DAD and SAFe (Scaled Agile Framework) are both large-scaled agile frameworks and perform the same functions in an organization but have different approaches to agile management. SAFe is considered more rigid than DAD. It also takes a more top-down approach and is more prescriptive in nature. DAD takes a less prescriptive, bottom-up approach and focuses on improving processes instead of sticking to one. It is considered more flexible than SAFe and puts adaptability above all else.