1.10 Engineeringeffectiviteit en ontwikkelaarsproductiviteit

Overzicht en motivatie

Elke leider van een grote softwareorganisatie stelt uiteindelijk een variant van dezelfde vraag: worden we beter in het bouwen van software, en hoe zouden we dat weten? Dit hoofdstuk gaat over het eerlijk beantwoorden daarvan. Engineeringeffectiviteit is hoe goed je organisatie engineeringinspanning omzet in waardevolle, betrouwbare software. Ontwikkelaarsproductiviteit is de individuele en teamkant daarvan: hoeveel nuttige output een ontwikkelaar kan produceren, en hoeveel van zijn of haar tijd en aandacht de werkomgeving teruggeeft in plaats van afneemt.

Het probleem begint op het moment dat iemand dit tot één getal probeert terug te brengen. Tel regels code en mensen schrijven meer code. Tel storypoints en schattingen inflateren. Tel commits, pull requests of uren aan het bureau en je beloont beweging in plaats van voortgang. Productiviteit voor een kenniswerker is geen telling van producten. Een ontwikkelaar die tienduizend regels dode code verwijdert, of die een dag pairt zodat een teamgenoot een productiestoring vermijdt, heeft uitstekend werk gedaan dat geen naïeve maat vastlegt. Het eerlijke antwoord op “hoe productief zijn we?” is multidimensionaal, en het behandelt de ervaring van de ontwikkelaar met het werk als een echt signaal in plaats van een zacht signaal.

Dit doet er op schaal meer toe, niet minder. In een onderneming met tientallen teams vermenigvuldigen kleine hoeveelheden wrijving (een trage build, een onbetrouwbare testsuite, een wachttijd van twee dagen op een omgeving) zich over honderden engineers tot enorme verloren capaciteit. Bij de overheid, waar geen marktprijs op output staat, is het risico “outputtheater”: documenten die zijn geproduceerd of tickets die zijn gesloten meten terwijl publieke waarde ongemeten blijft. Het doel van dit hoofdstuk is je te helpen de effectiviteit van de engineeringorganisatie en de dagelijkse ervaring van haar ontwikkelaars te meten en te verbeteren, zonder bespeling, bewaking of het onderling rangschikken van mensen.

Kernprincipes

Productiviteit is multidimensionaal. Geen enkel getal legt haar vast. Elke maat die als de maat wordt aangeboden, is fout.
Meet om wrijving weg te nemen, niet om mensen te rangschikken. Het onderwerp van meting is het systeem, niet het individu.
Trianguleer. Combineer hoe ontwikkelaars zeggen dat het werk voelt met wat de systemen daadwerkelijk registreren.
De ervaring van de ontwikkelaar is data. Feedbacklussen, cognitieve belasting en flow zijn meetbaar en de moeite waard om te verbeteren.
Ga ervan uit dat elke maat wordt bespeeld. Ontwerp tegen de wet van Goodhart met meerdere dimensies en eerlijke bedoeling.
Verbind met resultaten, voorzichtig. Effectiviteit moet opklimmen tot bedrijfswaarde zonder een doel te worden dat corrumpeert.

Aanbevelingen

Verwerp de valkuil van de enkele maat

De eerste discipline is weigeren één getal productiviteit te noemen. Regels code, commitaantallen, velocity in storypoints en gelogde uren delen allemaal een fataal gebrek: ze meten activiteit, niet waarde, en activiteit is triviaal op te blazen. Dit is de wet van Goodhart in actie, het principe dat een maat die een doel wordt ophoudt een goede maat te zijn. Velocity werd uitgevonden als eigen prognosehulp van een team. Op het moment dat een manager de punten van het ene team met die van het andere vergelijkt, schalen teams hun schattingen stilletjes om en wordt het getal betekenisloos. Wanneer iemand één productiviteits-KPI eist, behandel dat dan als een verzoek dat je moet hervormen, niet vervullen. Bied in plaats daarvan een kleine uitgebalanceerde set aan en leg uit waarom één getal hen zou misleiden.

