Disciplined Agile Delivery (DAD)

A holistic & pragmatic way to scaling agile​

Disciplined Agile Delivery (DAD) builds on top of known Agile and Scrum frameworks, taking a pragmatic approach while placing emphasis on the many different parts of an organization that are involved in delivering software.

In terms of scaling, DAD differs between tactical agility at scale and strategic agility at scale. While tactical agility addresses individual team scaling, strategic agility scales through the application of Agile and Lean strategy holistically throughout the enterprise by expanding the framework to different areas of the organization.

Key Purpose
& Core Principles

Disciplined Agile Delivery
(DAD)

A goal-driven approach

The key purpose of DAD is to increase overall business agility in a simple way. Arguing that every situation is unique, DAD promotes pragmatism and an approach of adopting the Agile processes to the specific needs of the company and product. DAD offers a lot of “Bang for the Bucks” and fast deployment.

Within the DAD framework, a goal-driven approach is applied to create and adapt Agile processes. According to the methodology, each team will meet 21 key processes during their lifecycle, and for each of these processes, the team must make a number of decisions of how to structure that process.

As shown on the image below, each of the decision points provide suggested techniques or practices meant to be used for implementing the decision in the organization.

An Introduction to Key Elements

Roles

DAD builds on top of Scrum to provide a more extensive role catalogue in order to address the entire solution delivery lifecycle. The team roles are broken down into two categories; primary (working on the project on a constant basis) and secondary roles (introduced temporarily e.g. in relation to scaling).

DAD defines 5 primary roles. Stakeholders are the people who will use your team’s product or solution, e.g. end-users or customers. Team members are the people in the team executing the planned work, such as developers or testers. The team lead works as a servant leader for the team, resembling a Scrum Master, as he or she facilitates progress by removing impediments and empowering the team. The Product Owner is the representant for the stakeholders and is responsible for prioritizing and maintaining the list of activities to be carried out by the team. Finally, the architecture owner is responsible for enterprise alignment of the solution architecture, mitigating risks with a deep technical or domain knowledge.

In addition to the 5 primary roles, DAD also defines 5 secondary roles. Specialists are people joining the team temporarily to contribute with their specific knowledge. Domain experts are people with technical domain expertise who can help out the team on challenges within their areas, e.g. legal advisors. Technical experts help out the more generalized team members at key points in the life cycle of the solution or product. Independent testers work to validate the work of the testers in the team in specific cases where it is necessary e.g. due to very complex systems. Finally, the integrator helps the team to integrate their product or solution within the holistic system, and is responsible for managing dependencies to other products or solutions.

Delivery Lifecycle

DAD provides a suggestion for 6 different full delivery lifecycles, accounting for different work styles, agile maturity in the company, and other conditions that might influence the needs for a specific type of delivery lifecycle:

  • 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

The basic assumption is that companies need to factor in full delivery lifecycles beyond the development and release part typically covered by agile and scrum. This includes the early stages of vision definition and approval, as well as the support and retirement phases following releases.

In doubt which agile framework to choose?​