Als een team traag levert, ligt de oorzaak vrijwel nooit bij de engineers. Meestal zijn het vier of vijf concrete wrijvingen die niemand heeft gemeten.
«Het team is traag» is een symptoom, en oprichters diagnosticeren dat meestal ten onrechte als een mensenprobleem. In onze ervaring is het vrijwel altijd een systeemprobleem: werk wacht in wachtrijen, wijzigingen zijn groot en riskant, deployen is eng, en niemand heeft cijfers om mee te argumenteren.
Begin met vier metingen
Deze vier zijn goed onderbouwd en, belangrijker, diagnostisch: elk slecht resultaat wijst naar een specifieke klasse probleem.
| Metriek | Wat het blootlegt bij een slechte score |
|---|---|
| Deployfrequentie | Batchgrootte te groot, deploys behandeld als gebeurtenissen |
| Doorlooptijd van wijzigingen | Wachttijd — meestal code review of wachten op QA, niet het programmeren |
| Faalpercentage van wijzigingen | Zwak testen of ontbrekende gelijkenis met productie |
| Hersteltijd | Geen geoefende rollback, gebrekkige observability |
De gebruikelijke bevindingen
Code review is een knelpunt, geen kwaliteitspoort
- Pull requests zijn te groot om zinvol te reviewen, dus review wordt goedkeuringstheater
- Geen verwachting over reviewdoorlooptijd, dus wijzigingen blijven dagen liggen
- Eén senior engineer is de enige goedkeurder — een wachtrij met één loket
Deployen is een gebeurtenis
- Handmatige stappen die maar één persoon kent
- Geen rollback waar iemand op vertrouwt, dus releases worden gebundeld, wat ze riskanter maakt, wat ze zeldzamer maakt
- Deploys gepland in rustige periodes — een sterk signaal dat het team het proces niet vertrouwt
Werk is niet werkelijk gedefinieerd
- Tickets die eerst een gesprek vergen voordat iemand kan beginnen
- Geen gedeelde definition of done, dus werk kaatst heen en weer tussen development en QA
- Te veel onderhanden werk — iedereen druk, niets wordt af
Wat je als eerste verandert
- Maak deployen saai — automatiseer, voeg rollback toe, oefen het. Al het andere verbetert zodra uitbrengen veilig is.
- Verklein de batchgrootte — kleinere wijzigingen zijn makkelijker te reviewen, veiliger uit te brengen, sneller te diagnosticeren.
- Stel een review-SLA in — uren, geen dagen, met een tweede goedkeurder zodat één persoon nooit het knelpunt is.
- Beperk onderhanden werk — afmaken verslaat beginnen.
- Instrumenteer wat klanten voelen, zodat incidenten intern gevonden worden in plaats van gemeld.
Snelheid en veiligheid zijn geen afruil in softwarelevering. Teams die het vaakst deployen hebben ook de laagste faalpercentages — omdat kleine, frequente, omkeerbare wijzigingen tegelijk sneller én veiliger zijn.
Onderzoek werk zonder mensen op cijfers te rangschikken
Vergelijkbare taken maken systeembeperkingen zichtbaar. Verklaar wachttijd en herstelwerk zonder activiteit met productiviteit te verwarren.
- Kies meerdere afgeronde wijzigingen, waaronder een urgente reparatie.
- Meet wachtrijen, reviewrondes, overdrachten en uitrolproblemen.
- Beproef één verbetering met nulmeting en evaluatiedatum.
Veelgestelde vragen
Hoe lang duurt een audit van engineeringprocessen?
Doorgaans één tot twee weken: leverdata verzamelen, het team interviewen, een echte release observeren en de tooling doornemen. De uitkomst hoort een klein aantal geprioriteerde wijzigingen met verwachte impact te zijn, geen score op een volwassenheidsmodel.
Gaan jullie ons vertellen dat we Scrum moeten invoeren?
Nee. Methodologie is zelden de beperking — wachttijd, batchgrootte en deployrisico wel. Teams hebben onder elk framework goed geleverd en onder allemaal slecht; de ceremonie veranderen zonder die drie dingen te veranderen doet niets.
Ons team zegt meer engineers nodig te hebben. Klopt dat?
Soms, maar aannemen in een procesknelpunt maakt het eerst erger — meer mensen die meer onderhanden werk produceren tegen dezelfde review- en deploywachtrijen. Meet eerst waar de tijd werkelijk heen gaat; als het merendeel wachttijd is, is aannemen niet de oplossing.
Kunnen teams met ruwe levercijfers worden vergeleken?
Alleen met context over product, werksoort en operationele beperkingen. Trends helpen onderzoeken; aantallen alleen bewijzen geen effectiviteit.
Levert je team trager dan zou moeten?
Wij meten waar de tijd werkelijk heen gaat en lossen de grootste knelpunten op — meestal in weken, niet in kwartalen.
Verder lezen
Postmortem best practices: er een schrijven die mensen echt lezen
De meeste postmortems zijn archeologie: een accuraat verslag van iets dat niemand gaat veranderen. Een nuttige levert een klein aantal dingen op die daadwerkelijk gebeuren.
Technische MVP-audit: wat we in de eerste 48 uur controleren
De meeste MVP-audits leveren een document op. Een nuttige levert beslissingen op: wat brandt, wat kan wachten en wat het kost om het te herstellen.