Gebruik SPACE om te structureren wat je meet

Het SPACE-raamwerk geeft je de vijf dimensies die het waard zijn om samen te houden: Satisfaction en welzijn, Performance, Activity, Communicatie en samenwerking en Efficiëntie en flow. Het punt van SPACE is dat je ten minste een paar dimensies moet kiezen, nooit slechts één, en nooit allemaal uit dezelfde categorie. Activiteitsmaten (commits, deployments) zijn verleidelijk omdat ze makkelijk te verzamelen zijn, maar op zichzelf vervormen ze. Koppel ze aan een tevredenheidssignaal en een prestatiesignaal, zodat geen enkele dimensie kan worden bespeeld zonder dat de andere haar ontmaskeren. Een team dat meer deployments levert terwijl de tevredenheid instort en het faalpercentage van wijzigingen oploopt, is niet productiever, en een uitgebalanceerde set laat je dat meteen zien.

Behandel ontwikkelaarservaring als feedbacklussen, cognitieve belasting en flow

Ontwikkelaarservaring (DevEx) is hoe het voelt om hier engineeringwerk te doen, en het is concreter dan het klinkt. Het rust op drie dingen die je kunt meten en verbeteren. Feedbacklussen zijn hoe lang een ontwikkelaar wacht om te leren of iets werkte: lokale buildtijd, duur van de testsuite, doorlooptijd van codereview, deploytijd. Trage lussen forceren contextwisselingen en nutteloos wachten. Cognitieve belasting, de totale mentale inspanning die een taak vraagt, groeit wanneer een ontwikkelaar te veel tools, ongedocumenteerde systemen en verwarde afhankelijkheden moet jongleren om een eenvoudige wijziging te maken. Flow is de toestand van gerichte, productieve onderdompeling die versnipperde agenda’s en voortdurende onderbrekingen vernietigen. Wanneer je een feedbacklus verkort, een begrip weghaalt dat een ontwikkelaar in zijn hoofd moest houden of een blok focustijd beschermt, heb je productiviteit verbeterd op een manier die geen activiteitstelling registreert. Dit is dezelfde DevEx-zorg die platform engineering bedient via gebaande wegen en self-service (hoofdstuk 8.4).

Trianguleer percepties met systeemstatistieken

Geen enkele databron is op zichzelf betrouwbaar, dus combineer twee soorten. Perceptuele data komt van de ontwikkelaars zelf via een ontwikkelaarservaringsenquête: een regelmatige, grotendeels anonieme vragenlijst die vraagt hoe zeker ze zich voelen bij het opleveren, waar ze tijd verliezen en wat hen frustreert. Systeemdata komt uit je tools: pipelinetijden, reviewlatentie, incidentfrequentie. Elk corrigeert het andere. Enquêtes vangen pijn die instrumenten missen, zoals een demoraliserende bereikbaarheidsdienst of een gevreesde legacyservice. Systeemstatistieken vangen problemen die mensen hebben genormaliseerd en niet meer melden. Wanneer een enquête zegt dat builds pijnlijk zijn en je pipelinedata een mediane build van vijftien minuten bevestigt, heb je een geprioriteerde, verdedigbare investering. Draai de enquête met een vaste cadans, houd haar kort en sluit de lus altijd door te tonen wat er door is veranderd.

Gebruik DORA als leveringssignaal, niet als ranglijst

De vier DevOps Research and Assessment (DORA)-maten (deployfrequentie, doorlooptijd van wijzigingen, faalpercentage van wijzigingen en tijd tot herstel van de service) zijn een sterke, onderzoeksgebaseerde meting van je leveringsvermogen, die snelheid met stabiliteit koppelen zodat geen van beide wordt opgeofferd voor de ander. Hoofdstuk 11.5 behandelt de diepgang hierover en hoofdstuk 11.2 de leveringspipeline die ze meten. Gebruik ze daar. Hier gaat de richtlijn over hoe je ze vasthoudt. Behandel DORA als een gezondheidssignaal op teamniveau dat laat zien of je leveringssysteem verbetert, niet als scorebord om teams of individuen te rangschikken. Op het moment dat DORA-cijfers in iemands beoordeling verschijnen, beginnen teams deployments te splitsen om de frequentie op te vullen en incidenten te verbergen om hun faalpercentage te beschermen, en sterft het signaal.

