Methodologies

Methodologies#

How teams structure work over time. Each methodology is a set of constraints; pick the one that fits the work, not the one that’s most fashionable.

Waterfall#

Sequential phases: requirements → design → implementation → verification → maintenance. Each completes before the next begins. The classical model, now mostly an antagonist in methodology debates, though still appropriate where requirements are genuinely fixed (regulated, embedded, fixed- contract work).

  • Originated in 1970s engineering process; named in a paper that argued against it as a model for software.

  • Strong for well-understood problems where requirements truly are fixed.

  • Brittle when requirements move during the project (which is most software).

Where it still fits: regulated, fixed-scope, fixed-deadline contracts; some embedded and aerospace work.

Agile#

A 2001 manifesto, not a method. Agile is the umbrella; Scrum, Kanban, XP, and the others below are concrete implementations. The most common pitfall is “agile” used as the name of a process while the actual values get ignored.

  • Individuals and interactions over processes and tools.

  • Working software over comprehensive documentation.

  • Customer collaboration over contract negotiation.

  • Responding to change over following a plan.

Agile is the umbrella; Scrum, Kanban, XP, and others are concrete implementations. The most common pitfall is “agile” used as the name of a process while the values are ignored.

Scrum#

A timeboxed iterative framework, by far the most common Agile implementation in 2026. Predictable cadence and structured prioritization are the wins; ceremony overhead and velocity-as-target are the failure modes most teams hit.

  • Sprints, fixed-length iterations (typically 1-4 weeks).

  • Roles, Product Owner, Scrum Master, Developers.

  • Artifacts, Product Backlog, Sprint Backlog, Increment.

  • Ceremonies, Sprint Planning, Daily Standup, Sprint Review, Retrospective.

Strengths: predictable cadence, regular feedback, structured prioritization.

Pitfalls: ceremony overhead, treating velocity as a target, refusing mid-sprint scope change when it would actually help.

Kanban#

Pull-based, continuous-flow. The board makes work visible; WIP limits keep the team from starting more than they can finish. Best fit for operational and support work where forecasting matters less than throughput. Mechanics.

  • Board with columns representing workflow stages.

  • Work In Progress (WIP) limits per column, the central mechanism.

  • No fixed iterations; work flows when capacity is available.

  • Metrics: cycle time, throughput, work age.

Strengths: minimal ceremony; matches well to operational and support work; visible bottlenecks.

Pitfalls: weak forecasting; can drift if WIP limits aren’t enforced.

Lean#

Borrowed from Toyota’s manufacturing approach. Lean Software Development (Mary and Tom Poppendieck) translated the manufacturing principles into seven software-shaped rules that have influenced most modern methodologies.

  • Eliminate waste, partially-done work, extra features, handoffs, context switches.

  • Amplify learning.

  • Decide as late as possible (commit at the last responsible moment).

  • Deliver as fast as possible.

  • Empower the team.

  • Build integrity in.

  • See the whole.

Lean Software Development (Mary and Tom Poppendieck) translates these to software. Influential on most modern methodologies.

Extreme Programming (XP)#

A 1999 method that pushed several practices to extremes; the practices below were considered radical at the time and are mostly mainstream now. The methodology as a complete package is less common; the individual practices are everywhere.

  • Pair programming.

  • Test-driven development.

  • Continuous integration.

  • Refactoring as a regular activity.

  • Small releases.

  • Simple design (“YAGNI”).

  • Collective ownership.

  • Sustainable pace (40-hour week).

  • On-site customer, a domain expert co-located with developers.

Many XP practices are now mainstream; the methodology as a complete package is less common.

Shape Up#

Basecamp’s method (2019). Six-week cycles with two-week cool-downs, written pitches with explicit “appetite” instead of estimates, and a betting table that picks pitches per cycle. Suits product teams that own outcomes; less applicable to ops or support work.

  • 6-week cycles, bigger than a sprint, smaller than a project.

  • 2-week cool-downs between cycles.

  • Pitches, written, shaped problems with appetite (time-box) and rough scope.

  • Betting table, leadership picks pitches for the next cycle.

  • No backlog in the traditional sense.

Strengths: forces upstream thinking (“shaping”); allows real problem-solving at the implementation level; reduces grooming theater.

Suits product teams that own outcomes; less applicable to ops or support.

SAFe / LeSS / Spotify#

Scaled agile frameworks for many-team organizations. The honest answer is that at scale, organization structure matters more than methodology choice (Conway’s Law); the frameworks below are different forms of the same compromise.

  • SAFe (Scaled Agile Framework), comprehensive, prescriptive, enterprise-friendly, polarizing among practitioners.

  • LeSS (Large-Scale Scrum), scrum, scaled, with a strong “less is more” stance.

  • Spotify model, squads / tribes / chapters / guilds; less a method than an org structure description.

Reality check: at scale, structure-of-organization matters more than methodology choice (Conway’s Law).

DevOps and Continuous Delivery#

Not a methodology per se, but a complementary culture and practice that wraps around whichever methodology a team has chosen. The practices below are how DevOps shows up in code; the DORA metrics are how it shows up in measurement.

  • CI/CD, automated pipelines for build, test, deploy.

  • Infrastructure as code, observability, on-call rotations.

  • You build it, you run it, developers operate what they ship.

  • The DORA metrics, deployment frequency, lead time, MTTR, change failure rate, as the standard performance signals.

Choosing#

Questions that drive the choice. The five below cover most of what differs between teams; most successful 2026 teams end up with Kanban-flavoured work, lighter Scrum-style ceremonies, and XP / DevOps engineering practices, adjusted as the team learns.

  • How well-understood are the requirements?

  • How long is the feedback loop with users?

  • How distributed is the team?

  • How much ceremony does the team tolerate?

  • What does the work flow look like, discrete projects or continuous?

Most successful 2026 teams pick Kanban-flavoured work, scrum-style ceremonies (or fewer), XP / DevOps engineering practices, and adjust without religious attachment.

Contents