Disciplined Agile (DA): PMI's Hybrid Agile Toolkit Explained

By Tara Minh · Updated Oct 10, 2026

Disciplined Agile (DA) is a process-decision toolkit owned by the Project Management Institute. Instead of prescribing one method, it lays out the decisions a team faces, the options for each, and the trade-offs, so the team can assemble its own "way of working" (WoW). It can sit on top of Scrum, Kanban, SAFe, or traditional methods.

Most agile frameworks answer a question for you. Scrum says how to run a Sprint. SAFe says how to plan across teams. DA asks a different question first: what's your situation, and which options fit it? That's why it's often described as a toolkit rather than a framework, and it's why it appeals to organizations where a single prescribed method keeps breaking against reality.

Key Facts

• Scott Ambler and Mark Lines co-created the Disciplined Agile approach in 2012; its roots are in Disciplined Agile Delivery (DAD), which Ambler says began at IBM Rational around 2008.
• PMI announced its acquisition of DA in August 2019; Ambler's account is that PMI bought Disciplined Agile Inc. and the Disciplined Agile Consortium to obtain the toolkit.
• PMI's site organizes the toolkit into Foundation, Disciplined DevOps, Value Streams, and Disciplined Agile Enterprise layers.
• PMI describes DA as usable alongside traditional, Scrum, or SAFe approaches, not as a replacement for them.
• The DA mindset rests on principles, promises, and eight guidelines.

Where Disciplined Agile came from

DA started life as a software delivery method. Scott Ambler, who traces DAD to his work at IBM Rational around 2008, and Mark Lines co-created the broader Disciplined Agile approach in 2012. Their goal was a flexible approach that recognizes every organization is different, and that even inside one organization, different teams work differently.

The pair went on to publish five books on DA and set up the DA Consortium. In August 2019, PMI announced the acquisition, and the toolkit moved under the same roof as the PMBOK tradition. Ambler held the title Vice President and Chief Scientist of DA at PMI until July 2022 and has said he's no longer involved in how it evolves.

That ownership matters for how you read DA today. It's PMI's answer to a long-standing tension: many organizations run some work with predictive methods and some with agile ones, and they need guidance that covers both without picking a side.

What "choose your WoW" actually means

The central idea is simple to state and hard to practice: there is no single best process, so choose your own way of working on purpose. PMI's introduction pitches DA as a way to explore your options and find your best next step, starting where you are and improving from there.

In practice, "choosing your WoW" is a series of small decisions rather than one big adoption event:

• Which lifecycle fits this team's work?
• Which planning, estimation, and quality practices do we use, and which do we skip?
• How much governance does this particular risk level need?
• Who do we coordinate with, and how?

DA's tool for this is the process goal diagram. PMI says DA teams are guided through choosing their WoW via straightforward process goal diagrams, which show the options for each decision and what each costs you. It adds that every practice has trade-offs: it works well in some situations and poorly in others. The diagrams are there to make those trade-offs visible before you commit.

This is also why DA pairs well with continuous improvement. PMI calls its approach to this Guided Continuous Improvement, meaning you revisit the choices as the situation changes instead of locking them in.

The layers of the toolkit

PMI's site organizes the DA toolkit into layers, each one widening the scope of the decisions covered.

The layering is the part that separates DA from most team-level frameworks. A sprint-based method rarely says anything about how Legal or Finance should work with agile teams. DA does, because PMI's toolkit treats those as process decisions too. PMI frames the top layer as the capacity to sense and respond to marketplace change with a culture and structure that supports change.

Two things worth knowing before you dive in. First, the layers aren't a maturity ladder you climb in order. A team can use Disciplined DevOps guidance without anyone touching the enterprise layer. Second, PMI publishes much of this as a browsable knowledge base rather than a book you read once, so expect to dip in and out.

Choosing a lifecycle

One of DA's most practical contributions is that it won't force every team onto the same lifecycle. Mark Lines made the argument directly: many organizations box agile into one flavor, such as Scrum or Kanban or a prescriptive scaling pattern, and that shrinks the share of projects that get to use agile at all.

