Het review-gat: waarom jouw pull requests weken blijven liggen (en het niet aan capaciteit ligt)

Er is één zin die elke developer kent en niemand uitspreekt: "Even een review doen." Gevolgd door niets. Je pull request ligt er, netjes, gedocumenteerd, klaar. En dan... wachten. Drie dagen. Tien dagen. Soms drie weken, tot je zelf maar gaat pushen of de branch maar merge in wanhoop.

We behandelen dit als een capaciteitsprobleem. "Te druk." "Te weinig mensen." Maar dat is, denk ik, de verkeerde diagnose.

Review is geen taak, het is een statussymbool

In veel teams is review impliciet gedevalueerd. Code schrijven is het echte werk; review is wat je doet als je klaar bent met het echte werk. Dat zie je terug in alles: reviews worden laat op de dag gedaan, tussendoor, met halve aandacht. Reviews krijgen geen plek in de planning, geen sprint-punt, geen prioriteit.

En dan klagen we dat er te weinig gereviewd wordt. Dat is alsof je afvraagt waarom niemand de afwas doet als de afwas geen plek heeft in de huishoudelijke routine.

Het onzichtbare machtsspel

Er speelt nog iets. In veel teams is review stiekem een machtsspel: wie reviewed bepaalt wat er in gaat. Dat maakt review traag, want traagheid is macht. Als jouw PR drie weken blijft liggen en die van de tech lead vandaag nog gemerged wordt, dan weet je genoeg over de hiërarchie.

Ik noem dit bewust, want je kunt het niet oplossen met een tool of een checklist. Je kunt het alleen oplossen door het te benoemen.

Rituelen die wél werken

Genoeg geklaagd. Wat kun je concreet doen? Een paar rituals die ik in verschillende teams heb zien werken:

1. De review-slot. Een vast blok in de dag (bijvoorbeeld 10:00–11:00) waarin iedereen reviewt. Geen vergadering, geen feature-werk. Het klinkt saai, maar het werkt, omdat het review van een gunst verandert in een routine.

2. De review-roulette. Een bot of script wijst per PR willekeurig een reviewer aan, met een deadline van 24 uur. Niet de senior die altijd alles mag beoordelen, maar iemand — en rouleert. Dit doodt het machtsspel en groeit juniors sneller dan welke training dan ook.

3. Kleinere PR's, hard afgesproken. Een PR boven de 400 regels wordt teruggestuurd, punt. Niet uit pedanterie, maar omdat grote PR's psychologisch onreviewable zijn. Het probleem is vaak niet de reviewer, het is de omvang.

4. Review in de definitie-of-done. Een ticket is pas af als het gemerged is. Niet "code af, review volgt". Zolang review buiten je definitie van af staat, zal het altijd verliezen van feature-werk.

5. De review-shout-out. Eindig je sprint met een rondje: wie heeft deze week goed gereviewed? Klinkt zacht, maar het herkadert review van last naar bijdrage.

Het gesprek dat je moet voeren

Al deze rituelen helpen niet als je niet eerst het onderliggende gesprek voert: waarom doen we dit eigenlijk zo? Zit er ergens een ongeschreven regel dat review van juniors minder prioriteit heeft? Dat code van bepaalde mensen sneller gemerged wordt? Dat soort dingen spreek je niet aan in een retro-bullet, maar in een echt gesprek.

Want uiteindelijk is een PR die blijft liggen nooit alleen een PR die blijft liggen. Het is een signaal aan de bijdrager: jouw werk telt minder. En dat is een signaal dat je, eenmaal verzonden, moeilijk terugdraait.

Review dus niet als een bottleneck, maar als het hart van samenwerken. Want dat is het, gewoon, als je het goed organiseert.