Meet het systeem, bewaak nooit het individu

Dit is de lijn die je niet mag overschrijden. Aggregeer maten tot team- en organisatieniveau en gebruik ze om wrijving te vinden en weg te nemen. Bouw geen dashboards die ontwikkelaars rangschikken op commits, uren of “productiviteitsscores”, en laat individuele telemetrie nooit beloning of promotie voeden. Bewaking vernietigt de psychologische veiligheid en het vertrouwen waarvan effectieve engineering afhangt, en leert mensen de maat te optimaliseren in plaats van het werk. Individuele groei en beoordeling horen thuis in de afzonderlijke, menselijke mechanismen van loopbaanladders en managergesprekken (hoofdstuk 1.3). Effectiviteitsmeting vraagt “wat vertraagt onze teams?” Ze vraagt nooit “wie is onze traagste engineer?”

Pak sleurwerk en wrijving rechtstreeks aan

Zodra je kunt zien waar tijd weglekt, geef je die terug. Veel van wat effectiviteit beperkt, is sleurwerk (toil), het handmatige, repetitieve, automatiseerbare werk dat meegroeit met groei en geen blijvende waarde levert (hoofdstuk 9.1). Trage reviews zijn ook wrijving, dus het stroomlijnen van codereview (hoofdstuk 2.5) met kleinere wijzigingen en heldere verwachtingen verkort een kernfeedbacklus. Gebaande wegen en self-serviceplatforms (hoofdstuk 8.4) halen hele categorieën wachten en cognitieve belasting in één keer weg. Begroot ook tegen technische schuld, de opgebouwde kosten van eerdere sluiproutes die elke toekomstige wijziging belast, want een codebase die niemand veilig kan wijzigen is de diepste productiviteitssink van allemaal.

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Enkele productiviteitsmaat (LOC, velocity, commits)	Goedkoop, makkelijk, één getal voor leiders	Meteen bespeeld. Meet activiteit, niet waarde. Corrodeert vertrouwen
Uitgebalanceerde set in SPACE-stijl	Bestand tegen bespeling. Weerspiegelt de werkelijkheid	Meer werk om te verzamelen. Moeilijker in één cijfer samen te vatten
DevEx-enquête (perceptueel)	Vangt gevoelde pijn die instrumenten missen	Subjectief. Heeft vertrouwen en opvolging nodig om eerlijk te blijven
Systeemstatistieken (DORA, pipelinetijden)	Objectief, continu, in aggregaat moeilijk te vervalsen	Blind voor moreel en context. Gevaarlijk bij toepassing op individuen
Beide trianguleren	Elke bron corrigeert de ander. Robuust	Vraagt investering in tooling en enquêtediscipline

De centrale spanning is stringentie tegenover eerlijkheid. Een enkel getal is makkelijk te rapporteren en makkelijk te corrumperen. Een rijk, multidimensionaal beeld is eerlijk maar moeilijker te communiceren aan een drukke bestuurder. Los het op door een kleine uitgebalanceerde set te kiezen (een paar SPACE-dimensies plus een enquête plus DORA als leveringsmeting), trends te rapporteren in plaats van momentopnamen en expliciet te zijn dat de cijfers bestaan om het systeem te verbeteren, niet om mensen te beoordelen. Wanneer het bestuur “één grafiek” wil, geef hen een trend van een paar complementaire signalen en weersta de verleiding ze tot een valse samengestelde maat te laten instorten.

Vragen om met je team te bespreken

