Crystal, FDD, DSDM & AUP: Other Agile Frameworks [2026]

Ask most people to name an agile framework and they'll say Scrum, maybe Kanban. But agile is a whole family, and several less famous members have shaped how teams work, each with its own emphasis, from people-first flexibility to rigorous feature planning to business-driven governance. Knowing they exist is part of understanding that agile is a mindset tailored to context, not a single method. This guide explains the other agile frameworks beyond Scrum: the Crystal agile methodology, Feature-Driven Development, DSDM, and the Agile Unified Process — what each is, how they differ, when to use them, and how they appear on the PMP and CAPM exams.

Beyond Scrum and Kanban: the wider agile family

Agile is not a single method but a family of frameworks, all sharing the values and principles of the Agile Manifesto while differing in how they put them into practice. Scrum, Kanban, and Extreme Programming get most of the attention, but several other frameworks were part of the early agile movement and remain relevant in particular contexts.

The four covered here — Crystal, Feature-Driven Development (FDD), the Dynamic Systems Development Method (DSDM), and the Agile Unified Process (AUP) — each emphasize a different aspect of agile. Crystal is about people and adaptability; FDD is about structured, feature-based delivery; DSDM is about business value with fixed time and cost; and AUP is a lightweight take on a heavier traditional process. None is as widely used as Scrum today, and some are largely of historical interest, but they show something important: that agile is a mindset that can be expressed in many ways, tailored to a team's size, context, and needs. Understanding the alternatives is part of understanding agile itself.

The Crystal agile methodology

Crystal is not one method but a family of lightweight, adaptable methodologies created by Alistair Cockburn, one of the original signatories of the Agile Manifesto. Its central belief is that people and their interactions matter more than any process — so rather than prescribing fixed practices, Crystal adapts the amount of process to the situation.

Crystal's most distinctive feature is that its family members are color-coded by team size and project criticality. Crystal Clear suits very small teams (roughly one to six people), Crystal Yellow larger ones (around seven to twenty), Crystal Orange bigger still (around twenty to forty), and darker colors scale up from there. The idea is that a small, co-located team needs far less process than a large, distributed one, so the framework should flex accordingly. Across the family, Crystal emphasizes a handful of properties: frequent delivery of working software, reflective improvement (regularly adjusting how the team works), and osmotic communication — the way information naturally flows among people working closely together, ideally in the same room. Crystal is the most people-centric and least prescriptive of the agile frameworks, which is both its strength and the reason it's harder to adopt "by the book."

Ready to take the next step in project management?

200,000+ Learners Trust Our Instructors

Get PMP® Certified

The gold-standard credential for experienced PMs

PMP Training →

Get CAPM® Certified

The entry-level PM credential — no experience required

CAPM Training →

Learn Project Management

Master PM from beginner to project manager

PM Course →

Feature-Driven Development (FDD)

Feature-Driven Development (FDD) is a model-driven, feature-centric agile method created by Jeff De Luca in the late 1990s. As its name suggests, it organizes all work around small, client-valued features — a feature being a small piece of functionality expressed in plain language, such as "calculate the total of a sale." Where Crystal is loose and adaptive, FDD is comparatively structured and prescriptive.

FDD is built around five processes that a team works through:

1. Develop an overall model of the domain, giving the team a shared understanding of the whole system.
2. Build a features list, breaking the model into a comprehensive list of small features.
3. Plan by feature, sequencing and assigning the features to be built.
4. Design by feature, working out the design for a small group of features.
5. Build by feature, implementing and testing them, then integrating regularly.

The first two processes happen once at the start; the last three repeat in short iterations, with features typically built in a couple of weeks or less. FDD emphasizes up-front domain modeling, regular builds, and clear progress reporting, which makes it scale well to larger teams and appeal to organizations that want agility with more structure and predictability than Scrum's lighter framework provides.

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method (DSDM) is one of the earliest agile methods, developed in the UK in 1994 — before the term "agile" even existed — and later evolving into the approach now known as AgilePM. Its defining characteristic is a reversal of the traditional project trade-off: DSDM fixes time and cost and flexes scope, rather than fixing scope and letting time and cost vary.

To make that work, DSDM relies on MoSCoW prioritization, sorting requirements into Must have, Should have, Could have, and Won't have (this time). By guaranteeing the "must haves" and treating lower priorities as flexible, a team can hit a fixed deadline and budget while still delivering the essential value — the same value-based ordering used in a product backlog. DSDM is guided by eight principles, including focusing on the business need, delivering on time, never compromising quality, and building incrementally from firm foundations. Unlike the more developer-focused frameworks, DSDM covers the whole project lifecycle and governance, not just the building of software, which is why it has found a home in larger enterprises and more regulated environments that need agility with structure and control.

Agile Unified Process (AUP)

The Agile Unified Process (AUP), created by Scott Ambler around 2005, is a simplified, agile version of the Rational Unified Process (RUP) — a heavier, more formal software-development process that predates agile. AUP keeps RUP's overall shape but strips it down and runs it in an agile way, with "just enough" documentation rather than RUP's extensive artifacts.

