Hoofdstuk 1 — Inleiding: van Agile naar Scrum

Organisaties die software of digitale producten bouwen, werken vandaag de dag bijna altijd volgens een of andere vorm van "Agile werken". De term is echter zo ingeburgerd geraakt dat de betekenis ervan soms vervaagt: is Agile een methode, een mindset, een verzameling ceremonies, of gewoon een ander woord voor "flexibel"? En hoe verhoudt Scrum — waarschijnlijk het bekendste Agile-framework — zich tot dat bredere gedachtegoed?

Dit boek beantwoordt die vragen in twee lagen. Eerst behandelen we Agile als filosofie: waar het vandaan komt, welke waarden en principes eraan ten grondslag liggen, en welke raamwerken er naast Scrum bestaan. Daarna duiken we diep in Scrum zelf: de rollen, events, artefacten en de praktische vaardigheden die nodig zijn om er als team daadwerkelijk beter van te worden — niet als doel op zich, maar als middel om sneller waarde te leveren en beter om te gaan met onzekerheid.

Voor wie is dit boek? Voor iedereen die met Scrum-teams werkt of gaat werken: developers, product owners, scrum masters, engineering managers en iedereen die zich afvraagt waarom een team ineens "sprints" doet in plaats van een projectplanning van zes maanden.

Hoofdstuk 2 — Waarom traditioneel projectmanagement vaak tekortschiet

Bij traditioneel, watervalgebaseerd projectmanagement wordt een project vooraf volledig gepland: eerst worden alle eisen vastgelegd, dan wordt er ontworpen, vervolgens gebouwd, getest en pas aan het einde opgeleverd. Dit model werkt goed wanneer de eisen stabiel en volledig te voorspellen zijn — bijvoorbeeld bij de bouw van een brug. Software-ontwikkeling voldoet echter zelden aan die voorwaarde.

Drie problemen komen keer op keer terug bij een puur voorspellende aanpak:

• Eisen veranderen. Gebruikers weten vaak pas precies wat ze willen nadat ze een eerste versie hebben gezien en gebruikt. Bij een waterval-aanpak komt die feedback pas aan het einde — te laat om nog goedkoop bij te sturen.
• Risico wordt laat zichtbaar. Integratieproblemen, technische risico's en verkeerde aannames komen vaak pas aan het licht tijdens het testen, wanneer bijsturen het duurst is.
• Voortgang is moeilijk te meten. "90% klaar" bij een waterval-project zegt weinig; er is geen werkend product om tussentijds te valideren.

Agile werken pakt dit anders aan: in plaats van in één keer een compleet plan uit te voeren, wordt werk opgeknipt in kleine, waardevolle stukken die snel worden opgeleverd, getest en beoordeeld. Zo ontstaat vroegtijdig feedback, en kan koers worden bijgesteld zolang dat nog relatief goedkoop is.

Hoofdstuk 3 — Het Agile Manifesto: waarden en principes

In 2001 kwamen zeventien softwareontwikkelaars — afkomstig uit uiteenlopende, destijds concurrerende lichte ontwikkelmethoden — samen in Snowbird, Utah, en formuleerden het Manifesto for Agile Software Development. Dit korte document bevat vier kernwaarden die de basis vormen van alle Agile-raamwerken, inclusief Scrum.

Belangrijk is de nuance: het manifesto zegt niet dat processen, documentatie, contracten en plannen waardeloos zijn — het zegt dat de items aan de linkerkant meer waarde hebben wanneer je moet kiezen. Naast deze vier waarden bevat het manifesto twaalf onderliggende principes, waarvan een aantal in de praktijk het meest richtinggevend blijkt:

• "Onze hoogste prioriteit is het tevredenstellen van de klant door vroege en continue levering van waardevolle software."
• "Verwelkom veranderende eisen, zelfs laat in de ontwikkeling."
• "Lever regelmatig werkende software op, met een voorkeur voor een kortere tijdspanne."
• "Bouw projecten rond gemotiveerde individuen. Geef ze de omgeving en steun die ze nodig hebben, en vertrouw erop dat ze het werk gedaan krijgen."
• "Regelmatige reflectie op hoe een team effectiever kan worden, gevolgd door aanpassing van gedrag."

Hoofdstuk 4 — Agile raamwerken naast Scrum

