Scrum, Kanban, and the Agile Method Family

The Agile method family examined: Scrum, Kanban, XP, FDD, DSDM, Crystal, and SAFe compared by structure, governance, and fit across project contexts.

By Kateule Sydney — Researcher and Writer | Last Verified: 2026-10-03 | Published by Kat-Syd Resources Hub

The Agile method family: Scrum, Kanban, XP, DSDM, FDD, Crystal, and SAFe compared

Table of Contents

• 1. Agile Is a Family of Methods and Frameworks, Not a Single Approach
• 2. Scrum Is a Framework, Not a Methodology
• 3. Kanban Is a Flow-Based Method, Not an Iteration System
• 4. Extreme Programming Is an Engineering-Focused Agile Method
• 5. DSDM, FDD, and Crystal Represent Different Trade-Offs
• 6. Scaled Agile Framework Addresses Coordination at Scale
• 7. What the Method Family Shows About Agile at Scale
• Judgement
• References

1. Agile Is a Family of Methods and Frameworks, Not a Single Approach

One of the most persistent confusions in Agile practice is treating Agile as a single methodology. The Manifesto for Agile Software Development established four values and twelve principles; it did not prescribe a single method or framework. Scrum, Kanban, Extreme Programming, Feature-Driven Development, Dynamic Systems Development Method, Crystal, and Scaled Agile Framework represent different approaches associated with Agile, although they differ in origin, scope, and degree of prescription.

Definition. The Agile Manifesto, published in February 2001 by 17 software practitioners, states four values and twelve principles for software development. It does not prescribe a method. Some Agile approaches predate the Manifesto, while others emerged around or after it. DSDM, for example, originated in 1994, while Scrum, XP, FDD, Crystal, and later SAFe developed through different streams of Agile and related practice.

That distinction is one I explored in my post on Agile project management, where the focus was the values and principles behind Agile practice. This post examines the named methods and frameworks.

The methods differ along three dimensions:

• Scope of prescription — Scrum defines accountabilities, events, artifacts, and rules; Kanban is a method for managing and improving flow and does not prescribe a fixed set of roles or iterations; XP places much more emphasis on software engineering practices; FDD defines five core processes; DSDM provides a structured project framework; Crystal is a family of approaches that adapts to team size and system criticality; SAFe provides guidance for coordinating Agile work at organizational scale
• Unit and cadence of delivery — Scrum uses fixed-length Sprints; Kanban emphasizes continuous flow rather than mandatory iterations; XP emphasizes short development and feedback cycles; FDD organizes delivery around client-valued features; DSDM uses timeboxed, iterative development and incremental delivery; Crystal adapts its practices to context; SAFe organizes work around Agile Teams, Agile Release Trains, Planning Intervals, and other coordination mechanisms
• Governance assumption — Scrum defines specific accountabilities within a self-managing team; Kanban generally starts with existing organizational roles and responsibilities; DSDM provides explicit project roles and governance mechanisms; SAFe introduces additional coordination and portfolio mechanisms for organizations operating at larger scale

Why this matters. A firm that adopts Scrum and complains that it is rigid may be confusing Scrum’s specific framework with Agile’s broader values and principles. A firm that adopts Kanban and complains that it lacks governance may be expecting a flow-management method to provide governance structures that it does not prescribe. The same governance distinction is the reason structured methods such as PRINCE2 remain relevant in regulated or public-sector environments where Agile’s team-level governance assumptions do not fit.

The position I take from this section is that the Agile method family is a set of distinct tools and frameworks. Firms should evaluate which approach fits their work, organizational context, and constraints rather than assuming that one approach is universally appropriate.

2. Scrum Is a Framework, Not a Methodology

Scrum is often described as one of the most widely used Agile approaches. More importantly, Scrum is frequently misunderstood as a complete software-development methodology. Scrum is a lightweight framework that provides a structure for addressing complex work. It does not prescribe the engineering techniques used to create the product. That distinction is central to understanding Scrum.