Als een leider morgen één productiviteitsgetal eiste, wat zou je hen geven? Deze vraag legt bloot of je organisatie de valkuil begrijpt. Het eerlijke antwoord is dat geen enkel getal veilig is, en je taak is het verzoek te hervormen tot een kleine uitgebalanceerde set die bestand is tegen bespeling. Neem de maten die je al rapporteert mee en vraag voor elk: “hoe zou een slim, cynisch team dit opblazen zonder beter werk te doen?” Als het antwoord makkelijk is, is de maat gevaarlijk op het moment dat ze een doel wordt. Bespreek wat je in plaats daarvan zou aanbieden, en hoe je het bestuur zou uitleggen waarom één getal hen zou misleiden tot het optimaliseren van het verkeerde. De kwaliteit van dat gesprek voorspelt of meting je zal helpen of corrumperen.
Wat is je traagste feedbacklus, en wat kost ze je elke dag? Feedbacklussen zijn waar productiviteit stilletjes lekt: een build van vijftien minuten, een reviewwachttijd van twee dagen, een onbetrouwbare testsuite die het vertrouwen in elk groen vinkje uitholt. Neem echte cijfers mee uit een ontwikkelaarservaringsenquête en uit je pipelinemetingen, en kijk of de gevoelde pijn en de gemeten latentie overeenstemmen. Schat de dagelijkse kosten door de wachttijd te vermenigvuldigen met hoeveel ontwikkelaars er hoe vaak last van hebben, en het argument voor investering maakt zichzelf meestal. Bepaal welke lus je eerst verkort en wie de oplossing bezit. Een team dat zijn traagste lus niet kan noemen, is nog niet begonnen met het meten van wat het meest telt.
Waar riskeert je meting op bewaking te lijken, en hoe voorkom je dat? Het verschil tussen het systeem meten en mensen bewaken is het verschil tussen vertrouwen en angst, en het is makkelijk te overschrijden zonder het te merken. Loop elk dashboard en elke rapportage door en vraag of een ervan een individu kan rangschikken of een beoordeling kan voeden. Bepaal expliciet wat geaggregeerd blijft, wat anoniem blijft en wat verboden terrein is, en zeg dat dan openlijk tegen de teams die worden gemeten. In onderneming en overheid, waar toezicht- en auditdruk sterk zijn, is de verleiding om door te boren naar individuen constant, dus de bescherming moet een uitgesproken principe zijn, geen hoop. Als ontwikkelaars geloven dat de cijfers tegen hen worden gebruikt, optimaliseren ze de cijfers en verdwijnt de waarheid.
Toen we ontwikkelaars voor het laatst vroegen hoe het werk voelt, wat is er daardoor veranderd, en hebben ze dat ooit gehoord? Een enquête die geen zichtbare actie oplevert, leert ontwikkelaars niet meer eerlijk te antwoorden, dus de tweede stille enquête trekt minder en vlakkere reacties dan de eerste, en het instrument waarop je vertrouwt vervalt precies terwijl je het opschaalt. Voor een grote organisatie stapelt de verspilling zich op: honderden mensen besteden tijd aan het rapporteren van wrijving, er circuleert een rapport en er wordt niets opgeleverd. Neem de drie belangrijkste bevindingen van de laatste enquête mee, het concrete werk dat elk in gang zette en hoe je het resultaat terugcommuniceerde aan de mensen die het aandroegen. Weeg de tegenkracht tussen handelen op de luidste klacht en handelen op de meest wijdverbreide, want dat zijn vaak verschillende problemen. In onderneming en overheid, waar enquêtemoeheid en consultatieoverbelasting al hoog zijn, behandel je het sluiten van de lus als governancetoezegging: noem wie de reactie bezit, publiceer wat er veranderde en accepteer dat een onbeantwoorde enquête erger is dan geen.
Hoe zouden we teams vergelijken zonder een ranglijst te bouwen die eerlijkheid straft? Leiders van grote organisaties willen natuurlijk weten welke teams gedijen en welke vastzitten, maar teams rangschikken op ruwe velocity, deployfrequentie of DORA-cijfers negeert dat een betalingsteam onder zware regulering en een greenfield-prototypeteam in verschillende werelden leven. De concurrerende overweging is echt: je moet teams in moeilijkheden herkennen en vertellen wat werkt, maar op het moment dat vergelijking een scorebord wordt, schalen teams schattingen om, verbergen ze incidenten en splitsen ze deployments om hun positie te beschermen. Neem specifieke voorbeelden mee van hoe teamcontexten in je organisatie verschillen, samen met een voorstel om elk team te vergelijken met zijn eigen traject in de tijd in plaats van met zijn buren. In onderneming en overheid, waar audit- en toezichtdruk hard duwen richting rangschikking tussen teams, spreek je vooraf af wat vergeleken mag worden, wat alleen ooit als trend per team wordt gelezen en wie bevoegd is een oneerlijke vergelijking te weigeren.
Hoe verbinden we effectiviteit met echte resultaten zonder van een leveringsmaat een corrumperend doel te maken? Effectiviteit die nooit opklimt tot waarde ziet er voor het bestuur uit als navelstaren, maar op het moment dat een leveringssignaal als doorlooptijd of deployfrequentie het doel in een beoordeling wordt, optimaliseren teams het getal en laten ze het resultaat vallen waarvoor het een proxy moest zijn. Voor een grote organisatie is de spanning acuut, omdat bestuurders een heldere lijn willen van engineeringinspanning naar bedrijfsresultaten terwijl de eerlijke lijn rommelig en vertraagd is. Neem je huidige resultaatmaten mee, de leveringssignalen waaraan je ze zou koppelen en een expliciet verslag van hoe elk kan worden bespeeld als het een doel wordt. Weeg de trek tussen een eenvoudig verhaal dat het bestuur kan navertellen en een waarheidsgetrouw beeld dat vervorming weerstaat. In de overheid of een niet-markt interne dienst, waar geen omzet is om waarde aan te verankeren, wees dan bereid resultaten te definiëren als servicebetrouwbaarheid, doorlooptijd van fixes en publiek voordeel in plaats van ruwe activiteit, en die keuze te verdedigen voor toezichthouders die misschien de voorkeur geven aan makkelijker te tellen artefacten.