Scrum is verreweg het bekendste Agile-framework, maar zeker niet het enige. Om Scrum goed te kunnen plaatsen, is het nuttig kort de belangrijkste alternatieven en aanvullingen te kennen.

Kanban

Kanban komt oorspronkelijk uit de Lean-productiefilosofie van Toyota en richt zich op het visualiseren van werk op een bord met kolommen (bijvoorbeeld "To do", "In progress", "Done") en het beperken van werk-in-uitvoering (work in progress limits). In tegenstelling tot Scrum kent Kanban geen vaste iteraties: werk stroomt continu door het systeem.

Extreme Programming (XP)

XP legt sterk de nadruk op technische discipline: test-driven development, pair programming, continue integratie en eenvoud van ontwerp. XP wordt vaak gecombineerd mét Scrum: Scrum regelt het proces en de samenwerking, XP levert de technische praktijken om kwaliteit hoog te houden bij hoge leversnelheid.

Lean

Lean draait om het elimineren van verspilling (waste) in het hele ontwikkelproces: onnodig werk, wachttijden, overdrachten en onvolledig werk. Veel Agile-principes — kleine batches, snelle feedback, continue verbetering — zijn direct afgeleid van Lean-denken.

Hoofdstuk 5 — Scrum: het framework in het kort

Scrum is een lichtgewicht framework dat teams helpt complexe problemen op te lossen en tegelijk producten van hoge waarde te leveren. Het is bewust geen volledige methodologie met voorgeschreven technieken — Scrum geeft een minimale set spelregels (rollen, events, artefacten) en laat teams zelf invullen hoe ze het werk concreet uitvoeren.

Scrum is gebaseerd op empirisme: kennis komt voort uit ervaring, en beslissingen worden genomen op basis van wat daadwerkelijk waargenomen wordt. Dit rust op drie pijlers:

• Transparantie — het proces en het werk moeten zichtbaar zijn voor iedereen die verantwoordelijk is voor het resultaat.
• Inspectie — voortgang en artefacten worden regelmatig gecontroleerd om ongewenste afwijkingen te signaleren.
• Adaptatie — als een afwijking wordt gesignaleerd, wordt het proces of het product zo snel mogelijk aangepast.

Het hele framework draait om deze herhalende cyclus: een team plant een sprint, voert die uit met dagelijkse afstemming, laat aan het einde het resultaat zien, en reflecteert op hoe het samenwerkingsproces te verbeteren is — waarna de cyclus opnieuw begint. Deze regelmaat is precies wat empirische procescontrole in de praktijk mogelijk maakt: elke paar weken is er een natuurlijk moment om te inspecteren en bij te sturen.

Hoofdstuk 6 — Scrum-rollen

Scrum kent een klein, bewust beperkt aantal rollen. Samen vormen zij het Scrum Team: een zelforganiserend, cross-functioneel team zonder sub-teams of hiërarchie binnen het team zelf.

Product Owner

De Product Owner is verantwoordelijk voor het maximaliseren van de waarde van het product dat voortkomt uit het werk van het Scrum Team. Dit gebeurt vooral door het beheren van de Product Backlog: prioriteren, verhelderen, en zorgen dat iedereen begrijpt wat de belangrijkste items zijn en waarom. Een veelgemaakte misvatting is dat de Product Owner "de baas" van het team is — in werkelijkheid is de rol vooral gericht op het wat en waarom, niet op het hoe.

Scrum Master

De Scrum Master is verantwoordelijk voor het effectief maken van het Scrum Team. Dit gebeurt door het team te coachen in zelforganisatie en cross-functionaliteit, obstakels weg te nemen, en de organisatie te helpen begrijpen hoe ze het beste met het team kan samenwerken. De Scrum Master is geen projectmanager en geeft het team geen opdrachten — de rol is dienend leiderschap (servant leadership).

Developers

De Developers zijn de mensen in het Scrum Team die zich toeleggen op het creëren van elk aspect van een bruikbaar Increment per sprint. Deze rol omvat alle vaardigheden die nodig zijn om een product te bouwen — ontwerp, bouw, testen — ongeacht de specifieke functietitel van een teamlid. Developers plannen zelf hun werk binnen een sprint; niemand anders (ook de Product Owner niet) vertelt hen hoe ze backlogitems om moeten zetten in een werkend Increment.

Hoofdstuk 7 — Scrum-events in detail

