Disciplined Agile Delivery (DAD)

How did DAD come about?

Scott Ambler and Mark Lines are the creators of DAD. The term was first outlined by Ambler in the 2013 white paper "Going Beyond Scrum: Disciplined Agile Delivery." Ambler and Lines solidified the concept in their 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 recognized that scrums could only solve problems at the team level and could not address the problems Agile teams faced 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. DAD serves as the foundation layer, and the other layers are scaled-up versions.

Core principles of Disciplined Agile Delivery

The core principles of DAD are as follows:

• Delight customers. The team should keep customers in mind during beginning phases of development and businesses should seek feedback post-deployment to maintain satisfaction.
• Be awesome. Teams should be motivated, engaged and engaging. This promotes dependability and trust on the team and in the larger organization. Teams should also focus on product quality from the very beginning.
• Context counts. A team, its members, and the enterprise are all unique entities with unique goals and ways of working. None of them exist in a vacuum, and teams should consider the environment's effect on the individual entity as each affects one another.
• Be pragmatic. Agile principals are sometimes followed rigidly by the teams that practice them, which requires ideal conditions that are rarely present in the real-world enterprise. DAD encourages teams to be pragmatic rather than idealistic, and not to follow Agile strictly if there is a more efficient approach.
• Choice is good. This encourages teams to choose the strategy that maximizes benefits. 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, continuing improvement and experimentation, and clearly defining metrics for success. It also signals a preference for stable, sustainable teams with low employee turnover.
• Organize around products/services. Teams should organize their efforts around the product or service the end user desires. Similar yet more explicit than value streams, the team should focus development around what the customer needs.
• Enterprise awareness. The team should understand their place in the larger enterprise architecture. This includes knowing how a team's process and output affects external teams, and vice versa.

The phases and lifecycle types of the DAD framework

The three main phases of the DAD framework that mark stages in product development are inception, construction, and transition.

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:

• The Agile Lifecycle. This type is Scrum-based, iteration-based, and includes milestones and a work item list instead of a product backlog.
• The Lean Lifecycle. This type is Kanban-based. The main difference between this lifecycle and Agile 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 Agile lifecycle with shorter iterations.
• Continuous Delivery: Lean Lifecycle. This is essentially the Lean lifecycle with shorter iterations and more frequent releases.
• The Exploratory Lifecycle. This lifecycle focuses on a "fail fast" philosophy, where many different strategies are attempted to get a picture of what the market wants. This type is 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. Each lifecycle has different pros and cons.

Model team roles in DAD

DAD outlines five common primary roles in Agile teams and organizations of all scales, as follows:

• Stakeholder. This is anyone materially impacted by a product's outcome, like a user, someone related to a user, a manager, or a product owner. Anyone with a stake in the product's success fits this role.
• Product owner. The product owner speaks for the customer. They represent the customers' needs to the stakeholders and team members.
• Team member. Team members have a direct part in producing the product. They 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 to stakeholders.
• Team lead. The team lead acts as a servant leader, coaching and guiding the team through technical management activities and creating the conditions for the team to be successful.
• Architecture owner. Their responsibility is to minimize risk posed by architecture. They have a strong understanding of the business domain as well as a technical background. They facilitate the overall design of the product, remove impediments to the team and provide 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 the following:

• 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. They are sometimes introduced by the product manager to help answer team questions and explain specific requirements or the overall vision of the project.
• Technical expert. Technical experts can join temporarily to solve especially difficult problems and/or transfer their skills to team members.
• Independent tester. This role supports DAD teams by working alongside them and validating work throughout lifecycles.
• Integrator. They focus on integrating especially large teams that require a separate position to make sure they all function as a unit.

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

While software developers created DAD, it applies to other types of work. Any Agile team that needs to deliver a product under evolving circumstances can use it. One example is a team of writers tasked with running continuous delivery of web content over a period. The team could use DAD's Agile and Lean principals like Scrum and Kanban to plan, construct and deliver content, using feedback loops to adapt on the fly. Another example is portfolio management, where teams use DAD to achieve strategic objectives through selection and management of projects.

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.

Editor's note: This article was reformatted to improve the reader experience.