I recognise that this may seem like a basic or easily Googled question, but I've been struggling to make sense of the various resources that describe what DAD is. The Wikipedia article is sparse on detail, and YouTube tutorials have not really been any more illuminating.

What I'd like to know is how DAD operates in the real world. For example, many resources mention that it's a hybrid of various Agile methodologies such as Scrum, Lean, Kanban, XP and so on ... but how does that really work? What would a company implementing a DAD methodology look like? I've also seen resources mention that it's non-prescriptive and encourages choice between different frameworks ... how then is it different from simply instructing a company to "Use any one of the Agile methodologies you like"? What does DAD actually bring to the table in terms of development practices?

I'm new to software development entirely, so all of the abstract descriptions and jargon surrounding DAD haven't helped me to understand what it means in context. I'd be grateful if anyone could break down the jargon and place the methodology in context of a real-world situation.

2 Answers 2


I believe that they've moved away from this terminology, but when Disciplined Agile was newer, the creators described it as a "process decision framework".

DA is centered around high-level activity phases for a project and goals within each phase. These aren't strict phase-gate phases, but rather a way to organize the goals. However, DA doesn't tell you how to go about accomplishing these goals. It's more like a library of practices and information about which ones work well together.

We can take a concrete example of Scrum for more information.

Scrum doesn't tell you how to form your team. DA recognizes that there are choices to be made about where the team members come from, such as repurposing an existing team or creating a new team. There are also different structures such as feature teams and component teams or geographic distribution of the team or the dedication of the team members (full-time, as needed). All of these are decisions that would be considered as part of DA.

Scrum tells you that you need a potentially releasable product Increment after every Sprint. DA recognizes that there are choices to be made about how to go about doing this. Are you going to be using BDD? TDD? Maybe a combination of both? Are you going to produce formal design specifications? Maybe you'll be using mob programming to evolve the design with the whole team. Or maybe you'll build proofs-of-concept and demonstrate those.

There are even higher-level choices. Do you have cadences or do you perform work just-in-time, for example. The same sets of roles, phases, goals, and activities can be used to describe a number of processes. It's been mapped to a Scrum-based lifecycle, a just-in-time Lean lifecycle, and even an exploratory delivery lifecycle. All of these are built using the same building blocks, with just a different set of choices.

Some choices are mutually exclusive. Some combine well.

You could have 5 organizations adopting Disciplined Agile. They would likely be able to communicate with each other using DA's fixed sets of roles, phases, and goals. However, each organization may have a different way of satisfying those goals, so their lifecycle would look entirely different.

DA brings a framework that lets an organization build a process lifecycle that is appropriate for their needs. It's not prescriptive at all, but it guides the organization through the things that need to be thought of along the way and some ideas of common practices that have been known to work.

  • Thanks for taking the time to explain. I'm afraid it's still not entirely clear to me how DA differs from, well, simply using e.g. Scrum methodology, JIT Lean, Kanban or something else. What would it mean if an organisation is using Disciplined Agile through a Scrum framework, and how is this different from simply using a Scrum framework?
    – Lou
    Commented Aug 9, 2020 at 18:32
  • 2
    @Lou DA is more complete than Scrum. For example, compare the DA Scrum-based lifecycle to the Scrum Guide and you'll see that the Scrum Guide leaves it as an exercise to the reader for figuring out things like funding or building the initial Product Backog or what operations looks like. DA has goals in the Initiation phase to provide options for doing this. But aside from that, it may be very difficult to tell if an organization is using DA or Scrum and just filling in the blanks without asking them. DA is just a way to highlight all of the blanks and get some pointers to filling them in.
    – Thomas Owens
    Commented Aug 9, 2020 at 18:43

Discipline Agile Delivery defines itself as a "toolkit". A toolkit is not prescriptive: you can pick the tools and combine them as best suited to the (project) needs.

Despite the subtle semantics, it’s more than just a toolkit since it proposes guidance for the full development lifecycle:

  • At the micro level, work is arranged using typical practices of other methods:

    • it can be scrum based, with time-boxed iterations to build product increments.
    • it can be kanban based ("lean"), with different backlog items are processed at different speed
  • At a macro level, it inspired by the unified process:

    • it starts the delivery process with an inception: somehow you must clarify the objectives, hire a team, and agree on the way to go forward. If you’d use user story mapping, the initial workshop would probably happen there;
    • it then continues with a construction, that you’d organize à-la scrum with several sprints, or à-kanban, or anything else that is agile and suitable (see micro level above)
    • it finally releases a product with the transition (to production). Typically you may have additional activities here that are related to production constraints.
  • and then it continues with the next cycle of construction/transition until it’s over.

This is not surprising, since DAD was co-designed by Scott Ambler who has previously developed Agile Modelling, then Agile Unified Process (streamlining the typical UP to remove administrative overhead, and keep only the core ideas).

So DAD will not kill the current agile practices, it will complement and enrich them.

Not related: interestingly, the idea to take agile practices from different methods, and combine them as needed for a specific project, seems to become a new trend in software engineering: Ivar Jacobson recently published a nice textbook on the topic: "The essentials of modern software engineering - free the practices from the method prisons"

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.