Adoptionssiffran ljuger
Det är kvartalsavstämning. Plattformsteamets produktägare klickar fram en slide med en spikrak kurva: 92 procent av teamen är på den nya plattformen. Cheferna nickar. Någon skriver ner siffran till styrelsedecket. Samma vecka sitter tre produktteam och väntar på att plattformsteamet ska hinna hjälpa dem få ut veckans release. Kurvan pekar uppåt. Flödet står still.
Båda sakerna är sanna samtidigt. Det borde oroa dig mer än det gör.
Alla siffror pekar åt rätt håll
Titta på vad ett plattformsteam faktiskt rapporterar uppåt. Andel onboardade team. Antal repon som gått över till den nya pipelinen. 500 stängda tickets på ett kvartal. En nöjdhetsenkät på fyra av fem stjärnor. Kanske ett mognadsindex som lyser 82 procent grönt. Allt pekar uppåt och åt höger, och det är precis så det är tänkt att se ut.
Problemet är vad de siffrorna mäter. De mäter aktivitet, inte utfall. Att ett team är onboardat säger att det loggat in, inte att det kommer i mål snabbare än förut. Ett team kan använda plattformen till punkt och pricka och ändå sitta fast varje onsdag, i väntan på att någon i plattformsteamet ska hinna, godkänna eller felsöka. Adoptionssiffran ser likadan ut oavsett. Den stiger lika fint för teamet som älskar plattformen som för teamet som uthärdar den.
Nöjdhetsenkäten är inte bättre. De fyra stjärnorna kom från 14 av 70 utvecklare. Resten svarade inte. Enkäten fylls i av dem som redan gillar plattformen eller av de argaste, sällan av de tysta mittemellan, och svarsfrekvensen är låg nog att du kan läsa in vad du vill i resultatet. Fyra av fem stjärnor från en femtedel av teamen är inte ett betyg, det är ett rykte.
Adoption mäter användning, inte självständighet
Det lätta är att lita på siffran, för den känns objektiv. Men fråga vem som valt den, och vem som bär kostnaden när den är fel. Plattformsteamet mäts på att plattformen används. Produktteamen mäts på hur snabbt de levererar. Ingen gör fel, det är bara rationellt för varje part att titta på sin egen siffra. Och när de två målen glider isär blir hög användning en seger på plattformsteamets rapport samtidigt som beroendet växer i produktteamens vardag. Den som väljer måttet känner inte kostnaden. Den betalas i ledtid, ett par våningar bort, och syns inte på någon graf.
Adoption har dessutom en defekt inbyggd som mått: den går att trycka upp utan att något blivit bättre. Stäng av de gamla servrarna och ta bort den gamla pipelinen, så klättrar siffran mot 100 procent oavsett om plattformen är bra eller usel. Ett framgångsmått som stiger bara för att alternativen försvinner mäter en avveckling, inte plattformen bakom. Just den siffra som ser mest ut som framgång är alltså den som är lättast att arrangera på skrivbordet.
Frånvaromåttet
Det intressanta är inte hur ofta teamen kommer till plattformsteamet, utan hur ofta de slipper. Jag kallar det frånvaromåttet: en plattform mäts inte på hur mycket den används, utan på hur ofta teamen når mål utan att behöva dig. Inte närvaron i varje flöde, utan frånvaron från det. Ju mindre teamen behöver tänka på plattformsteamet för att komma i produktion, desto bättre gör plattformen sitt jobb.
Ett service desk-team som mäts på antal lösta ärenden ser bäst ut precis när flest saker går sönder. Ju mer som krånglar, desto längre kö, desto lättare att motivera budgeten, och desto svagare skäl att se till att det slutar krångla. Ett plattformsteam som mäts på användning och stängda tickets sitter i samma fälla: dess siffror lyser starkast när teamen behöver det som mest. Målet är det omvända. Färre ärenden, inte fler.
Räkna det som inte händer
Det svåra med frånvaro är att den inte syns av sig själv. Du får mäta den med flit. Så byt ut framgångssiffran.
Före: teamet rapporterar 92 procent adoption. Efter: teamet rapporterar att 40 team gjorde 3 000 deploys förra kvartalet, och att 97 procent av dem gick hela vägen till produktion utan att en enda ticket landade hos plattformsteamet. Det första talar om att folk loggar in. Det andra talar om att de klarar sig själva. Följ den kvoten över tid: antalet gånger ett team behöver knacka på hos plattformsteamet per uppnått mål ska sjunka när plattformen mognar, inte stiga.
Eller mät tiden. Hur länge dröjer det från att ett nytt team börjar tills dess första deploy går ut i produktion utan att någon i plattformsteamet lyfter ett finger? Går den tiden ner kvartal för kvartal bygger du något teamen växer ifrån att behöva. Går den upp har du byggt ett beroende, inte en plattform.
Lägg till ett obekvämt test på hela organisationen. Dölj adoptionsgrafen och titta i stället på företagets totala ledtid från idé till kund. Har den rört sig en millimeter sedan plattformen rullades ut? Om adoptionskurvan pekar spikrakt uppåt men leveranstiden till slutkund står stilla har du inte byggt självständighet. Du har bara flyttat bokföringen av väntan från en kö till en annan.
Visst, du måste veta att plattformen alls används. Ett team som aldrig ens provat den är ett problem värt att fånga, och där duger adoption som tidig hälsokoll. Men det är en ingång, inte ett mål. Ett team som använder plattformen och ändå fastnar varje vecka är ett större problem än det som aldrig loggat in, och det problemet är osynligt på adoptionsgrafen. DORA-mått, self-service-räknare, en enkel logg över mänsklig inblandning per deploy: vilket verktyg spelar mindre roll än vad du väljer att räkna. Räkna självständighet, inte aktivitet.
Mät på frånvaro, inte användning
Ett plattformsteams verkliga mål är att bli osynligt i det dagliga flödet. Det är en obekväm sak att sträva mot, för osynlighet syns inte på en slide, och en kurva som pekar uppåt är lättare att ta med till kvartalsavstämningen än en kö som tystnat.
Men det är den tysta kön som är beviset. Den bästa plattformen är den teamen slutar prata om, för att de inte längre behöver tänka på den. Så innan du visar nästa adoptionssiffra, fråga vad den egentligen mäter. Ett plattformsteam ska inte mätas på hur oumbärligt det är, utan på hur ofta det inte behövs.
Nästa kvartal pekar kurvan säkert uppåt igen. Frågan att ta med till mötet är om kön av team som väntar på plattformsteamet gör detsamma.
Vet ni om er plattform gör teamen autonoma, eller mäter ni bara att de använder den? Så jobbar jag.