Lean, XP and scaling frameworks

Scrum and Kanban are the frameworks most often named in exam questions, but agile practice draws on a wider family of ideas. Lean thinking explains why agile teams obsess over flow and waste. Extreme Programming (XP) supplies the engineering practices that let software teams change direction cheaply. Scaling frameworks try to coordinate many agile teams working on one product. This lesson surveys them at the depth the PMP exam expects: what each is for, its signature practices and when it fits.

Lean thinking

Lean grew from the Toyota Production System and was described for Western audiences in the 1990s. Its central idea is to maximize customer value while minimizing waste, by improving the flow of work through the whole value stream. Mary and Tom Poppendieck later translated lean into software development with seven principles that remain a useful summary: eliminate waste, build quality in, create knowledge, defer commitment, deliver fast, respect people and optimize the whole.

"Defer commitment" is often misunderstood. It does not mean avoiding decisions; it means not making irreversible decisions earlier than necessary, so that they can be made with better information. The last responsible moment is the point after which not deciding would eliminate an important option. For the fit-out, that moment came early, because long-lead items had to be ordered. For the app's notification provider, it came much later.

The wastes of knowledge work

Lean manufacturing identified types of waste, often remembered as transport, inventory, motion, waiting, overproduction, overprocessing and defects, with unused talent sometimes added as an eighth. The Poppendiecks mapped these to software and other knowledge work. The mapping helps you recognize waste in exam scenarios that never use the word.

Value stream mapping

A value stream map traces a piece of work from request to delivery, recording the time spent actually working on it and the time spent waiting between steps. The ratio of working time to total elapsed time is called process cycle efficiency (sometimes flow efficiency). In knowledge work it is often shockingly low, under 15 %, because items spend most of their time in queues. The Compass team mapped what happened to a typical bug reported by a patron during the pilot, from report to fix in production.

# Value stream for a patron-reported app bug, from report to fix in production (hours).
steps = [("Triage queue", 0, 30), ("Triage", 0.5, 0), ("Wait for sprint planning", 0, 120),
         ("Fix and unit test", 4, 0), ("Wait for code review", 0, 16), ("Code review", 1, 0),
         ("Wait for release window", 0, 60), ("Deploy", 0.5, 0)]
work = sum(w for _, w, _ in steps)
wait = sum(q for _, _, q in steps)
print(f"Value-adding work: {work} h; waiting: {wait} h; lead time: {work + wait} h")
print(f"Process cycle efficiency: {work / (work + wait):.1%}")
biggest = max(steps, key=lambda s: s[2])
print("Largest wait:", biggest[0], f"({biggest[2]} h)")

Value-adding work: 6.0 h; waiting: 226 h; lead time: 232.0 h
Process cycle efficiency: 2.6%
Largest wait: Wait for sprint planning (120 h)

Only six of 232 hours were spent working on the bug; the rest was waiting. The biggest wait was not in the team's coding at all but in holding the bug until the next sprint planning. Working faster would barely change the total. The team changed its policy: small defects found by patrons now go straight to the top of the sprint backlog if they take less than half a day, and releases move from a fixed fortnightly window to whenever the automated tests pass. Optimizing the whole meant fixing queues, not effort.

Extreme Programming (XP)

XP, developed by Kent Beck and colleagues in the late 1990s, takes good engineering practices and turns them up to the extreme: if code review is good, review all the time through pair programming; if testing is good, write tests first; if integration is good, integrate many times a day. XP's values are communication, simplicity, feedback, courage and respect. Many Scrum teams adopt XP's technical practices because Scrum itself says nothing about how to build software.

A related idea is technical debt: the future cost of shortcuts taken now, such as skipped tests or a quick-and-dirty design. Like financial debt, a little can be useful to hit a date, but unpaid debt accumulates interest in the form of slower and riskier change. XP practices keep debt low. In exam questions, a team whose velocity is steadily falling while defects rise often has a technical debt problem; the best answer usually involves making the debt visible to the product owner and allocating capacity to pay it down.

Other agile methods

Several other methods appear occasionally. The Dynamic Systems Development Method (DSDM), now maintained by the Agile Business Consortium, fixes time, cost and quality and varies features, and gave the world MoSCoW prioritization (must, should, could, won't have this time). Feature-Driven Development (FDD) organizes work around small client-valued features with a modelling phase and feature teams. Crystal is a family of methods scaled by team size and criticality, emphasizing people and communication. You need to recognize their names and signature ideas rather than know them in depth.

Scaling agile

A single Scrum Team of up to about ten people cannot build every product. When several teams work on one product, they need ways to coordinate backlogs, dependencies, integration and releases. Scaling frameworks offer different answers.

Scaling frameworks differ greatly in how much structure they add. LeSS tries to keep Scrum's simplicity and reorganize around customer value; SAFe provides many defined roles and events that large enterprises find familiar. Neither is automatically right. Exam questions about scaling usually reward the basics: a single, clearly ordered backlog per product, coordination of dependencies across teams, an integrated increment at least every sprint, and avoiding extra layers that slow decisions. The Compass app is a single team, so none of these frameworks was needed, but the library's later program to build apps for all branches used a Scrum of Scrums across three teams.

Choosing among the family

In practice, few teams use one method in pure form. A common combination is Scrum for the team's framework, XP practices for engineering, Kanban-style WIP limits on the task board and lean thinking for improving the end-to-end process. Exam questions rarely ask which method a team "should" adopt in the abstract; they describe a problem and ask for the next step. Match the problem to the idea that addresses it: long lead times with little hands-on work point to lean value stream thinking; rising defects and slow change point to XP practices and technical debt; unpredictable incoming work points to Kanban; coordination trouble across several teams points to scaling practices; and a team unsure of its goals and roles points back to Scrum's accountabilities and events.