Definition. Scrum is a framework for developing and sustaining complex products, defined by Ken Schwaber and Jeff Sutherland in the Scrum Guide. The current official Scrum Guide is the November 2020 edition. It defines three accountabilities within the Scrum Team—Product Owner, Scrum Master, and Developers—five events—the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective—and three artifacts—the Product Backlog, Sprint Backlog, and Increment.

Scrum rests on three structural characteristics:

• Fixed-length Sprints — a Sprint is a fixed-length event of one month or less; organizations commonly use shorter Sprint lengths, but Scrum itself does not require a two-to-four-week Sprint
• Cross-functional and self-managing teams — the Scrum Team is designed to contain the skills necessary to create value each Sprint; the team is also self-managing, meaning its members decide internally who does what, when, and how
• Empiricism — Scrum is founded on transparency, inspection, and adaptation; decisions are made based on observation and learning rather than relying solely on predictive planning

The Scrum Guide explicitly defines Scrum as a framework rather than a complete development methodology. Teams can use their own practices, techniques, and processes within the framework. Scrum therefore does not prescribe how to write code, how to test software, how to design databases, or how to deploy systems.

Key point. Scrum provides a framework for managing complex product development; it is not an engineering method. Firms that expect Scrum alone to solve their engineering, architecture, or product-discovery problems may be asking the framework to address issues outside its prescribed scope.

The position I take from this section is that Scrum’s value lies partly in its deliberately limited prescription. Firms can use Scrum alongside engineering practices such as those associated with XP and alongside other product-management or governance practices where appropriate.

3. Kanban Is a Flow-Based Method, Not an Iteration System

Kanban is often described as Agile without Sprints. That description is useful as a first approximation but is incomplete. Kanban is a method for managing and improving the flow of work through a system. Its central mechanisms include visualizing work, limiting work in progress, managing flow, and making policies explicit. The current Kanban Guide describes six general practices in total.

Definition. Kanban is a method for managing and improving the flow of work through a system or value stream. Its development is associated with David J. Anderson’s work on knowledge-work Kanban, which drew on ideas from the Toyota Production System. The Kanban Guide identifies six general practices: visualize, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively and evolve experimentally.

Kanban differs from Scrum in several structural ways:

• No mandatory iterations — Kanban does not require work to be organized into fixed-length iterations; work can move continuously through the workflow
• No prescribed Scrum-style roles — Kanban does not require roles such as Product Owner or Scrum Master; existing organizational roles can remain in place while the way work flows through the system is improved
• No prescribed Scrum events — Kanban does not require a Daily Scrum, Sprint Review, or Sprint Retrospective; teams may use meetings and feedback mechanisms that fit their system

The WIP limit is an important Kanban mechanism. When a work state reaches its limit, additional work is not pulled into that state until capacity becomes available. Limiting WIP can reduce delays and context switching and can expose bottlenecks in the system. A firm that needs external governance mechanisms to complement Kanban’s flow discipline will find them in structured methods such as PRINCE2, which Kanban does not attempt to replace.

Why this matters. Kanban can be particularly useful for work that arrives continuously or unpredictably, including support, operations, maintenance, and service work. However, it is too strong to say that Kanban is inherently better for such work or that Scrum is inherently better for work that can be planned in advance. Both can be adapted to different contexts.

The position I take from this section is that Kanban and Scrum are not necessarily competing choices. Teams can use Scrum while also applying Kanban practices such as visualization and WIP limits. The important question is whether the resulting system improves transparency, flow, feedback, and delivery.

4. Extreme Programming Is an Engineering-Focused Agile Method

Extreme Programming is the Agile approach most explicitly focused on software engineering practices. It was developed by Kent Beck in the late 1990s and described in Extreme Programming Explained. The second edition was published in 2004.

Definition. Extreme Programming is an Agile software-development method built around values, principles, and engineering practices. Its commonly associated values include communication, simplicity, feedback, courage, and respect. XP places unusually strong emphasis on practices such as testing, pair programming, continuous integration, refactoring, simple design, collective code ownership, and small releases.

