ManagementSubsection
Methodologies
How a team decides what to build next, in what order, and how it knows when something is done. Nine methodologies, from the two most teams actually run to the four that exist because one team stopped being enough. Each page describes what the framework actually defines — every ceremony, every role, every artefact — rather than summarising it, and says plainly where it stops working.
What is inside
Every page in this group, with what each one covers.
- AgileThe four values and twelve principles everything else here is built on — and what they never said.ManifestoPrinciples
- ScrumEvery event, role and artefact the Scrum Guide defines, including the four most teams quietly skip.Sprint3 roles
- KanbanFlow instead of iterations: WIP limits, the seven cadences, classes of service and the cumulative flow diagram.WIP limitsFlow
- ScrumbanWhat you get by keeping Scrum’s ceremonies and Kanban’s flow — and which combinations produce neither.HybridPull
- WaterfallThe model everyone cites as the mistake, described accurately — and the cases where it is still the right answer.PhasesFixed scope
- SAFeScaling to 50–200+ people: four configurations, the ART, PI planning, the IP iteration and all ten principles.ART50–200+
- LeSSScaling by removing rather than adding: LeSS Basic for 2–8 teams, LeSS Huge beyond, and all ten principles.2–8 teamsDescaling
- NexusThree to nine Scrum teams on one product, and the Integration Team whose job is the dependencies between them.3–9 teamsIntegration
- Scrum@ScaleTwelve components on two cycles — the how and the what — with the executives inside, as two Scrum teams.Two cycles12 components
Where to start
- New to all of thisAgile first for the values, then Scrum for the mechanics — most teams you join will be running some version of it.
- Your sprints keep spillingRead Kanban. Work in progress, not estimation accuracy, is what makes a sprint fail to finish.
- More than one team, one productStart with Nexus for three to nine teams; SAFe and LeSS answer the same question at very different sizes.
Elsewhere in the section
- ManagementIT project management is the set of decisions that turn an intention into shipped software: what to build, how to cut it into work that can actually be finished, how the team runs itself week to week, and how the result reaches users. This section covers 25 topics in six groups — product management, decomposition, methodologies, the release process, the formal frameworks, and the craft of running a project rather than a method for running one — and each page gives the trade-off behind the choice rather than a summary for a certification exam.
- DecompositionTurning something too big to start into pieces small enough to finish — and keeping the reason for each piece attached to it on the way down. Four topics covering the two traditions that rarely meet: work breakdown from project management, and user stories from product. They answer different questions, and knowing which one you are in stops most arguments about how detailed a plan should be.
- FrameworksThe two bodies of project management practice you will meet in a tender document, a certification requirement or a client’s process manual. They are not competitors: one is a body of knowledge describing what to think about, the other is a method prescribing who decides what. Both pages describe what the current edition actually says, and the comparison between them is the argument most people have without it.
Found this useful?
Share it with someone who is working on the same problem.