Disciplined Agile Delivery (DAD) is a way of organising software delivery that covers the whole life of a project, from the first idea to the system running in daily use, and lets each team choose its working method from a catalogue of options instead of following one fixed process. It is the delivery part of a larger body of guidance called Disciplined Agile (DA), which the Project Management Institute (PMI) has owned since 2019.
Most businesses will never adopt DAD formally. It is still worth understanding, because a supplier, a job applicant or a parent company may mention it, and because several of its ideas are useful on any software project.
Where DAD came from and who owns it now
DAD was developed by Scott Ambler and Mark Lines, who set it out in a 2012 book, “Disciplined Agile Delivery”. Their starting point was that Scrum, the best-known agile framework, describes how a team builds software in short cycles but says little about how a project is started, how the technical design is looked after or how the finished system gets into use. Teams were filling those gaps by borrowing from other methods. DAD gathered the borrowings into one place.
PMI, the American body best known for the PMP project management qualification, acquired Disciplined Agile in August 2019 and now publishes the material on its own website. PMI describes DA as a tool kit, not a methodology: a decision framework and knowledge base that helps teams and organisations choose their “way of working”.
Older articles use the names loosely. “Disciplined Agile Delivery” was once the name for the whole thing. Today “Disciplined Agile” is the whole toolkit, which also covers DevOps and how the rest of the organisation works, and DAD is the part concerned with delivering software.
What DAD adds to Scrum
A full delivery lifecycle. DAD describes three phases. Inception is a short period at the start in which the team and the people paying for the work agree the vision, the scope, the technical approach and the funding. Construction is the build, done in increments. Transition is getting the result into use: deployment, data, training and handover. PMI’s guidance is that Inception should be kept short and that Transition should shrink as releases become routine.
More roles. The current Scrum Guide (2020) names three accountabilities: Product Owner, Scrum Master and Developers. DAD has five primary roles: stakeholder, team member, team lead, product owner and architecture owner. The last of these is the person who owns the technical design decisions for the team, on the reasoning that design is a major source of project risk and somebody should be answerable for it. Five supporting roles are brought in when the work calls for them: specialist, domain expert, technical expert, independent tester and integrator.
Awareness of the wider organisation. DAD calls this being “enterprise aware”. A team is expected to follow the organisation’s standards, reuse what already exists and take account of the people who will run and support the system afterwards. Lightweight milestone reviews give managers a view of progress without a heavy reporting process.
Choices instead of prescriptions. For each thing a team has to achieve, such as addressing risk or coordinating its activities, DAD sets out the decisions involved and the options for each, with their trade-offs. The team picks what suits its situation and revisits the choice as it learns. This is what “goal-driven” means in DAD material.
The six DAD lifecycles
Scrum has one cycle. DAD supports six, because teams face different situations.
| Lifecycle | How it works | Where it fits |
|---|---|---|
| Agile | Based on Scrum: fixed-length iterations with a release after several of them | Project work, and teams new to agile; PMI calls it the likely starting point |
| Lean | Based on Kanban: a continuous flow of work with a limit on how much is in progress | Experienced teams, and work that arrives unpredictably |
| Continuous Delivery: Agile | Short iterations with a release at the end of each one | A long-lived team with automated testing and deployment |
| Continuous Delivery: Lean | Continuous flow with releases as often as daily | The same, taken further |
| Exploratory | Based on Lean Startup: a series of quick experiments | A new product where nobody yet knows what users need |
| Program | A team of teams | Large efforts that need several teams coordinated |
The traditional sequential model, usually called waterfall, is described in the material but is not one of the six. We compare the two approaches in agile vs waterfall, and the flow-based way of working in 7 reasons to use Kanban.
What changed in 2025: the certifications were retired
For several years PMI sold four Disciplined Agile certifications: Disciplined Agile Scrum Master (DASM), Disciplined Agile Senior Scrum Master (DASSM), Disciplined Agile Coach (DAC) and Disciplined Agile Value Stream Consultant (DAVSC). During 2025 PMI withdrew them. Training partners stopped delivering the courses at the end of May and the last exams were held in November.
In their place PMI now offers courses: Disciplined Agile Essentials, Disciplined Agile Foundations and Disciplined Agile Leadership. These lead to a badge or a certificate of completion, not a certification. PMI’s agile certification is the PMI Agile Certified Practitioner (PMI-ACP), which is not tied to any one framework. On PMI’s website the old DASM and DASSM pages now redirect to the Foundations course and to the PMI-ACP.
Two practical consequences follow. A DASM or DASSM on a CV was earned before the end of 2025. And a training provider still advertising a DASM exam is out of date. The toolkit itself has not been withdrawn: PMI continues to publish it and launched the first of the new courses in April 2025.
Whether DAD matters to a smaller business
In our view, DAD was designed for large organisations with several teams, an architecture function and formal governance. A company of 10 to 500 people commissioning one system from a supplier does not need to adopt it, and should be wary of anyone proposing ten named roles for a team of four.
Several of its ideas are worth borrowing all the same:
- Treat the start and the finish as real work. Budget time for agreeing scope before the build, and for data migration, training and go-live after it. This is the same thinking behind agreeing scope and acceptance checks before a fixed price is set.
- Name the person who owns the technical design, on your side or the supplier’s.
- Pick the way of working to suit the work. A defined build and an open-ended stream of support requests need different handling.
- Involve the people who will run and support the system before it goes live.
For a wider comparison of the methods you are likely to be offered, see the top software development methodologies.
What to ask a supplier who mentions DAD
The same questions work for any method a supplier names:
- Which lifecycle do you use for work like ours, and why that one?
- What happens before the build starts, and what will we be asked to approve?
- Who is responsible for the technical design, and who decides priorities on our side?
- How does the system get into use: data migration, training, support after go-live?
- How will we see progress between milestones?
A supplier who can answer these plainly is worth more than one with the right vocabulary. Our list of questions to ask a software supplier covers the commercial side as well.