XP differs from Scrum and Kanban because engineering practices are central to the method:

• Test-driven development and continuous testing — XP places strong emphasis on automated testing and rapid feedback; test-first development is closely associated with modern interpretations of XP, although the original XP practice was framed more broadly around continuous testing
• Pair programming — two programmers work together on the same task, with the roles of driver and observer changing regularly; this provides continuous review and can distribute knowledge across the team
• Continuous integration — developers integrate their work frequently rather than allowing large amounts of unintegrated code to accumulate
• Refactoring — developers improve the internal structure of code without changing its externally observable behavior
• Simple design — the team seeks the simplest design that adequately meets current requirements rather than building unnecessary complexity in advance
• Collective code ownership — developers are encouraged to work across the codebase rather than treating particular sections of code as permanently owned by individuals

XP also includes practices related to planning, customer collaboration, small releases, coding standards, and sustainable development. XP can be adopted selectively, but selective adoption should not be confused with implementing the full XP method. A team that adopts some XP practices alongside Scrum is better described as using a Scrum-XP combination than as implementing XP in its entirety.

Why this matters. Engineering practices are easy to underemphasize when Agile adoption focuses primarily on planning meetings, boards, and reporting. XP is useful precisely because it puts software quality and technical feedback at the center of the development process.

The position I take from this section is that XP is an important source of engineering practices within the broader Agile ecosystem. Teams that adopt XP practices should recognize which practices they are actually using rather than assuming that adopting XP terminology constitutes adoption of the method.

5. DSDM, FDD, and Crystal Represent Different Trade-Offs

The lesser-known approaches in the Agile family—DSDM, FDD, and Crystal—represent different responses to project context. DSDM places substantial emphasis on structured project governance and delivery. FDD combines domain modeling with feature-oriented delivery. Crystal emphasizes tailoring the approach to team size and system criticality.

Definition. Dynamic Systems Development Method originated in the UK in 1994 as an approach to improving Rapid Application Development. Its current Agile Project Framework includes Pre-Project, Feasibility, Foundations, Evolutionary Development, Deployment, and Post-Project phases.

FDD, or Feature-Driven Development, is a model-driven, feature-oriented Agile approach associated with Jeff De Luca and Peter Coad. Its five processes are: Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature, and Build by Feature.

Crystal, associated with Alistair Cockburn, is a family of approaches designed to vary according to factors such as team size and system criticality. Crystal is therefore better understood as a family of context-sensitive approaches than as a single fixed method.

The approaches make different trade-offs:

• DSDM — structured project governance and delivery; DSDM provides explicit roles, lifecycle phases, products, prioritization practices, and governance mechanisms; its structure can be useful where formal project controls and business alignment are important, and its governance emphasis has more in common with PRINCE2 than with Scrum
• FDD — model-driven, feature-oriented delivery; FDD begins with an overall model and a feature list and then proceeds through design and build activities organized around features; the initial model provides shared domain understanding, but it is not necessarily a complete design frozen before development
• Crystal — contextual tailoring; Crystal does not prescribe one universal process, and its family of approaches varies according to factors such as team size and system criticality

Key point. These approaches should not automatically be dismissed because they are less prominent than Scrum or Kanban. They address different organizational and development conditions. Their usefulness depends on the context in which they are applied.

The position I take from this section is that firms should evaluate DSDM, FDD, and Crystal according to the work, constraints, team structure, and governance requirements they face rather than assuming that popularity is evidence of universal suitability.

6. Scaled Agile Framework Addresses Coordination at Scale

Scaled Agile Framework is designed to coordinate Agile product development across multiple teams and organizational levels. It addresses a different scale of coordination from a single-team framework such as Scrum.

Definition. SAFe is a framework for applying Lean, Agile, and product-development practices at organizational scale. It was created by Dean Leffingwell and was first published in 2011. SAFe 6.0 remains the current major version identified by Scaled Agile’s official documentation, with its current configuration material updated in September 2025.

