Låt oss fokusera på validerat lärande i stället för att misslyckas

Som kommer från en bakgrund med vattenfallsleveranser där misslyckanden skulle undvikas till varje pris, har jag förvånats över den agila toleransen för misslyckanden. Om jag hade fått en tårtbit för varje gång jag hört någon upprepa mantrat ”vi måste misslyckas för att lära oss” skulle jag ha varit tvungen att börja banta för flera månader sedan.

Lärande genom att misslyckas har blivit den vanligaste lösningen för att hantera osäkerhet, problem eller risker. Det anses ofta också vara ett fritt spelrum för att ”se vad som händer” och ”lära sig något på vägen”.

För att vara tydlig tror jag helt och hållet på kraften i att lära sig genom att göra misstag. Många framgångsrika entreprenörer lärde sig av sina misslyckanden och blev framgångsrika så småningom. Problemet med ”se vad som händer”-metoden är att den ofta leder till slöseri. Tid är ofta en kritisk faktor på grund av begränsade resurser eller konkurrenstryck. Därför är det viktigt för många organisationer att använda dessa resurser effektivt och ändamålsenligt.

Vad mer är problemet är att ”lära sig genom att misslyckas” har blivit en nödlösning, när det primära målet borde vara att lära sig samtidigt som man minimerar konsekvenserna av ett misslyckande? Som Eric Ries påpekade i Lean Startup:

”Lärande är den äldsta ursäkten i boken för att misslyckas med genomförandet. Det är vad chefer faller tillbaka på när de misslyckas med att uppnå de resultat vi lovat. vi är vilt kreativa när det gäller att visa vad vi har lärt oss. Vi kan alla berätta en bra historia när vårt jobb, vår karriär eller vårt rykte beror på det.”

Istället för att bara ”se vad som händer” förespråkar Ries ett validerat lärande. Validerat lärande är ”en liten enhet av framsteg som snabbt kan verifieras för att avgöra om en vald riktning är korrekt”. Teorin om validerat lärande uppmuntrar entreprenörer att kontinuerligt validera och mäta det som är viktigast för kunderna.

Termen minimum viable product (MVP) definieras som ”en version av en ny produkt som gör det möjligt för ett team att samla in maximal mängd validerat lärande om kunderna med minsta möjliga ansträngning”. Detta kräver att en entreprenör i förväg förstår vilka lärdomar han (eller hon) vill validera, eller med andra ord vet vilka frågor han (eller hon) vill besvara. Dessa frågor eller antaganden måste vara så mätbara och exakta som möjligt, baserat på den information som finns tillgänglig vid den aktuella tidpunkten.

Scrum-guiden stöder också detta tänkande och använder termen ”empiri”. Empirism handlar om att fatta beslut på grundval av bevis, fakta och erfarenhet. Genom regelbunden inspektion och anpassning kan ett Scrum-team validera antaganden och komma in i en cykel av kontinuerliga inkrementella förbättringar.

”Scrum bygger på teorin om empirisk processkontroll, eller empiricism. Empiricism hävdar att kunskap kommer från erfarenhet och att fatta beslut baserat på vad som är känt”. (Scrum Guide 2017)

Validerat lärande är förankrat i Scrum. På grund av dess inkrementella och iterativa karaktär kan Scrum-team kontinuerligt lära sig med varje Sprint. Det är uppenbart att det kommer att ske misslyckanden. Det är omöjligt att göra allting rätt första gången. Effekten bör dock förbli begränsad och hanteras, eftersom teamet kan ta med sig lärdomarna från detta misslyckande in i nästa Sprint.

För övrigt uppmuntrar Scrum, på grund av sin förankrade flexibilitet, teamen att vara användarcentrerade. Detta gör det möjligt att tidigt validera antaganden med slutanvändare. Exempel på sådana valideringsmetoder är användarforskning, prototyper, A/B-testning eller mätning av KPI:er genom analys.

Så ja, vi kan behöva misslyckas för att lära oss. Men misslyckande bör aldrig vara ett mål i sig självt. Det primära fokuset bör alltid vara att förstå vad du vill lära dig och validera. Jag ber därför vänligen om att vi släpper ”låt oss se vad som händer” när det gäller inlärning. Varje gång du hör någon säga ”Vi kommer att lära oss saker” bör ditt svar vara ”Vad och hur exakt?”.

Vill du skriva för Serious Scrum eller diskutera Scrum på allvar?

Lämna ett svar

Din e-postadress kommer inte publiceras.