Sectorperspectief

Startup. Met een handvol engineers en weinig runway sla je dashboards helemaal over en meet je de twee dingen die het snelst bewegen: een ontwikkelaarservaringsenquête van tien vragen en basale pipelinetijden. Je grootste productiviteitsrisico is een trage of onbetrouwbare testsuite en voortdurende contextwisselingen, dus vind de slechtste feedbacklus, verkort haar en ga verder. Zet geen meetprogramma op waarvoor je niemand hebt om het te draaien, want één eerlijk gesprek over waar de dag lekt verslaat alle tooling die je dan zou moeten onderhouden.

Kleinbedrijf. Zonder meetspecialist en met een krap budget leun je op wat je bestaande tools al registreren: buildtijden, reviewlatentie en incidentaantallen uit de systemen waar je al voor betaalt. Koop een lichte enquêtetool in plaats van er een te bouwen en weersta de pitch van een leverancier voor een dashboard met individuele productiviteit, dat je vertrouwen zal kosten dat je niet kunt missen. Zie de hele inspanning als het wegnemen van wrijving voor een klein team dat zich niemands dag kan veroorloven te verspillen.

Grote onderneming. Over tientallen teams is de prijs teruggewonnen capaciteit op schaal, en het gevaar is een centraal dashboard dat stilletjes afglijdt naar het rangschikken van mensen. Standaardiseer een uitgebalanceerd programma (een kwartaalenquête over DevEx, een paar SPACE-dimensies en DORA gelezen als leveringstrend per team) en bestuur het zo dat individuele telemetrie nooit wordt verzameld. Vergelijk elk team met zijn eigen traject, rechtvaardig platforminvestering (hoofdstuk 8.4) tegenover de wrijving die de data onthult en geef één verantwoordelijke eigenaar de bevoegdheid elke maat te weigeren die een ranglijst zou worden.

