XP, Lean, and Other Methodologies

Beyond Scrum/Kanban/Waterfall there are several methodologies interviewers may probe. XP (Extreme Programming) for engineering practices; Lean for the philosophical roots of much of Agile; scaling frameworks (SAFe, LeSS); and a few specialty methods.

XP — Extreme Programming

Kent Beck, 1999. The opinionated engineering side of Agile. While Scrum addresses team / process, XP addresses how engineers actually write code.

The famous practices:

XP’s bet: engineering excellence drives delivery. Scrum can be done with bad engineering practices; XP can’t.

In practice, modern teams cherry-pick:

• TDD: very common; sometimes dogmatic, often pragmatic.
• Pair programming: common in some shops (Pivotal Labs era), rarer elsewhere.
• CI: now universal.
• Continuous refactoring + simple design: common practice.

You rarely hear “we do XP” today, but most healthy engineering orgs do most of the practices.

Lean — the philosophy

From Toyota Production System (Taiichi Ohno, 1950s–80s) — eliminate waste, optimize flow. Adapted to software by Mary and Tom Poppendieck (early 2000s).

Lean’s seven wastes (in software):

Lean principles applied to software:

Kanban is essentially Lean operationalized for software. The vocabulary (WIP, flow, pull) is direct from Toyota.

SAFe — Scaled Agile Framework

Dean Leffingwell, 2011. The most popular “Agile at scale” framework in enterprises.

Adds many layers above team Scrum:

• Team level: Scrum or Kanban.
• Program level: Agile Release Train (ART) — 5–12 teams aligned around a Program Increment (PI; typically 8–12 weeks).
• Large Solution level: multiple ARTs on one product.
• Portfolio level: strategic themes, lean budgets, Epic owners.

PI Planning: a two-day event where the whole train (50–200 people) plans the next PI. Massive logistical event; often physical or hybrid.

Pros:

• Provides structure for large enterprises adopting Agile.
• Defined roles, ceremonies, artifacts — easier to roll out at scale.
• Training / certification ecosystem.

Cons:

• Heavy process — often violates Agile’s “individuals over processes.”
• Many roles (RTE, System Architect, Solution Train Engineer, Epic Owner, …).
• Critics call it “Waterfall with sprints.”
• Expensive consultants.

For an interview: know it exists, know the basic structure, have a position. Many engineers dislike SAFe; many enterprises mandate it. Show you can navigate either.

LeSS — Large Scale Scrum

Craig Larman and Bas Vodde. The minimalist alternative to SAFe.

• One Product Owner across many teams.
• One Product Backlog.
• One Sprint, synchronized across teams.
• One Sprint Review where all teams demo.
• Common Definition of Done.

Up to ~8 teams in standard LeSS; LeSS Huge for more.

Philosophy: scaling Scrum is mostly about descaling the organization (fewer roles, simpler structure) — not adding layers.

In interviews: LeSS is the “thoughtful” alternative to SAFe. Less common, more elegant.

Spotify model — a footnote

Tribes (groups of squads), squads (Scrum-ish teams), chapters (functional groups across squads), guilds (interest groups).

Famously published in two papers (Henrik Kniberg, 2012, 2014). Enterprise consultants turned it into a “model” to sell. Spotify themselves have repeatedly said: don’t copy us; we’ve evolved past this.

For interviews: know the vocabulary. Don’t recommend it without irony.

Crystal — context-sensitive methodologies

Alistair Cockburn. A family of methodologies (Crystal Clear, Crystal Yellow, …, Crystal Diamond) where the formality scales with project size and criticality.

Insight: “the right amount of process” depends on the team and project. A 4-person co-located team needs less ceremony than a 50-person distributed team building life-critical software.

Crystal is mostly an academic reference today, but the insight survives: process should fit the context.

DSDM / DAD — older frameworks

DSDM (Dynamic Systems Development Method, 1990s) and DAD (Disciplined Agile Delivery, Scott Ambler, 2010s) — both attempts at enterprise-friendly Agile. Less common in current discussions; SAFe ate their lunch.

DevOps — methodology or culture?

DevOps isn’t a development methodology per se; it’s a movement (originated ~2009) emphasizing collaboration between development and operations:

• Infrastructure as code.
• Continuous integration / continuous delivery.
• Monitoring and observability built in.
• Shared responsibility for production.

It overlaps with Agile (both are reactions to siloed waterfall structures) but is more about the dev/ops boundary than the planning model.

You can do Scrum without DevOps (long deploy cycles, separate ops team). You can do DevOps without Scrum (Kanban + CI/CD). Most modern teams do both.

The “DORA metrics” (Deployment Frequency, Lead Time for Changes, Mean Time to Recover, Change Failure Rate) are the standard DevOps performance measures.

See ../backend/27_cicd/.

CI/CD vs the methodologies

CI/CD (Continuous Integration / Continuous Delivery / Deployment) is the engineering practice underneath modern Agile. Without CI/CD, “ship every sprint” is a lie.

The methodologies depend on it:

• Scrum’s “potentially shippable increment” → requires CD.
• Kanban’s flow → broken if every deploy is a project.
• DevOps’s collaboration → built around it.

In interviews, “we do Scrum” without “and we deploy multiple times per day” raises questions about whether the team can actually deliver iteratively.

Choosing among engineering practices

The “individual practices” matter more than the methodology label. A team doing TDD + CI + code review + feature flags is high-functioning whether they call themselves Scrum, Kanban, or “we ship stuff.”

Common interview confusions

• “XP is dead.” — the label is rare; the practices (TDD, CI, refactoring) are universal in healthy teams.
• “Lean and Agile are the same.” — Agile descends partly from Lean. Lean is broader (manufacturing, services), older, focused on waste elimination.
• “SAFe is the standard for enterprise Agile.” — most-adopted in big enterprises; widely criticized by Agile practitioners. Adoption ≠ endorsement.

Interview angle

• “What’s XP?” — Extreme Programming, Kent Beck 1999. Engineering practices: TDD, pair programming, CI, refactoring, simple design, collective code ownership, sustainable pace, whole-team. Less heard as a label today; most practices are now mainstream.
• “What’s Lean development?” — Toyota Production System adapted to software (Poppendiecks, early 2000s). Eliminate waste, build quality in, defer commitment, deliver fast, respect people, optimize the whole. The philosophical root of Kanban.
• “What’s SAFe and what do you think of it?” — Scaled Agile Framework, the most popular Agile-at-enterprise framework. Adds layers (ARTs, PI Planning, Solution Trains) above team Scrum. Critics call it “Waterfall with sprints”; enterprises like it because it scales the consulting / certification ecosystem. Pragmatic answer: useful when mandated, heavyweight, often violates Agile’s “individuals over processes.”
• “LeSS vs SAFe?” — LeSS keeps Scrum simple at scale (one PO, one backlog, fewer roles). SAFe adds layers. LeSS is more philosophically Agile; SAFe is more enterprise-friendly.
• “DevOps — methodology or culture?” — culture/movement, not a development methodology. Emphasizes dev-ops collaboration, IaC, CI/CD, shared production responsibility. Complements Agile rather than replacing it.
• “What are the DORA metrics?” — Deployment Frequency, Lead Time for Changes, Mean Time to Recover (MTTR), Change Failure Rate. The four metrics from “Accelerate” research that correlate with high-performing teams.
• “Which practices matter more than the methodology label?” — TDD/automated testing, code review, CI on every change, short-lived branches, continuous delivery, feature flags. A team doing these is effective regardless of whether it calls itself Scrum or Kanban.