4.4. Components of an Adaptive Plan
💡 First Principle: "Agile" is an umbrella term for a set of values — it isn't a single framework. Scrum, Kanban, Extreme Programming (XP), and SAFe each implement those values with different structural components, built to solve different problems (team-level cadence, continuous flow, engineering discipline, and multi-team scaling, respectively).
| Framework | Core Structure | Best Fit When... |
|---|---|---|
| Scrum | Fixed-length sprints, defined roles (Product Owner, Scrum Master, Developers), set ceremonies (planning, daily standup, review, retrospective) | A single team needs a predictable, repeatable cadence |
| Kanban | Continuous flow, work-in-progress (WIP) limits, no mandated iteration length | Work arrives unpredictably and steady flow matters more than fixed cycles |
| Extreme Programming (XP) | Engineering practices — pair programming, test-driven development, continuous integration | Code quality and technical discipline are the primary risk to manage |
| SAFe (Scaled Agile Framework) | Coordinates multiple Scrum/Kanban teams across a larger program, with additional planning and synchronization layers | Several teams need to deliver a shared, interdependent product |
⚠️ Exam Trap: Scrum, Kanban, XP, and SAFe are not interchangeable synonyms for "agile." A scenario mentioning WIP limits and continuous flow (no fixed sprint length) is describing Kanban, not Scrum — even though both fall under the adaptive umbrella. Match the described structural detail to the specific framework, not just to "agile" in general.
A worked example. A scenario describes a support team that receives an unpredictable number of incoming requests each day, has no natural "sprint boundary" for that kind of work, and cares most about limiting how many tickets are open at once so nothing falls through the cracks. That's a Kanban description, not Scrum — there's no fixed-length planning cycle here, and the WIP limit is doing the coordination work a sprint boundary would do elsewhere. A different scenario describing a single product team that plans two-week cycles, holds a daily 15-minute sync, and runs a retrospective every cycle is describing Scrum's ceremony structure specifically.
Why the distinction matters beyond vocabulary. Picking the wrong framework's structure for a real team's situation isn't just a labeling error — a support team forced into fixed two-week sprints would be fighting the unpredictable, continuous nature of its actual workload. The exam tests recognizing framework fit as a practical judgment, not a matching exercise between definitions.
Frameworks can combine, and often do in practice. A single team running Scrum's sprint cadence while also adopting XP's engineering practices — pair programming and test-driven development alongside two-week sprints and a defined Scrum Master role — isn't a contradiction or a sign of confusion. The two frameworks address different dimensions of the work: Scrum structures when and how the team plans and reviews, while XP structures how well the code itself holds up. A scenario describing a team with solid Scrum ceremonies but frequent production bugs from inconsistent code quality is pointing toward adding XP practices specifically, not toward abandoning Scrum's structure entirely, since the underlying cadence isn't what's actually broken here — the gap sits specifically in engineering discipline, not in the team's planning or ceremony structure at all.