Overheid. Zonder marktprijs op output en met sterke toezichtsdruk is de trek naar outputtheater (documenten en gesloten tickets tellen) constant, en de trek naar bewaking van benoemde individuen onder audit is nog sterker. Meet in plaats daarvan resultaten en leveringsvermogen: hoe snel een service een fix oplevert, hoe betrouwbaar ze is en hoe personeel en externe medewerkers het werk ervaren via een anonieme enquête. Meet ambtenaren en externe medewerkers op dezelfde systeemniveaubasis, publiceer waarvoor de meting dient en wees bereid aan een wetgevend orgaan te betogen dat een leveringstrend per team een eerlijker beeld geeft van publieke waarde dan welke individuele score dan ook.

Voorbeelden

Startup. Een startup van twintig personen merkt dat het opleveren is vertraagd terwijl iedereen druk is. In plaats van een productiviteitsdashboard te installeren, houdt de engineeringleider een DevEx-enquête van tien vragen en haalt basale pipelinetijden op. De enquête en de data komen overeen: de testsuite duurt tweeëntwintig minuten en faalt willekeurig, dus mensen bundelen wijzigingen en wisselen van context terwijl ze wachten. Het team besteedt twee weken aan het repareren van onbetrouwbare tests en het parallelliseren van de suite, waardoor die terugvalt tot vier minuten. De deployfrequentie stijgt vanzelf, de tevredenheid springt omhoog in de volgende enquête en niemand werd ooit gerangschikt of gescoord om dat te laten gebeuren.

Grote onderneming. Een bank met veertig engineeringteams wil blijvende investering in haar interne platform rechtvaardigen. De platformgroep neemt een uitgebalanceerd meetprogramma aan: een kwartaalenquête over DevEx onder alle teams, signalen in SPACE-stijl en DORA-maten gelezen op teamniveau als trend in leveringsgezondheid (hoofdstuk 11.5). Cruciaal is dat ze teams eerlijk benchmarken door elk team te vergelijken met zijn eigen traject in de tijd, niet met elkaar, omdat teamcontexten wild verschillen. De data laat zien dat teams op gebaande wegen (hoofdstuk 8.4) nieuwe engineers in dagen in plaats van weken onboarden en veel lagere cognitieve belasting melden. Dat bewijs, gepresenteerd als teruggewonnen capaciteit over honderden ontwikkelaars, financiert het platform voor nog een jaar. Individuele telemetrie wordt bewust nooit verzameld.

Overheid. Een federale dienst voor digitale diensten moet een wetgevend orgaan laten zien dat haar engineeringuitgaven waarde leveren, in een omgeving zonder marktprijs op output. Ze verwerpt outputtheater (documenten of gesloten tickets tellen) en meet in plaats daarvan resultaten en leveringsvermogen: hoe snel diensten een fix kunnen opleveren, hoe betrouwbaar ze zijn en hoe het personeel en zijn externe medewerkers het werk ervaren via een anonieme enquête. Leveringssignalen in DORA-stijl laten zien of modernisering daadwerkelijk doorvoer en stabiliteit verbetert, gekoppeld aan publieke resultaten in plaats van ruwe activiteit (hoofdstuk 11.5). Omdat meting nooit individuen rangschikt, en omdat externe medewerkers en ambtenaren op dezelfde systeemniveaubasis worden gemeten, vermijdt de dienst de bewakings- en moraalproblemen die zulke inspanningen laten zinken, en geeft ze toezichthouders een eerlijk beeld van waarde.

Zakelijke onderbouwing: motivatie, ROI en TCO