The lifecycles he describes in that post include:

Lines also notes that organizations adopting DA tend to move their mix of lifecycles over time, from traditional toward basic agile and eventually toward the advanced continuous lifecycles, as team capability improves. That's a useful mental model: lifecycle choice isn't a verdict on a team, it's a fit between the work and the team's current capability.

If you're deciding between a Scrum-style and a flow-style lifecycle, Scrumban is a good example of the kind of hybrid DA treats as a legitimate option rather than a deviation.

How DA compares with SAFe, LeSS, Nexus, and Scrum of Scrums

These approaches get compared constantly, but they aren't the same kind of thing. SAFe, LeSS, and Nexus are prescribed ways to scale. Scrum of Scrums is a coordination pattern. DA is a decision toolkit that can include any of them as an option.

The honest summary: if you already know you want a specific scaling model, read up on SAFe, LeSS, Nexus, or Scrum of Scrums directly. If you don't know yet, or if different parts of your organization clearly need different things, DA's job is to help you decide.

PMI is explicit that DA isn't competing with those methods on their own turf. It says applying the toolkit lets organizations customize any method or framework, including traditional, Scrum, or SAFe. In other words, you can run SAFe and use DA to question which SAFe practices you actually need.

How to start using DA: a step-by-step approach

You don't need to adopt the whole toolkit. Here's a lightweight way to begin with one team.

1. Describe the situation. Write down team size, location, regulatory constraints, how predictable the work is, and the skills in the room. DA's whole premise is that context drives the choice.
2. Pick a starting lifecycle. Match the work to one of the lifecycles above. If you're unsure, a basic Scrum-based lifecycle is a common starting point, and you can move later.
3. Identify the decisions that hurt. Where does the team argue or stall? Pick two or three process areas, such as estimation, release, or stakeholder governance.
4. Look at the options and trade-offs. For each pain point, use the DA Browser and process goal diagrams to list the options and what each one costs.
5. Choose and record the decision. Pick an option, say why, and note what would make you revisit it. The template below helps.
6. Try it for a fixed period. Run the choice for a few iterations and look at the results in a retrospective.
7. Repeat. Treat the WoW as a living thing. When the team or the work changes, revisit the decisions.

A WoW decision-record template

Most teams change their process in conversation and then lose the reasoning. A decision record fixes that. Copy this table and keep one row per decision.

Keep the "trade-off we accepted" column honest. It's the part DA cares about most, and the part teams skip when they want a fast answer.

Examples by business function

Because DA reaches past software, it's worth seeing what a WoW decision looks like in other functions. These are illustrative scenarios, not case studies.

Notice the pattern: the same organization uses several approaches at once. That's not inconsistency. It's the point.

Do's and don'ts

What about DA certification and training today?

PMI has changed its agile training offers over the past few years, so check pmi.org for what's current before you plan a program around a credential. PMI's DA site currently points learners to agile certifications and lists online courses called Disciplined Agile Essentials and Disciplined Agile Foundations, along with instructor-led training through PMI Authorized Training Partners. The toolkit content itself is available on the DA site and in the DA Browser, so you can use the ideas without any course.

When DA is not the right choice

DA gives you freedom, and freedom has a cost. It's a poor fit when:

• A team wants a ready-made routine to follow on day one. DA asks for decisions, and some teams just want a recipe.
• Nobody has the experience to weigh trade-offs. Early on, many teams benefit from a coach.
• The organization needs one standard method for contractual or audit reasons. A prescribed framework may be simpler to defend.
• Leadership wants to adopt a label rather than examine how work gets done.

In those cases, starting with plain Scrum or a defined scaling framework, then using DA ideas later, is a reasonable path. For background on the broader family of methods, see what agile methodology is.

Disciplined Agile won't tell you which framework to buy. It gives you a way to argue about process with evidence: here's our situation, here are the options, here's the trade-off we're taking, and here's when we'll look again. If your teams already run a mix of agile and traditional work, that habit may be worth more than any single method.