Scrum kent vijf events, elk met een vast maximum aan tijd (timebox) en een duidelijk doel. Samen zorgen ze voor regelmatige inspectie en adaptatie, zonder dat er behoefte is aan extra, ongeplande vergaderingen.

De Sprint

De Sprint is de "container" voor alle andere events: een vaste periode van doorgaans één tot vier weken waarin een "Done", bruikbaar en potentieel uitleverbaar productincrement wordt gecreëerd. Sprints hebben een consistente duur gedurende een ontwikkeltraject, wat een vast ritme creëert. Tijdens een sprint worden geen wijzigingen doorgevoerd die het Sprint Goal in gevaar brengen; de scope mag wel worden verduidelijkt en heronderhandeld tussen Product Owner en Developers naarmate er meer bekend wordt.

Sprint Planning

Aan het begin van elke sprint bepaalt het Scrum Team het werk dat in de aankomende sprint wordt uitgevoerd. Dit gebeurt in drie stappen: waarom is deze sprint waardevol (Sprint Goal), wat kan er Done gemaakt worden (welke Product Backlog-items), en hoe gaat het gekozen werk worden gerealiseerd.

Daily Scrum

Een dagelijkse, 15 minuten durende bijeenkomst voor de Developers om voortgang richting het Sprint Goal te inspecteren en het plan voor de komende 24 uur aan te passen. Het is uitdrukkelijk geen statusrapportage aan de Scrum Master of Product Owner, maar een planningsmoment van en voor de Developers zelf.

Sprint Review

Aan het einde van de sprint wordt het resultaat van het werk gepresenteerd aan belanghebbenden, en wordt besproken wat er is bereikt en wat de omgeving inmiddels heeft veranderd. Dit is een werksessie, geen presentatie zonder discussie — feedback van stakeholders voedt direct de volgende Product Backlog-aanpassingen.

Sprint Retrospective

Het Scrum Team evalueert hoe de afgelopen sprint verliep op het gebied van individuen, interacties, processen, tools en de Definition of Done, en identificeert verbeteringen om in de volgende sprint door te voeren. Dit is het moment waarop het team expliciet aan zijn eigen samenwerkingsproces werkt, niet alleen aan het product.

Hoofdstuk 8 — Scrum-artefacten en commitments

Scrum kent drie artefacten die het werk en de waarde ervan representeren. Elk artefact bevat een expliciete "commitment" die transparantie en focus waarborgt.

Product Backlog en het Product Goal

De Product Backlog is een geordende, altijd evoluerende lijst van wat nodig is om het product te verbeteren. Het bijbehorende commitment is het Product Goal: de langetermijnvisie waar het Scrum Team naartoe werkt, die richting geeft aan de prioritering van de backlog.

Sprint Backlog en het Sprint Goal

De Sprint Backlog bestaat uit het Sprint Goal (waarom), de geselecteerde Product Backlog-items (wat) en een plan om deze te realiseren (hoe). Het Sprint Goal geeft de Developers samenhang en focus, en moedigt aan om als team samen te werken in plaats van geïsoleerde taken af te vinken.

Increment en de Definition of Done

Een Increment is een concreet opstapje richting het Product Goal — elk Increment is aanvullend op eerdere Increments en wordt grondig geverifieerd, zodat alle Increments samen werken. De Definition of Done is een formele beschrijving van de staat van het Increment wanneer het aan de kwaliteitsmaatstaven voor het product voldoet — zonder gedeelde Definition of Done kan er geen zinvolle uitspraak worden gedaan over of werk daadwerkelijk klaar is.

Hoofdstuk 9 — Product Backlog management: user stories, prioriteren, schatten

User stories

Een veelgebruikt format om Product Backlog-items te beschrijven is de user story, met de vorm: "Als <type gebruiker> wil ik <doel> zodat <reden/waarde>." Dit format dwingt het team om na te denken over wíe profiteert van het werk en waaróm, in plaats van alleen een technische taak te noteren.

Een handig hulpmiddel om de kwaliteit van user stories te toetsen is het INVEST-acroniem:

Prioriteren