Het rendement van het meten en verbeteren van effectiviteit is teruggewonnen capaciteit, en op schaal zijn de getallen groot. Kleine wrijvingen vermenigvuldigen zich over een grote organisatie: een build van tien minuten waar honderd engineers meerdere keren per dag tegenaan lopen is duizenden engineeruren per jaar aan wachten. Verkort die lus en je hebt zinvolle capaciteit toegevoegd zonder iemand aan te nemen. De dominante ROI hier is dezelfde als bij platform engineering (hoofdstuk 8.4): dure engineeringtijd die van wachten en sleurwerk wordt omgeleid naar waardevol werk.

De total cost of ownership is bescheiden maar reëel. Je betaalt voor enquêtetooling en de discipline om die te draaien, voor het instrumenteren van pipelines en voor de managementaandacht om trends te lezen en erop te handelen. Het grotere risico voor de ROI is meting slecht doen. Eén bespeelde maat of een bewakingsprogramma kan negatief rendement opleveren: maanden inspanning om een getal te optimaliseren terwijl echte resultaten stagneren, plus de corrosie van vertrouwen die elke toekomstige verandering moeilijker maakt. De kosten van helemaal niet meten zijn diffuus en enorm: wrijving en sleurwerk stapelen zich onzichtbaar op, senior engineers branden op aan vermijdbare verspilling en het bestuur kan niet zien of investeringen helpen. Maak het argument bij het bestuur als hefboom en eerlijkheid: een klein, vertrouwd, uitgebalanceerd meetprogramma dat vindt waar een groot personeelsbestand tijd verliest en zichzelf vele malen terugbetaalt op het moment dat je op de eerste bevinding handelt.

Antipatronen en valkuilen

De enkele productiviteitsmaat. Elk enkel getal (LOC, velocity, commits, uren) wordt bespeeld op de dag dat het een doel wordt.
Individuen rangschikken. Ranglijsten en individuele “productiviteitsscores” vernietigen vertrouwen en leren mensen de maat te optimaliseren.
Meting als bewaking. Fijnmazige individuele telemetrie die beoordelingen voedt, corrodeert de psychologische veiligheid die effectief werk nodig heeft.
Enquêtes zonder opvolging. Ontwikkelaars vragen hoe het werk voelt en dan niets veranderen, leert hen niet meer eerlijk te antwoorden.
Ruwe cijfers van teams vergelijken. Teamcontexten verschillen. Vergelijkingen van velocity of DORA tussen teams straffen eerlijkheid en belonen bespeling.
Outputtheater. Geproduceerde artefacten tellen (documenten, tickets, opgeleverde functies) terwijl echte resultaten ongemeten blijven, gebruikelijk waar geen marktprijs is.
DORA in een beoordeling. Op het moment dat leveringsmaten mensen scoren, verbergen teams incidenten en splitsen ze deployments, en sterft het signaal.

Volwassenheidsmodel

Niveau 1, Initiëren: Productiviteit wordt beoordeeld op onderbuikgevoel of een enkele bespeelbare maat zoals regels code, velocity of uren. Meting is ad hoc en reactief, wrijving is onzichtbaar, klachten zijn anekdotisch en niemand kan zeggen of de organisatie beter wordt.
Niveau 2, Ontwikkelen: Sommige teams nemen basispraktijken aan: een paar maten, vaak activiteitstellingen, en de af en toe voorkomende ontwikkelaarservaringsenquête. De praktijken zijn inconsistent van team tot team, data wordt verzameld maar zelden benut, ruwe vergelijkingen tussen teams sluipen binnen en er is geen gedeeld principe dat individuen beschermt tegen rangschikking.
Niveau 3, Standaardiseren: Een uitgebalanceerd meetprogramma is gedocumenteerd en organisatiebreed toegepast, met dimensies in SPACE-stijl, een regelmatige DevEx-enquête en DORA als leveringssignaal (hoofdstuk 11.5). Maten worden bij beleid tot teams geaggregeerd, individuen worden nooit gerangschikt en bevindingen sturen concreet werk aan om feedbacklussen te verkorten en sleurwerk te schrappen (hoofdstuk 9.1).
Niveau 4, Beheersen: Het programma wordt gemeten en gestuurd aan de hand van uitgangswaarden. Feedbacklustijden, enquêtescores en DORA-trends dragen afgesproken doelen en worden in de tijd gevolgd. Elk team wordt vergeleken met zijn eigen traject in plaats van met zijn buren. Investeringen in platform en sleurwerkreductie worden gerechtvaardigd met voor-en-na-data over teruggewonnen capaciteit. En een achteruitgang in een signaal triggert review in plaats van onopgemerkt voorbij te gaan.
Niveau 5, Orkestreren: Meting is vertrouwd, routinematig en adaptief. Perceptuele en systeemdata worden getrianguleerd, trends voeden continue verbetering, wrijving en cognitieve belasting worden actief opgespoord en weggenomen, de meetset zelf wordt herzien naarmate de organisatie verandert en effectiviteit is geïntegreerd met bedrijfs- en publieke resultaten zonder dat enige maat een corrumperend doel mag worden.

