Mäta idén

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. 

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.

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

De metrics du kommer komma fram til kommer kunna appliseras på tre olika sätt

• Mäta design. T ex kan du mäta hur många klicks det krävs hos gipsat.nu för att från att du ser ett snyggt bandage lägga en betald order på detta bandage. Detta behöver du mäta live, det kan du räkna ut av din design.
• Mäta med test. Svarstider är ett exempel där du på några olika sätt kan mäta i testmijö, andra saker är mänsklig interaktion. Testmiljön kan vara en ganska enkel prototyp.
• Mäta live. Hur en hypotes avseende kunders beteende funhgerar det är alldeles utmärkt att göra live. Detta kan du med fördel göra i A/B-tester och med möjligheten att slå på och av funktionalitet

Värden och outcomes ser ut som i bilden här för gipsat.nu.Metrics är Archimate en specialisering av en driver, det som är vad som driver idén, dessa kommer ju som metrics vara drivande ur perspektivet att du kommer sträva efter att uppfylla.

Men så svårt måste det inte vara: har du formulerat id'en så kan du utgå från de värden du vill skapa.

Värden och outcomes ser ut som i bilden här för gipsat.nu.Metrics är Archimate en specialisering av en driver, det som är vad som driver idén, dessa kommer ju som metrics vara drivande ur perspektivet att du kommer sträva efter att uppfylla.

Men så svårt måste det inte vara: har du formulerat id'en så kan du utgå från de värden du vill skapa.

nog 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.

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