The current SAFe structure should not be described simply as three levels called Team, Program, and Portfolio. SAFe 6.0 provides four configurations: Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe.

At the team and multi-team level, an important construct is the Agile Release Train. Scaled Agile defines an ART as a long-lived team of Agile teams that incrementally develops, delivers, and often operates one or more solutions. ARTs are generally made up of 50 to 125 people and are supported by roles including Product Management, System Architect, Release Train Engineer, and Business Owners.

SAFe addresses several coordination problems:

• Cross-team alignment — PI Planning brings the teams within an ART together to align on a shared mission and create a plan for the Planning Interval
• Dependency and integration management — the ART provides a structure for multiple Agile Teams working on related products or solutions
• Portfolio alignment — Portfolio SAFe provides mechanisms for connecting strategy, investment, governance, and delivery through Lean Portfolio Management

SAFe is also subject to criticism concerning its complexity, governance overhead, and implementation burden. Such criticism should be treated as an empirical or organizational question rather than as a universal property of the framework. The effect of adopting SAFe depends partly on how much of the framework an organization adopts and how well it is adapted to the organization’s context.

Why this matters. Large organizations face coordination problems that a single-team framework does not address by itself. These can include dependencies, architecture, portfolio decisions, funding, governance, and synchronization across teams. SAFe is one response to those problems, but it is not the only possible response. That coordination problem is the same one I important discussed in my post on why large projects fail, where dependencies and decision rights are recurring structural mechanisms behind failure.

The position I take from this section is that SAFe is primarily relevant when an organization needs mechanisms for coordinating multiple Agile teams and connecting delivery with broader organizational concerns. It should not be treated as a replacement for sound team-level engineering and product practices.

7. What the Method Family Shows About Agile at Scale

The Agile method family is not a menu of interchangeable equivalents. It is a collection of approaches with different purposes, structures, and degrees of prescription. Scrum provides a lightweight framework for complex product development. Kanban focuses on managing and improving flow. XP emphasizes software engineering practices. DSDM provides structured Agile project delivery. FDD organizes development around models and features. Crystal emphasizes contextual tailoring. SAFe provides mechanisms for coordinating Agile work at organizational scale.

Definition. The Agile method family can be understood as the collection of methods, frameworks, practices, and related approaches that have developed around Agile values and principles or are commonly used within the Agile ecosystem. The family includes approaches with different origins and different scopes rather than a single lineage.

The 2024 systematic literature review by Dong, Dacre, Baxter, and Ceylan examined 80 academic papers on Agile Project Management. The review was conducted across three academic databases and highlighted the continued academic interest in Agile project management, particularly as Agile practices have expanded beyond their original software-development context.

The pattern that emerges from the family is:

• Team-level approaches differ in their treatment of cadence and flow — Scrum organizes work through Sprints, while Kanban focuses on continuous flow and WIP management
• Engineering approaches differ in what they prescribe — XP emphasizes software engineering practices, while FDD combines domain modeling with feature-oriented development
• Project and governance approaches differ in their level of structure — DSDM provides explicit lifecycle and governance mechanisms, while Crystal emphasizes adaptation to team size and system criticality
• Enterprise approaches differ in how they coordinate teams and organizational concerns — SAFe provides a defined framework for coordinating Agile teams, value streams, and portfolio concerns

Key point. The Agile method family is not a hierarchy. No single approach can reasonably be described as universally correct. The relevant question is whether the approach is appropriate for the particular work, team, organization, and constraints.

The position I take from this section is that firms should treat the Agile method family as a toolkit of approaches rather than as a ranking of methods. decision is not which method is most popular but which combination of practices and structures addresses the actual problems the organization needs to solve.

Judgement

The Agile method family consists of distinct approaches that share important Agile principles but differ substantially in structure, scope, and prescription. Scrum is a lightweight framework for complex product development. Kanban is a method for managing and improving flow. XP emphasizes software engineering practices. DSDM provides structured Agile project delivery. FDD organizes development around domain models and features. Crystal emphasizes contextual adaptation. SAFe provides mechanisms for coordinating Agile work across multiple teams and organizational levels.