Niet alles kan tegelijk de hoogste prioriteit hebben. Veelgebruikte technieken zijn MoSCoW (Must, Should, Could, Won't have), waarde-versus-moeite-matrices, en het simpelweg stack-ranken van de backlog van hoog naar laag. Belangrijk is dat prioritering een continu proces is (backlog refinement), niet een eenmalige exercitie bij de start van een project.

Schatten

Veel Scrum-teams schatten de omvang van werk in story points in plaats van uren: een relatieve maat voor complexiteit, onzekerheid en hoeveelheid werk. Een populaire techniek hiervoor is Planning Poker, waarbij teamleden onafhankelijk van elkaar een schatting kiezen (vaak volgens de Fibonacci-reeks: 1, 2, 3, 5, 8, 13...) om groepsdenken te voorkomen, gevolgd door een gesprek bij grote verschillen in schatting.

Hoofdstuk 10 — Scrum versus Kanban

Scrum en Kanban worden vaak tegenover elkaar gezet, maar zijn beter te begrijpen als twee verschillende antwoorden op dezelfde onderliggende Agile-waarden.

Scrum werkt met vaste iteraties (sprints) en een vast aantal rollen; dit past goed bij productontwikkeling waar een team gedurende langere tijd samen aan hetzelfde product bouwt en behoefte heeft aan een voorspelbaar ritme van plannen, opleveren en reflecteren. Kanban werkt met continue flow zonder vaste iteraties, en legt de nadruk op het beperken van werk-in-uitvoering (WIP-limieten) om doorlooptijd te verkorten; dit past goed bij werk met wisselende, onvoorspelbare prioriteiten, zoals supportteams of platformteams die voortdurend binnenkomende verzoeken verwerken.

Veel teams combineren elementen van beide — bijvoorbeeld een Scrum-team dat een Kanban-bord gebruikt om de Sprint Backlog te visualiseren, of WIP-limieten hanteert binnen een sprint. Deze hybride vorm wordt soms "Scrumban" genoemd. Het is geen kwestie van "beter" of "slechter", maar van welke structuur het beste past bij het soort werk en de mate van voorspelbaarheid die een team nodig heeft.

Hoofdstuk 11 — Scrum opschalen naar meerdere teams

Scrum is in de kern ontworpen voor één team. Zodra een product door meerdere teams tegelijk wordt gebouwd, ontstaat een nieuwe uitdaging: hoe blijf je afgestemd zonder terug te vallen op zware, centrale coördinatiestructuren?

Een eenvoudige en veelgebruikte praktijk is Scrum of Scrums: een kort, regelmatig afstemmingsmoment waarbij een vertegenwoordiger van elk team knelpunten, afhankelijkheden en risico's deelt die de teamgrenzen overstijgen. Dit schaalt de kernprincipes van de Daily Scrum (kort, gericht op obstakels en voortgang) naar een team-van-teams niveau.

Voor grotere organisaties bestaan uitgebreidere schaalraamwerken:

• LeSS (Large-Scale Scrum) — probeert Scrum zo dicht mogelijk bij zijn oorspronkelijke, minimalistische vorm te houden, ook bij meerdere teams: één Product Backlog, één Product Owner, gezamenlijke Sprint Review en Retrospective.
• SAFe (Scaled Agile Framework) — een uitgebreider raamwerk met extra rollen en planningsniveaus (zoals Program Increment-planning), vaak gekozen door grote, traditioneel georganiseerde ondernemingen die een meer gestructureerd transitiepad willen.
• Nexus — een lichtgewicht uitbreiding van Scrum zelf (ontwikkeld door Scrum.org) voor 3 tot 9 teams die aan één product werken, met een extra "Nexus Integration Team" verantwoordelijk voor het samenvoegen van increments.

Hoofdstuk 12 — Meten in Agile en Scrum

Scrum-teams meten hun voortgang niet met traditionele projectmanagement-metrics zoals "percentage voltooid volgens plan", maar met metrics die passen bij empirisch, iteratief werken.

Velocity

Velocity is de hoeveelheid story points die een team gemiddeld per sprint aflevert. Het is primair een planningshulpmiddel voor het team zelf — om te voorspellen hoeveel werk realistisch in een toekomstige sprint past — en nadrukkelijk geen prestatie-indicator om teams onderling te vergelijken of onder druk te zetten.

Burndown- en burnup-charts

Een burndown chart toont hoeveel werk er nog resteert gedurende de sprint; een burnup chart toont juist hoeveel werk al is voltooid, plus eventuele scope-toevoegingen. Beide geven een snel, visueel signaal of een sprint op koers ligt.

Cycle time en lead time

Vooral relevant bij Kanban-achtige flows: cycle time is de tijd tussen het starten van werk aan een item en het opleveren ervan; lead time is de tijd vanaf het moment dat een item is aangevraagd tot oplevering. Kortere en consistentere cycle times duiden op een voorspelbaar, gezond systeem.

Hoofdstuk 13 — Agile cultuur, mindset en veelgemaakte fouten

Scrum invoeren als set van ceremonies zonder de onderliggende mindset te omarmen, is een van de meest voorkomende oorzaken van teleurstellende resultaten. Een paar veelgemaakte anti-patronen:

"Zombie Scrum"

Een team voert alle events uit — Daily Scrum, Sprint Review, Retrospective — maar zonder er daadwerkelijk waarde uit te halen: de Daily Scrum wordt een statusrapportage aan een manager, de Retrospective levert geen concrete verbeteracties op, en de Sprint Review is een eenzijdige presentatie zonder echte dialoog. De vorm is aanwezig, de functie niet.

Sprints als mini-watervalletjes

Sommige teams knippen een groot, vooraf volledig uitgedacht plan simpelweg op in stukjes van twee weken, zonder daadwerkelijk ruimte te laten voor voortschrijdend inzicht of het aanpassen van de backlog op basis van feedback. Dit behoudt de schijn van Agile werken, maar mist de kern: inspecteren en aanpassen.

Scrum Master als projectmanager in vermomming

Wanneer een Scrum Master takenlijsten verdeelt, deadlines oplegt en het team aanstuurt in plaats van te coachen en obstakels weg te nemen, verdwijnt de zelforganisatie die Scrum juist beoogt te versterken.

Geen psychologische veiligheid

Zonder een omgeving waarin teamleden vrijuit kunnen zeggen dat iets niet lukt, dat een schatting waarschijnlijk niet klopt, of dat een aanpak niet werkt, verwordt de Retrospective tot een oppervlakkige exercitie en blijven onderliggende problemen onopgelost.

Hoofdstuk 14 — Praktijkcasus: een team dat overstapt op Scrum

Ter illustratie: "Team Noord", een fictief team van zes developers bij een middelgrote organisatie, werkte voorheen volgens een klassieke waterval-aanpak met kwartaalplanningen. Hieronder volgt hun eerste drie sprints na de overstap naar Scrum.

Sprint 1: wennen aan het ritme

Het team koos een sprintlengte van twee weken. De eerste Sprint Planning duurde langer dan gepland — het team was niet gewend om werk in kleine, onafhankelijke stukken op te knippen. De velocity van deze eerste sprint (18 story points) werd expliciet niet gebruikt om toekomstige sprints op te baseren; het diende puur als eerste ijkpunt.

Sprint 2: eerlijke Retrospective

Tijdens de eerste Retrospective kwam naar boven dat de Product Owner nog gewend was om taken in detail voor te schrijven, wat de zelforganisatie van de Developers in de weg zat. Het team sprak af dat de Product Owner zich voortaan zou richten op het wat en waarom, en de Developers zelf het hoe zouden bepalen.

Sprint 3: eerste stabiele Sprint Goal

Met een scherper Sprint Goal ("Gebruikers kunnen hun profiel volledig zelf beheren") behaalde het team een velocity van 24 story points, en voor het eerst een Sprint Review met concrete feedback van twee externe stakeholders die daadwerkelijk het Increment gebruikten in plaats van er alleen naar te kijken.

Deze casus is bewust bescheiden: er is geen wonderbaarlijke productiviteitssprong, maar een geleidelijke verschuiving in gedrag — kortere feedbackcycli, een eerlijker gesprek over wat wel en niet werkt, en een groeiend gevoel van eigenaarschap bij de Developers. Dat is precies het soort verandering waar Scrum op mikt.

Hoofdstuk 15 — De toekomst van Agile werken

Agile werken blijft evolueren. Een aantal ontwikkelingen is de moeite waard om in de gaten te houden.

Product-georiënteerde teams in plaats van projectteams

Steeds meer organisaties stappen af van tijdelijke projectteams die na oplevering worden ontbonden, richting langlevende, product-georiënteerde teams die een product gedurende zijn hele levenscyclus beheren. Dit sluit beter aan bij de Scrum-gedachte van continue verbetering op basis van echte gebruiksdata.

Platform engineering en interne developer-platforms

Om teams echt autonoom te laten werken zonder dat elk team zelf infrastructuur, CI/CD en tooling opnieuw uitvindt, bouwen organisaties interne platforms die gestandaardiseerde, veilige bouwstenen aanbieden — waardoor Scrum-teams zich kunnen concentreren op productwaarde in plaats van herhaald technisch fundamentwerk.

Data-gedreven prioritering

In plaats van prioritering puur op onderbuikgevoel of de luidste stakeholder, gebruiken meer teams productanalytics en experimenten (A/B-testen) om te onderbouwen welke Product Backlog-items daadwerkelijk waarde toevoegen.

AI-ondersteuning in het Scrum-proces

Van het automatisch samenvatten van Sprint Reviews tot het signaleren van risico's in de Sprint Backlog op basis van historische patronen: AI-tools worden steeds vaker ingezet als ondersteuning van — niet vervanging voor — de menselijke gesprekken die de kern van Scrum vormen.

Wat niet verandert, is de onderliggende belofte van het Agile Manifesto: mensen en hun samenwerking blijven belangrijker dan elk proces of elke tool, hoe geavanceerd ook.

Hoofdstuk 16 — Conclusie

Agile werken en Scrum zijn geen doel op zich, maar een antwoord op een fundamenteel probleem: hoe bouw je waardevolle producten in een wereld waarin niet alles vooraf te voorspellen is? Dit boek liet zien hoe die gedachte terugkomt op elk niveau — van de vier waarden van het Agile Manifesto tot de concrete rollen, events en artefacten van Scrum.

1. Agile is een verzameling waarden en principes; Scrum is één concreet framework dat deze waarden operationaliseert.
2. Scrum rust op empirisme: transparantie, inspectie en adaptatie, herhaald in een vaste cyclus van sprints.
3. Rollen zijn bewust beperkt en dienen elkaar: de Product Owner bepaalt het wat en waarom, de Developers het hoe, en de Scrum Master maakt het team effectief.
4. Artefacten zonder hun commitments (Product Goal, Sprint Goal, Definition of Done) verliezen hun betekenis.
5. Metrics zoals velocity en burndown zijn hulpmiddelen voor het team zelf, geen beoordelingsinstrumenten.
6. De grootste risico's zitten niet in het framework, maar in het uithollen ervan tot lege ceremonie — "Zombie Scrum".

De reis naar volwassen Agile werken is zelden lineair. Elk team, elke organisatie en elk product vraagt om een eigen balans tussen structuur en flexibiliteit. Het enige constante uitgangspunt is dat regelmatige, eerlijke reflectie — en de bereidheid om op basis daarvan iets aan te passen — de kern vormt van elke Agile-praktijk die daadwerkelijk werkt.

Bijlage A — Glossarium

Bijlage B — Agile/Scrum-checklist

B.1 Voor de Product Owner

• Is er een actueel, duidelijk Product Goal?
• Is de Product Backlog geprioriteerd en regelmatig verfijnd?
• Zijn de belangrijkste items klein genoeg en INVEST-proof?

B.2 Voor de Scrum Master

• Worden alle events gehouden binnen hun timebox?
• Is er psychologische veiligheid om problemen eerlijk te benoemen in de Retrospective?
• Worden obstakels die het team zelf niet kan oplossen actief weggenomen?

B.3 Voor de Developers

• Is er een gedeelde, expliciete Definition of Done?
• Wordt de Sprint Backlog dagelijks bijgewerkt op basis van de Daily Scrum?
• Is het Sprint Goal aan het einde van de sprint behaald, of is er tijdig gesignaleerd dat dit niet ging lukken?

B.4 Voor de organisatie

• Wordt velocity gebruikt als planningshulpmiddel, niet als beoordelingsinstrument?
• Krijgen teams voldoende autonomie om het "hoe" zelf te bepalen?
• Is er ruimte voor experimenten en het eventueel aanpassen van het proces zelf?

Bijlage C — Aanbevolen bronnen

• The Scrum Guide — de officiële, korte definitie van het Scrum-framework (Ken Schwaber & Jeff Sutherland).
• Manifesto for Agile Software Development — de vier waarden en twaalf principes in hun oorspronkelijke vorm.
• Kanban Guide for Scrum Teams — voor teams die Kanban-praktijken willen combineren met Scrum.
• LeSS.works — documentatie over Large-Scale Scrum.
• Scaled Agile Framework (SAFe) — voor organisaties die op grotere schaal willen coördineren.