Disciplined Agile Delivery (DAD)

Origins

Disciplined Agile Delivery was developed by Scott Ambler and Mark Lines at IBM and Disciplined Agile Inc., first published in 2012.¹ The framework's premise was distinctive: rather than prescribe one way of doing agile, DAD provides a toolkit of process goals and process options from which teams choose what fits their context.

The Project Management Institute (PMI) acquired Disciplined Agile in 2019, and it now operates as part of PMI's certification ecosystem. The framework was rebranded "Disciplined Agile Toolkit" but retains its underlying structure.²

The Core Idea: Choice, Not Prescription

DAD's distinctive claim: there is no one right way to deliver software. Different teams in different contexts need different approaches. The framework's job is to enumerate the choices, explain their trade-offs, and help teams pick — not to prescribe.

This stands in clear contrast to SAFe (highly prescriptive) and even Scrum (smaller but still prescriptive). DAD argues the prescription itself is a problem: every team forced to use a framework that doesn't fit produces friction, theatre, or both.

The Process Goals

DAD organizes its content around 21 process goals across the delivery lifecycle. Examples:

• Form the initial team.
• Identify the architecture strategy.
• Plan the release.
• Coordinate activities.
• Address risk.
• Improve quality.
• Produce a potentially consumable solution.
• Govern delivery.

For each goal, DAD provides decision points (e.g., "what testing strategy?") and process options for each decision (e.g., "automated unit tests, exploratory testing, scripted manual testing"). Teams pick the options that fit their situation.

The Lifecycle Options

DAD supports six lifecycle variants:

• Agile (Scrum-based) — sprint-based delivery.
• Lean — continuous flow without sprints.
• Continuous Delivery: Agile — sprint-based with frequent releases.
• Continuous Delivery: Lean — continuous flow with continuous deployment.
• Exploratory (Lean Startup-based) — for novel products requiring discovery.
• Program — for coordinated multi-team work.

The team picks the lifecycle that fits its work and can shift between them as the work evolves.

The Strengths

• Context-honesty. The framework explicitly acknowledges that one size doesn't fit all.
• Breadth. DAD covers the full delivery lifecycle — including the bits Scrum doesn't address (architecture, governance, deployment).
• Decision support. The toolkit format helps teams make explicit choices rather than inheriting defaults.
• Enterprise-friendly. Includes governance, risk, and architectural concerns that enterprises legitimately have.

The Weaknesses

• Complexity. 21 process goals across 6 lifecycles produces a lot to learn. Teams can drown in the toolkit before benefiting from it.
• Decision overhead. Choice is valuable but also costly. Teams that need to make every process decision deliberately can spin in process design.
• Less ecosystem than SAFe. PMI's stewardship has stabilized the framework but the ecosystem is smaller than SAFe's.
• Hard to communicate. "We use DAD" doesn't convey what you actually do, because DAD allows wide variation.

Who DAD Fits

• Mature agile teams that have outgrown prescriptive frameworks and want explicit decision support.
• Enterprise organizations needing to cover the full lifecycle (not just sprint-level practice).
• Coaches who appreciate a structured catalog of options to draw from.
• Organizations that value PMI certification or are already in the PMI ecosystem.

Who DAD Doesn't Fit

• Teams new to agile, who need prescription before they can choose.
• Organizations seeking the simplest possible framework.
• Cultures attached to a single methodology brand identity (SAFe, LeSS, Scrum).
• Teams whose work is well-served by Scrum or Kanban as-is.

The Honest Position

DAD is the most intellectually honest of the major scaling frameworks. It treats agile delivery as a domain with many valid approaches, not as a single methodology. The cost of that honesty is complexity — the toolkit format requires more from teams than a prescriptive framework does. For teams ready to make those choices, DAD's catalog is genuinely useful. For teams that aren't, prescription is often more helpful than choice.

Coaching Tips

Start with one lifecycle.

Don't try to absorb the whole toolkit. Pick the lifecycle that fits the team and learn that piece first.

Use the goal diagrams for retros.

The decision-point diagrams are excellent retro inputs. "Which options are we using for this goal? Are they working?"

Don't over-customize.

DAD's freedom can become decision overhead. Pick a starting set; change only what doesn't work.

Use it as a catalog, not a methodology.

DAD's value is the catalog of options. Treat it as a reference, not as a prescriptive framework.

Watch for choice paralysis.

Some teams freeze when given too many options. Default to a sensible starting set and let teams customize from there.

Pair with Scrum or Kanban basics.

DAD complements Scrum or Kanban; it doesn't replace them. Use the toolkit to fill in what the simpler frameworks don't address.

Summary

Disciplined Agile Delivery occupies a distinctive niche: the framework that refuses to prescribe a single way. The 21 process goals and 6 lifecycle variants give teams genuine flexibility while still providing structure. The honesty of the framework is its strength; the complexity of the framework is its cost. DAD rewards mature teams ready to make explicit choices and burdens newer teams who would benefit from a more prescriptive starting point. For organizations ready for it, the toolkit is a richer resource than any single-method framework provides.

Back to Scaling Agile