Kategori: Hypotesdriven utveckling

• En del i den digitala transformationen är att vi går från jag tycker till vi vet, där vi vet uppstår i den hypotesdrivna utvecklingen när vi validerar med objektiv data
• Utan möjlighet att validera med objektiv data kan vi inte utveckla hypotesdrivet, dvs då faller transformationen
• En nytta som inte går att mäta är ingen nytta
• Målet är att tjäna pengar, transformation till en lean-agil kontext är ett medel. Utan transformation är chansen liten att nå framgång och tjäna pengar i en accelererande digital kontext.

Metod och process får aldrig bli målet. Det kan var lätt att gå i den fällen, inte minst vid en transformation där metod och process är avgörande katalysatorer för förändring. Men varken transformation som sådan, metod eller process är målet. Målet för ett företag är kort och gott att tjäna pengar. 

Väljer vi SAFe för att transformera vår verksamhet och utveckling från den destruktiva resurs- och lokaloptimerande verksamheten till att skapa värde över tid med kortast möjliga hållbara ledtider och hela systemet i fokus finns det vissa medel som är mer avgörande än andra. Jag vill lyfta fram tre.

Lean-agilt ledarskap, hypotesdriven utveckling och DevOps. Utan dessa tre ingen SAFe, ingen transformation och därmed ingen potential att nå lönsamhet över tid.

Denna bloggpost fokuserar på hypotesdriven utveckling. Som de två andra är det allas angelägenhet, därmed inte sagt att det är allas syssla. Men kom ihåg, vi är alla utvecklare.

Hypotesdriven utveckling: “Tillsammans definiera hypoteser som vi genom experiment validerar eller falsifierar med objektiv data.”

Hypotesdriven utveckling förklaras enklast genom att vi likt forskaren formulerar en hypotes och sen gör ett experiment för att validera eller falsifiera hypotesen. Experimentet i vår utveckling formulerar vi som en MVP. Eftersom hur snabbt vi lär oss är avgörande för vår potential att skapa värde bryter vi ner arbetet i små delar och itererar. För att accelerera lärandet utvecklar vi i cyklen bygga-mäta-lära. Genom verktyg som Lean ger oss för att optimera flödet fokuserar vi på att minimerar den totala tiden genom läroloopen. Ett av de största slöseriet i utvecklingsprocessen är som bekant att slösa med människors tid …

Både EPIC och Feature-processen i SAFe bygger på hypotesdriven utveckling med hjälp av Lean startup och Lean UX. Det är absolut grundläggande att förstå det och att det är allas angelägenhet. Låt er inte luras av metodnamnen Lean Startup och Lean UX där det är lätt att tro att ”det bara är för start ups” och “lean UX: det fixar väl UX:arna …”. Fel, fel, fel. Alla måste förstå och praktisera dessa metoder på alla nivåer. Annars är det bara att glömma transformationen.

Featuren innehåller tre viktiga parametrar:  hypotesformulering kring nyttan som ska var mätbar.

Det är helt avgörande för produkt- och systemutveckling i en komplex miljö att vi förstår och lär oss arbeta systematiskt med effekthemtagning i team och tåg –i små batchar.

Vägledning i Nyttorealisering 2.0

Det statliga initiativet ”E-delegationen” beskriver i sin publikation ”Vägledning i nyttorealisering 2.0” vad nytta är.
Citaten nedan är direkt kopierade från publikationen:

• En nytta har alltid ett kvantifierbart värde uttryckt i pengar, resurser eller kvalitetsmått (tid, volym, nöjd kund etc.).
  
• Nytta är en mätbar förändring vilken uppfattas som positiv av en eller flera intressenter och som bidrar till ett eller flera verksamhetsmål.
• En nytta som inte går att mäta är ingen nytta. 
• Utan nollmätning kan man bara gissa om en förändringsinsats har haft någon effekt.

Formulera hypoteser

I den traditionella projektstyrda utvecklingskontexten beställde vi saker och observerade progress vid beslutspunkter. När vi arbetar hypotesdrivet formulerar vi en hypotes och validerar löpande med objektiv data som vi matchar mot uppsatta leading indicators. Vi går från jag tycker – till vi vet med hjälp av objektiv data.