AUP retains RUP's four phases — Inception (initial scope and vision), Elaboration (proving the architecture), Construction (building the software), and Transition (releasing it) — but rather than treating them as a sequential, waterfall-like progression, it works through them iteratively and incrementally. It organizes work across a handful of disciplines, such as modeling, implementation, testing, and project management, applying each with an agile, lightweight touch. AUP was essentially a bridge for organizations moving from the formality of RUP toward agile, and it has largely been succeeded by Disciplined Agile (DA), a broader agile toolkit that Ambler went on to develop and that is now part of PMI. It's the most "traditional-looking" of the frameworks here, which is exactly what made it useful for teams transitioning away from heavyweight processes.

Comparing the frameworks

Although all four are agile, each emphasizes something different, which is the key to telling them apart. The table below summarizes their distinctive character.

Read across the table, the spectrum becomes clear: from Crystal's minimal, people-first flexibility, through FDD's feature-based structure, to DSDM's business-driven governance and AUP's lightweight take on a formal process. They range from the least prescriptive (Crystal) to the most structured (DSDM and AUP), giving a sense of just how much variety exists within "agile." What unites them is the Manifesto's values; what separates them is how much process each adds and where it focuses.

When would you use these frameworks?

In practice, most teams today reach for Scrum, Kanban, or a blend of the two, and these four frameworks are far less commonly adopted wholesale. But each still has contexts where its emphasis is genuinely useful. Crystal suits a small, co-located team that wants to stay agile with the absolute minimum of imposed process. FDD appeals to larger teams building a feature-rich product who want more structure and predictability than Scrum offers. DSDM fits organizations — often larger or regulated ones — that need to hit fixed deadlines and budgets while staying flexible on scope, and that value its whole-lifecycle governance. AUP made sense mainly as a stepping stone for teams moving away from heavyweight processes like RUP.

More often, though, their real value today is as a source of ideas rather than complete methods to adopt. DSDM's MoSCoW prioritization, Crystal's emphasis on communication and reflection, and FDD's feature-based planning all get borrowed by teams running Scrum or Kanban. That's a fitting outcome for the wider agile family: even the less popular frameworks contributed techniques that live on. The lesson is less "pick one of these" and more "agile is a rich tradition, and there's more to it than Scrum."

Other Agile Frameworks on the PMP® and CAPM® Exams

Because the current PMP exam treats agile as a broad family of approaches rather than just Scrum, it expects a working awareness of these other frameworks. You won't need deep expertise in each, but you should recognize the names and their headline ideas: that Crystal is a lightweight, people-focused family, that FDD organizes work around features, and — most testably — that DSDM fixes time and cost while flexing scope and uses MoSCoW prioritization.

Situational questions are more likely to test the concepts than the framework names. MoSCoW prioritization and the idea of flexing scope to protect a fixed date and budget are the most exam-relevant takeaways here, since they apply well beyond DSDM itself. The broader point the exam rewards is understanding that agile can be tailored many ways, and choosing an approach that fits the context. Our PMP Complete Study Guide, the most complete on the market, covers the full range of agile approaches as the exam frames them.

PMP Practice Question: Agile Frameworks

A project manager is running a DSDM-based project to deliver a compliance system before a regulator-imposed go-live date; neither the date nor the budget can move, and the team has promised stakeholders a guaranteed essential scope. In the prioritization workshop, the business sponsor classifies 52 of the 60 requirements, about 85% of the estimated effort, as Must have, arguing that "everything in a compliance project is mandatory," and asks the team to start building immediately in priority order.

What should the project manager do next?

a) Begin delivery in strict priority order, so the Must haves are completed first and the Should and Could haves are dropped if time runs short.

b) Facilitate a re-prioritization with the sponsor so the Must haves consume only part of the team's capacity, leaving the Should and Could haves as the flex that protects the fixed date.

c) Accept the sponsor's classification and protect the go-live date by planning a contingency buffer into the schedule ahead of the deadline.

d) Have the team re-estimate the 52 Must haves and reclassify those with the largest estimates as Should have until the committed work fits the timebox.

Correct answer: B.

Rationale: In DSDM the deadline is protected by flexing scope, and that only works if the guaranteed portion is genuinely smaller than the team's capacity — DSDM's own guidance is that Must-have effort should not exceed roughly 60% of the total, precisely so the Should and Could haves form the contingency. With 85% classified as Must have, there is almost nothing left to drop, so the "guarantee" is an illusion; the correct next step is to take the prioritization back to the sponsor and rebalance it before delivery starts.

Choice a) is the trap for candidates who know MoSCoW only on the surface: building in priority order is the mechanism, but it protects nothing when the Musts alone can exceed what the timebox holds — the team simply fails inside the deadline with no agreed flex. Choice c) imports a predictive fix into the wrong constraint: the date is regulator-imposed, and in this approach contingency comes from scope, not from schedule padding a fixed date cannot accommodate. Choice d) puts the reclassification in the wrong hands: Must versus Should is a business-value judgment owned by the business, and demoting requirements by size rather than value quietly breaks the agreement the prioritization exists to create. To drill this kind of agile-prioritization judgment, work through our PMP practice exams or, at the entry level, our CAPM practice exams.

Ready to take the next step in project management?

200,000+ Learners Trust Our Instructors

Get PMP® Certified

The gold-standard credential for experienced PMs

PMP Training →

Get CAPM® Certified

The entry-level PM credential — no experience required

CAPM Training →

Learn Project Management

Master PM from beginner to project manager

PM Course →

Frequently asked questions