My position is that the Agile method family is best understood as a portfolio of approaches rather than as a set of interchangeable products. A firm that adopts Scrum because it is popular may end up implementing ceremonies without addressing its engineering or product-management problems. A firm that adopts Kanban because it wants fewer meetings may end up with a visual board without effective flow management. A firm that adopts SAFe simply because it wants to scale Agile may add organizational structures without addressing underlying team-level problems.

The strongest counterargument to my position is that the Agile ecosystem contains too many methods and that organizations may be better served by selecting one approach and implementing it consistently. I take that objection seriously. Too many choices can create unnecessary complexity, and a well-implemented approach can be more useful than an organization-wide search for the theoretically perfect method. However, the existence of multiple approaches reflects real differences in the problems they attempt to address. The practical answer is not to select methods indiscriminately but to understand what each approach actually prescribes and then determine which elements are relevant to the organization’s circumstances.

My recommendations follow from that conclusion:

• Treat the Agile method family as a toolkit rather than a menu of interchangeable approaches — choose an approach according to the work, constraints, and organizational context
• Do not confuse Agile values and principles with any particular method — Scrum, Kanban, XP, DSDM, FDD, Crystal, and SAFe are different approaches within the broader Agile ecosystem
• If adopting XP, pay attention to its engineering practices rather than adopting only its terminology — practices such as testing, pair programming, continuous integration, refactoring, and simple design are central to XP’s engineering orientation
• Match the coordination framework to the scale of the problem — SAFe is designed to coordinate multiple Agile teams and broader organizational concerns; it is not necessary for every team or organization
• Evaluate DSDM, FDD, and Crystal against the actual work and constraints — their different structures can be relevant in particular governance, domain, team-size, or criticality contexts

The final argument of this post is that the Agile method family consists of distinct approaches, and organizations that treat them as interchangeable risk adopting ceremonies and terminology without understanding the underlying practices and assumptions.

References

• Agile Alliance. Agile Essentials and Agile Manifesto resources — Agile Alliance
• Beck, K., et al. (2001). Manifesto for Agile Software Development — Agile Manifesto
• Schwaber, K., & Sutherland, J. (2020). The Scrum Guide — Scrum Guides
• Anderson, D. J. (2010). Kanban: Successful Evolutionary Change for Your Technology Business — Blue Hole Press
• Beck, K. (2004). Extreme Programming Explained: Embrace Change, 2nd Edition — Addison-Wesley
• Agile Business Consortium. The DSDM Agile Project Framework — Agile Business Consortium
• Palmer, S. R., & Felsing, J. M. (2002). A Practical Guide to Feature-Driven Development — Prentice Hall
• Cockburn, A. (2004). Crystal Clear: A Human-Powered Methodology for Small Teams — Addison-Wesley
• Leffingwell, D. (2021). SAFe 6.0 Distilled: Achieving Business Agility with the Scaled Agile Framework — Addison-Wesley
• Dong, H., Dacre, N., Baxter, D., & Ceylan, S. (2024). What is Agile Project Management? — Project Management Journal, 55(6), 668–688

Read Also on Kat-Syd Resources Hub

Agile Project Management: Origins & Limits — Iterative delivery, the 2001 Manifesto, and the challenge of scaling Agile, tested against peer-reviewed research and the Spotify case.

PRINCE2 and the Structured Governance Approach — Its UK public-sector origins, seven principles and seven practices, and where the method’s governance approach faces limits.

Why Large Projects Fail: The Structural Causes — Optimism bias, strategic misrepresentation, governance weakness, and complexity, tested against megaproject research and documented cases.

Written by Kateule Sydney — Researcher and Writer

© 2026 Kat-Syd Resources Hub. All rights reserved.

Kat-Syd Resources Hub — Educational case studies and analytical reference