Men det räcker alltså inte med att formulera en hypotes. Den absolut avgörande faktorn och förmågan är om vi kan och har IT-förmågan att mäta och använda objektiv data för att validera vår hypotes med. För att följa den röda råden i bloggposten: utan data ingen hypotesdriven utveckling. Gällande data och metrics är det första vi måste förstå skillnaden mellan output och outcome och varför de två är viktiga men bör hållas isär.

I SAFe använder vi data (metrics) på två sätt – output och outcome.

Output ger oss en bild av i vilken hastighet vi leverera utan att nödvändigtvis berätta om det är värde vi levererar. Klickar vi på Metrics ingången i the big picture i SAFe hittar vi framför allt metrics kopplat till tågets output. Den datan är viktig för att kunna vara förutsägbar i vår leveranstakt gentemot affären/kunden. I Lean budget processen på portföljnivå måste vi ha en idé om tågens leveransförmåga och hastighet för att kunna prioritera och distribuera EPICs över tågen. Det är lätt att gå i fällan och bara säkra den här metrics-förmågan, vilket slutar i att vi visst hittar en förutsägbarhet och en hastighet men vi leverera därmed inte per automatik värde. Hastighet är inte lika med värde.

“What gets measured gets managed.” Det vi mäter är det vi styr verksamheten efter. Eftersom output är enklare att mäta än outcome är risken överhängande att vi styr affärsutvecklingen med fel siffror. ”Vi jobbar snabbt men levererar skräp”. Tips: fråga aldrig hur snabbt det går eller om det kan gå snabbare när du går på ett teams demo. Fråga efter värde! Och hur du kan hjälpa teamen att röja hinder för att skapa värde med kortare ledtider.

Outcome är förenklat att mäta värdet som våra EPICS och Features realiserar eller är på väg att realisera. Eftersom vi bara ska utveckla så länge det värde vi skapar är mer prioriterat än något annat potentiellt värde är det viktig att vi mäter kontinuerligt och över tid i våra iterationer. Team som äger effekten testar och analyserar bäst över tid.

I hypotesdriven utveckling använder vi leading indicators för att validera våra hypoteser mot medan vi utvecklar dem. De är framåtriktade mätetal som vi kan påverka till skillnad mot traditionella lagging indicators som är mer av konstaterande art. IT-förmågan att arbeta med leading indicators utvecklar vi i pipelinen och de hänger tätt ihop med release on demand med funktioner som nollmätning, funnel analys, feature toggles, A/B tester, dark releaser osv.

När vi hanterar leadning indicatos måste vi vara på vår vakt att de inte är vanity metrics, dvs mätetal som är enkla att mäta med som inte direkt kan påverka värdet. 

Här är ett exempel på hur variablerna kan förhålla sig till varandra:

• Affärsmål: väga 75 kg
• Vanity metric: mäta antal gånger man ställer sig på vågen (ej relevant)
• Lagging indicator: jag väger just nu 80 kg (konstaterande)
• Leading indicator 1: mäta kalorier i Pizzan framför oss (actionable)
• Leading indicator 2: mäta förbränning i träningsaktiviteten (actionable)

Sammanfattning

• Det finns massor av medel för att nå målet, vissa medel är mer avgörande än andra
• Hypotesdriven utveckling är det övergripande konceptet och processen att bedriva utveckling på i SAFe
• Hypotesdriven utveckling är allas angelägenhet
• Vi kan inte utveckla hypotesdrivet om vi inte har tillgång till objektiv data för att validera med och göra nollmätningar
• Vi behöver mäta både output och outcome. Det är två olika metrics och vi måste förstå hur de förhåller sig till varandra och till målet/visionen

Referenser

• https://www.scaledagileframework.com/metrics/
• https://www.scaledagileframework.com/guidance-applied-innovation-accounting-in-safe/
• https://www.bokus.com/bok/9781491953600/lean-ux-2e/
• https://www.bokus.com/bok/9780307887894/the-lean-startup/
• https://www.scaledagileframework.com/blog/innovation-accounting-helps-to-quickly-evaluate-mvps/
• https://www.digg.se/nyheter–publikationer/Publikationer/nyttorealisering