Ideeën voor discussie

Welke van je huidige maten zou een cynisch team kunnen opblazen zonder beter werk te doen, en waarmee zou je ze vervangen?
Als je precies één feedbacklus in de hele organisatie zou kunnen verkorten, welke zou de meeste teruggewonnen capaciteit opleveren?
Hoe zou je veel teams eerlijk benchmarken als hun contexten verschillen, zonder een ranglijst te creëren die eerlijkheid straft?
Waar ligt de lijn tussen het systeem meten en het individu bewaken, en wie in je organisatie is bevoegd die af te dwingen?
Hoe meet je in een omgeving zonder marktprijs op output, zoals de overheid of een intern platform, echte waarde in plaats van activiteit?
Wat zou je een ontwikkelaar laten zien om te bewijzen dat de enquête van dit kwartaal iets heeft veranderd?

Belangrijkste inzichten

Productiviteit van engineers is multidimensionaal. Verwerp elk enkel getal (regels code, velocity, commits, uren) als de maat, omdat de wet van Goodhart garandeert dat het wordt bespeeld.
Gebruik het SPACE-raamwerk (tevredenheid en welzijn, prestaties, activiteit, communicatie en samenwerking, efficiëntie en flow) om meerdere dimensies samen te houden zodat geen enkele dimensie alleen kan worden bespeeld.
Ontwikkelaarservaring komt neer op feedbacklussen, cognitieve belasting en flow. Lussen verkorten en belasting wegnemen is echte productiviteit die activiteitstellingen nooit laten zien.
Trianguleer perceptuele data uit een DevEx-enquête met systeemdata uit je tools. Elk corrigeert het andere.
Behandel DORA-maten als teamniveausignaal voor levering, niet als ranglijst. De diepgang staat in hoofdstuk 11.5 en de pipeline in hoofdstuk 11.2.
Meet het systeem, nooit het individu. Aggregeer tot teams, houd beoordeling in de aparte menselijke kanalen van hoofdstuk 1.3 en laat meting nooit bewaking worden.
Besteed teruggewonnen tijd aan het schrappen van sleurwerk (hoofdstuk 9.1), het versnellen van codereview (hoofdstuk 2.5) en het aanleggen van gebaande wegen (hoofdstuk 8.4). Verbind effectiviteit met bedrijfsresultaten zonder een maat een corrumperend doel te laten worden.

Referenties en verder lezen

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): the multidimensional framework.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): feedback loops, cognitive load, and flow.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (the DORA metrics and their research basis).
DORA, Accelerate State of DevOps Report (annual): the ongoing research programme behind the four metrics.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (toil and its elimination).
Matthew Skelton and Manuel Pais, Team Topologies (cognitive load as a first-class design concern).
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (the origin of flow state).
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (focus, interruption, and the human side of productivity).
Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): the origin of Goodhart’s law; see also Marilyn Strathern’s widely quoted formulation.
U.S. Government Accountability Office (GAO) guidance on performance measurement: measuring value in non-market public-sector settings.