Agile is an umbrella term for iterative, customer-feedback-driven approaches to software development and project management. Under that umbrella exist many specific methodologies — Scrum, Kanban, Extreme Programming (XP), Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), Lean Software Development, Crystal Family, Feature-Driven Development (FDD), Dynamic Systems Development Method (DSDM), and Disciplined Agile (DA). Each methodology applies the agile philosophy through different specific practices, roles, and ceremonies. Choosing the right methodology for your team and context matters substantially because the methodologies optimise for different conditions. The broader Agile page covers the underlying philosophy that all these methodologies share.
Scrum dominates adoption at roughly 70 percent of agile teams using some form of Scrum. Kanban is second-most-common, particularly for support and operations teams. XP, SAFe, and others occupy specific niches. The dominance of Scrum reflects a combination of factors — well-defined structure that makes adoption straightforward, strong certification ecosystem, broad training availability, and good fit for product development teams of 5-9 people. The other methodologies fill gaps where Scrum does not fit naturally: continuous-flow work, very large enterprise scaling, engineering-quality focus, or specific organisational constraints.
Understanding the trade-offs between methodologies matters because mixing or switching between them without coherent strategy produces worse outcomes than committing to one and applying it well. The Agile Approach overview covers the philosophy; the specific methodologies covered here translate philosophy into actionable practices. Agile Certification programs typically focus on specific methodologies (CSM and PSM for Scrum, SAFe certifications for the SAFe framework, etc.), helping practitioners develop expertise in their chosen approach.
The proliferation of agile methodologies sometimes confuses newcomers who expect a single "agile" approach. This is partly because agile emerged from convergence of multiple existing methodologies that shared key principles. The 2001 Agile Manifesto was signed by practitioners of Scrum, XP, Crystal, DSDM, Adaptive Software Development, and Pragmatic Programming — each bringing their own specific practices to the broader agile movement. The methodologies continue to evolve and combine; new variants emerge regularly as practitioners adapt approaches to their specific contexts.
Scrum: Most popular ~70%, sprints (2 weeks), defined roles, ceremonies. Kanban: Flow-based, WIP limits, continuous delivery. XP (Extreme Programming): Engineering practices (TDD, pair programming, CI). SAFe: Enterprise scaling, program increments, release trains. LeSS: Lighter alternative for scaled Scrum. Lean: Eliminate waste, deliver fast, build quality in. Crystal: Family adapted to project size (Clear, Yellow, Orange, Red). FDD: Feature-Driven Development with 5 processes. DSDM: 8 principles, MoSCoW prioritisation, time-boxing. Disciplined Agile: Toolkit combining multiple methods.
Scrum structures work into fixed-length iterations (sprints) typically 2 weeks long. Three roles drive the framework — Product Owner (manages the prioritised backlog), Scrum Master (facilitates the process and removes obstacles), Development Team (cross-functional team that builds the product). Five events organise the sprint cycle: Sprint Planning (commits to sprint goals), Daily Scrum (15-minute coordination), Sprint Review (demonstrates completed work to stakeholders), Sprint Retrospective (improves the team's process), and the Sprint itself as the container event.
Three artifacts capture work — Product Backlog (prioritised list of all work), Sprint Backlog (work committed for this sprint), Increment (completed work delivered each sprint).
Scrum's strength is its well-defined structure. Teams adopting Scrum have clear roles, ceremonies, and artifacts that guide the work. The structure produces predictable rhythm and visible progress that stakeholders find reassuring. The downside of the structure is rigidity — Scrum works best for product development with predictable sprint-able work; it adapts less well to interrupt-driven support work, very large programs, or pure engineering practices that need different optimisation. Most agile transformations start with Scrum because of its structure and broad familiarity; teams sometimes evolve beyond Scrum to other methodologies as they mature.
Scrum certification ecosystem is the strongest of any agile methodology. Certified Scrum Master (CSM), Professional Scrum Master (PSM), and Certified Scrum Product Owner (CSPO) certifications are widely recognised by employers. The certifications cover Scrum framework, roles and responsibilities, ceremonies, and common scaling considerations. CSM through Scrum Alliance and PSM through Scrum.org are the two most popular certification paths. Many career paths in agile coaching, project management, and product management benefit from holding these certifications, particularly when transitioning from non-agile backgrounds.
The Scrum Guide is the definitive description of Scrum, freely available at scrumguides.org. The current version is short (around 20 pages) and describes the framework without detailed prescription on how to implement each practice. The brevity is intentional — Scrum provides structure but leaves implementation details to the team. This produces variation across organisations using Scrum; what works as Scrum at one company may differ substantially from another. Reading the Scrum Guide directly produces better understanding than reading derivative explanations.
Iterative, time-boxed sprints with defined roles and ceremonies. Best for product development teams where work can be planned in 2-week iterations. The dominant methodology for software product development. Strong certification ecosystem makes adoption and hiring straightforward. Less effective for support, operations, or very large programs.
Flow-based with work-in-progress limits rather than time-boxed iterations. Visualises work on a board with columns representing work states. Best for teams with continuous incoming work that does not naturally fit iteration boundaries — support teams, operations, maintenance. Less ceremony than Scrum, easier to adopt incrementally.
Focused on technical practices — test-driven development, pair programming, continuous integration, refactoring, simple design, collective code ownership. Sometimes used alongside Scrum (Scrum for project management, XP for engineering). Many modern software engineering practices originated in XP and are now common across agile approaches even when XP itself is not formally adopted.
Scaled Agile Framework for applying agile at enterprise scale. Defines program-level constructs (Program Increments, Release Trains) above team-level Scrum. Adopted by large enterprises with hundreds or thousands of practitioners. Controversial — supporters value scaling structure; critics argue it adds bureaucracy. SAFe certification ecosystem is its own substantial industry.
Alternative scaling framework that keeps Scrum simple at team level and adds minimal coordination structure between teams. Less prescriptive than SAFe. Suitable for organisations wanting scaled agile without SAFe's structural overhead. Best for 50-500 practitioner organisations. Smaller adoption than SAFe but growing.
Adapted from Toyota Production System manufacturing principles. Seven principles: eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people, optimise the whole. Influential on broader agile thinking. Often used alongside other methodologies rather than as standalone framework. Excellent for cost-conscious environments where reducing waste matters.
Kanban originated in Toyota's manufacturing system and was adapted for software work by David Anderson and others. Unlike Scrum's time-boxed sprints, Kanban uses continuous flow — work moves through the system as capacity allows.
The methodology visualises work on a Kanban board with columns representing work states (To Do, In Progress, Code Review, Testing, Done). Work-in-progress (WIP) limits constrain how many items can be in each state simultaneously, preventing the team from starting more work than it can complete. The WIP limits are Kanban's core innovation — they force the team to finish work before starting new work, reducing context-switching and incomplete work accumulation.
Kanban suits teams with continuous incoming work that does not fit naturally into 2-week iterations. Support and operations teams that respond to user-generated tickets work well in Kanban. Maintenance teams handling production issues use Kanban effectively. Some product teams adopt Kanban after Scrum when they reach maturity where time-boxed planning no longer adds value compared to continuous flow. The lower ceremony of Kanban (no daily standups required, no sprint reviews, no retrospectives required) attracts teams that find Scrum's ceremonies excessive. Many teams add lightweight versions of standups and retrospectives even within Kanban for the team-building benefits.
Kanban's cumulative flow diagrams provide visual analytics on team performance. The diagrams show how many work items are in each state over time, revealing bottlenecks where work accumulates and capacity issues where work flows too slowly through certain stages. Teams using Kanban analytics often identify specific stages where investment in additional capacity or skill development produces the largest throughput improvements. The analytical focus distinguishes Kanban from Scrum's velocity tracking, which measures completion without revealing where work spends its time.
Family of methodologies developed by Alistair Cockburn. Crystal Clear (1-8 person projects), Crystal Yellow (10-20), Crystal Orange (20-50), Crystal Red (50+). Each version adapts ceremony weight to project size — smaller projects use less structure, larger projects add more. Emphasis on people and communication rather than processes. Influenced broader agile thinking even though direct Crystal adoption is rare. Cockburn's writings on human factors in software development remain influential.
Created by Jeff De Luca and Peter Coad in 1997. Five processes: Develop Overall Model, Build Features List, Plan By Feature, Design By Feature, Build By Feature. Heavy emphasis on domain modeling upfront and feature-by-feature implementation. Used in some enterprise contexts where domain complexity drives the work pattern. Less common than Scrum or Kanban but well-suited to specific situations involving complex domain models.
Originated in UK in 1994, predates the Agile Manifesto. Eight principles emphasise active user involvement, frequent delivery, time-boxing, iterative development. Uses MoSCoW prioritisation (Must, Should, Could, Won't). Includes more roles than Scrum (Business Sponsor, Visionary, Ambassador User, Advisor User, Solution Developer, etc.). Common in some European enterprises and government projects. Less adoption in the US than Scrum.
Created by Scott Ambler and Mark Lines, now owned by Project Management Institute (PMI). Hybrid framework that combines elements from Scrum, XP, Kanban, Lean, and others. Provides decision frameworks for choosing which practices fit specific contexts rather than prescribing single approach. Suitable for organisations wanting flexibility to combine practices. DA certifications offered by PMI alongside their other project management credentials.
Adapted from Toyota Production System by Mary and Tom Poppendieck. Seven principles influential on broader agile thinking. Often used alongside other methodologies rather than as standalone framework. Eliminate waste (anything not adding customer value), build quality in (avoid rework), create knowledge (learn through experimentation), defer commitment (decide last responsible moment), deliver fast (short cycles), respect people (empowered teams), optimise the whole (system-level thinking).
Hybrid combining Scrum and Kanban. Maintains Scrum's roles and some ceremonies while adding Kanban's WIP limits and flow visualisation. Useful for teams transitioning from pure Scrum to flow-based work without abandoning the Scrum structure entirely. Sometimes called "Scrum with Kanban practices." Adopted by many teams that find pure Scrum too rigid but want more structure than pure Kanban.
XP was developed by Kent Beck in the late 1990s and codified in his 1999 book "Extreme Programming Explained." Where Scrum focuses on project management practices, XP focuses on engineering practices that produce high-quality code.
The core XP practices include test-driven development (write tests before code, refactor mercilessly), pair programming (two developers at one workstation, swapping driver and navigator roles), continuous integration (merge code changes frequently to detect integration issues early), refactoring (continuously improve code structure without changing behaviour), simple design (build only what is needed now, not what might be needed later), and collective code ownership (any team member can modify any part of the codebase).
Many modern software engineering practices originated in XP and are now common across agile teams even when XP itself is not formally adopted. Test-driven development is widely practiced in software companies regardless of methodology framework. Continuous integration is foundational to DevOps practice. Refactoring tools and techniques developed in XP shaped modern IDE features. Pair programming remains somewhat controversial — strong advocates praise the quality benefits; critics note the apparent doubled cost. The actual research on pair programming productivity is mixed; teams that use it well report better outcomes than teams without it, but adoption depends on team culture.
XP's planning game predates Scrum's sprint planning but addresses similar concerns. The planning game involves customers writing user stories on index cards, developers estimating effort, and the planning emerging from negotiation between business priorities and engineering effort. Scrum's product backlog and sprint planning evolved from these concepts. The lineage from XP into modern Scrum practices is substantial; many teams using Scrum are unknowingly applying XP-derived practices in their planning sessions.
The Scaled Agile Framework (SAFe) addresses agile at enterprise scale — programs with multiple teams (often 50-500+ practitioners) working on related products that require coordination beyond what single Scrum teams can manage independently. SAFe defines program-level constructs above team-level Scrum: Agile Release Trains (ARTs) coordinate 50-125 practitioners across multiple teams, Program Increments (PIs) provide 8-12 week planning cadence across the ART, PI Planning brings hundreds of practitioners together for synchronised planning, and Solution Trains coordinate multiple ARTs for very large products requiring 250-500+ practitioners.
SAFe is controversial within the agile community. Supporters value the explicit scaling structure that addresses real coordination challenges in large enterprises. Critics argue SAFe adds substantial bureaucracy that contradicts agile values of light-weight processes. Both perspectives have merit — SAFe works well for large enterprises with substantial coordination needs but can feel heavy for smaller organisations that adopted it without needing its full scope.
SAFe certification ecosystem is its own substantial industry with multiple certifications (SAFe Practitioner, SAFe Scrum Master, SAFe Product Owner, SAFe Program Consultant, SAFe Architect, etc.). Many large enterprises require SAFe certification for specific roles, making it a substantial credential for practitioners working in those environments.
The PI Planning event in SAFe is one of the most distinctive practices in scaled agile. Hundreds of practitioners gather for 2 days to plan the next 8-12 weeks of work across multiple teams. The synchronised planning produces shared understanding, identifies dependencies, and creates commitments across the program. Critics argue the event is expensive in time and coordination overhead; supporters argue it produces alignment that distributed planning cannot achieve. Major enterprises using SAFe build PI Planning into their operating rhythm.
Large-Scale Scrum (LeSS) is an alternative scaling framework that keeps Scrum simple at the team level and adds minimal coordination structure between teams. LeSS comes in two configurations — LeSS (2-8 teams, up to 50 practitioners) and LeSS Huge (8+ teams, hundreds of practitioners). The framework emphasises single Product Owner across teams, single Product Backlog, synchronised sprints across teams, joint Sprint Planning, and Overall Retrospective involving representatives from all teams. The deliberate simplicity contrasts with SAFe's more elaborate scaling structures.
LeSS suits organisations that want scaled agile without SAFe's structural overhead. Many practitioners prefer LeSS philosophically because it stays closer to agile manifesto principles than SAFe's elaborate structure. The smaller adoption (versus SAFe) reflects partly the lack of LeSS's marketing reach and certification ecosystem, partly the genuine preference of some enterprises for SAFe's more prescriptive structure. Both LeSS and SAFe can work; choosing between them depends on the organisation's specific needs and cultural preferences around process formality.
The LeSS Huge configuration handles even larger organisations — hundreds of practitioners or thousands when needed. The approach divides large product organisations into Requirement Areas (logical product divisions) with multiple teams per area, single Product Owner per area, and Area Product Backlogs feeding the overall Product Backlog. The structure scales further than basic LeSS while maintaining the philosophical preference for simplicity over elaborate process structure that distinguishes LeSS from SAFe.
Survey data from various agile community sources consistently shows Scrum at roughly 70 percent adoption among agile teams. Kanban is second at 10-15 percent (some use it alongside Scrum). SAFe is third at 5-10 percent of agile practitioners (representing a substantial share of the largest enterprises specifically). XP is rarely the primary methodology but is widely incorporated as engineering practices alongside Scrum or Kanban. The other methodologies (LeSS, Crystal, FDD, DSDM, Disciplined Agile) each have smaller adoption shares but maintain dedicated practitioner communities.
Regional adoption patterns vary substantially. Scrum dominates globally but with regional preferences for specific certifications (Scrum Alliance CSM in some regions, Scrum.org PSM in others). SAFe adoption is strongest in North American and European enterprises. DSDM has stronger UK and European presence than US presence. Crystal influenced thinking broadly but is rarely directly adopted. Choosing methodology partly reflects local certification and training availability — using a methodology with limited local support adds friction.
Some organisations adopt Scrum because it is most popular rather than because it fits their work pattern. Support teams forced into 2-week sprints to satisfy management's Scrum mandate often produce worse outcomes than they would in Kanban. Matching methodology to work pattern matters more than following the popularity contest. Honest assessment of what actually fits versus what is fashionable produces better outcomes.
Some large enterprises adopt SAFe before any team has mastered Scrum-level agile fundamentals. Building scaling structure on shaky single-team foundations produces complex problems. Master single-team agile first then add scaling carefully. Skipping this sequence usually produces failure attributed to the methodology rather than to skipping the foundation. Sequential adoption matters more than parallel deployment.
Teams that adopt Scrum's standups but skip retrospectives, take Kanban's board but ignore WIP limits, mention TDD but do not actually do it — produce inconsistent results worse than committing to one methodology fully. Coherent application of a single methodology for 6-12 months produces better outcomes than pieced-together hybrid approaches. Mature teams sometimes blend effectively, but this comes from deep understanding rather than initial mixing.
Methodology choice matters but is not the whole answer to organisational agility. Culture (psychological safety, empowerment, customer focus), engineering practices (code quality, automation, DevOps), product strategy (what to build), and team skills all contribute to agile success. Treating methodology adoption as the silver bullet leads to disappointment when the methodology alone does not transform the organisation. Methodology is the structure that holds other practices together.
Scrumban is the most common hybrid agile methodology, combining Scrum's roles and some ceremonies with Kanban's WIP limits and continuous flow. Teams transitioning from Scrum sometimes adopt Scrumban as a middle step toward pure Kanban. Other teams use Scrumban as their stable end-state, finding the combination produces better outcomes than either pure approach. The hybrid maintains the team identity and accountability of Scrum while gaining the flow benefits and reduced ceremony of Kanban. Many mature agile teams operate in Scrumban form whether or not they call it that explicitly.
Beyond Scrumban, mature agile teams often combine practices from multiple methodologies based on their specific needs. Scrum for project management plus XP for engineering practices is a common combination. Kanban for support work plus Scrum for product development at the same organisation is another common pattern. Disciplined Agile explicitly embraces the toolkit approach where practices are selected from across methodologies based on context. The toolkit approach requires mature understanding of why each practice matters — applying it without that understanding produces the failed mixing pattern that the alert warned against.
The maturity question matters substantially for hybrid approaches. New agile teams should generally adopt one methodology fully and apply it consistently for 6-12 months. The discipline of consistent application develops understanding that informs later evolution. Mature teams with deep methodology understanding can blend practices effectively because they understand why each practice matters. Skipping the foundational discipline and going straight to hybrid usually produces piecemeal adoption with worse outcomes than committed application of any single methodology.
Choosing methodology is less consequential than committing fully to whichever one you pick and applying it with discipline over time. Methodology pedigree matters less than execution quality.
Scrum, used by roughly 70 percent of agile teams. Its dominance reflects a combination of factors — well-defined structure that makes adoption straightforward, strong certification ecosystem (CSM, PSM, CSPO certifications widely recognised), broad training availability, and good fit for product development teams of 5-9 people. Kanban is second-most-common, particularly for support and operations teams. SAFe dominates the large-enterprise segment but represents a smaller share of total agile teams.
Scrum is iteration-based with fixed 2-week sprints, defined roles (Product Owner, Scrum Master, Development Team), and ceremonies (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective). Kanban is flow-based with continuous work intake limited by work-in-progress (WIP) limits. Scrum suits product development with prioritised backlogs and fixed-cadence delivery. Kanban suits operations and support work where new requests arrive continuously. Many teams use Scrumban — a hybrid combining both.
Scaled Agile Framework (SAFe) is a framework for applying agile at enterprise scale — programs with multiple teams (50-500+ practitioners) working on related products requiring coordination beyond single-team agile. Defines program-level constructs (Agile Release Trains, Program Increments) above team-level Scrum. Best for large enterprises with substantial coordination needs. Critics argue SAFe adds bureaucracy that contradicts agile values; supporters value the explicit scaling structure. Use when single-team Scrum cannot handle the coordination complexity at your scale.
Extreme Programming (XP) is an agile methodology focused on engineering practices — test-driven development, pair programming, continuous integration, refactoring, simple design, collective code ownership. Many XP practices have become standard across modern software engineering even where XP itself is not formally adopted. XP is rarely the primary methodology for project management today but remains relevant as a source of engineering practices that pair well with Scrum or Kanban for high-quality software development.
Yes — the hybrid is called Scrumban. Maintains Scrum's roles and some ceremonies (typically standups and retrospectives) while adding Kanban's WIP limits and flow visualisation. Useful for teams transitioning from Scrum to Kanban or finding pure Scrum too rigid but wanting more structure than pure Kanban. Many mature agile teams operate in Scrumban form. Less prescriptive than pure Scrum, more structured than pure Kanban. Works best when the team understands why each practice matters before combining.
Depends on team size, work pattern, organisational maturity, and engineering needs. Product development team of 5-9 people: Scrum. Continuous support or operations work: Kanban. Engineering-quality focus: add XP practices alongside chosen primary methodology. Enterprise with 50+ practitioners across multiple related teams: SAFe or LeSS. Mature team wanting flexibility: Disciplined Agile toolkit approach. Pilot with one team for 6-12 months before broader rollout. Match methodology to context rather than chasing popularity.