Learning Agile: Understanding Scrum, XP, Lean, and Kanban
Source: https://www.oreilly.com/library/view/learning-agile/9781449363819/ ↗
A comparative textbook that treats Scrum, XP, Lean and Kanban as related but distinct practices, with careful attention to what each one is good at and what it is not.
The book is less polemical than most agile writing, which is its value: most teams end up with a hybrid of practices, and having a clear account of what each contributes is useful for maintenance.
For product direction it is the best reference if you are inheriting a team with a muddled process, or needing to explain the landscape to someone new.
Not a read-through; a look-up. Pair with the Agile Manifesto in its original form for the historical roots.
Central argument
Stellman and Greene argue that Scrum, XP, Lean, and Kanban are not interchangeable labels for 'doing agile' but distinct systems with different underlying assumptions, mechanisms, and appropriate contexts. The central thesis is that understanding what each practice is specifically designed to solve — Scrum for iterative delivery under uncertainty, XP for engineering discipline, Kanban for flow management, Lean for waste reduction — allows teams to make deliberate choices rather than cargo-culting a methodology. The book presents these frameworks comparatively rather than advocating for any single one, positioning informed hybrid adoption as the mature outcome.
Critique
The comparative, reference-oriented structure means the book largely describes each framework on its own terms without seriously interrogating the empirical evidence for their claimed benefits — readers are shown what each practice prescribes, not whether it consistently produces better outcomes in practice. By 2015, research on agile effectiveness was already contested enough that a rigorous treatment would have needed to engage with it. This absence of critical evidence-weighing risks reinforcing the assumption that the frameworks themselves are sound and the only variable is correct application.
Why it matters for product
For a product leader inheriting a team whose process is a sediment of half-adopted rituals — Scrum ceremonies with no real sprint goals, Kanban boards used as Jira wallpaper — having a precise account of what each practice is actually for enables a diagnostic conversation rather than a rebranding exercise. It is also directly useful when onboarding a new engineering lead or VP of Product who needs a shared vocabulary fast: the book functions as a reference document that can anchor that alignment without requiring everyone to read it cover to cover.