Hypotesdriven utveckling – ett avgörande medel i transformationen

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

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 objektv 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 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 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 är 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/

Peter Senges 7 möjliga attityder i förhållande till en vision

Peter Senge beskriver i “The Fifth Discipline: The Art & Practice of the Learning Organization” 7 möjliga attityder i förhållande till en vision:

  1. Commitment: Wants it. Will make it happen. Creates whatever ”laws” (structures) are needed
  2. Enrollment: wants it. Will do whatever can be done within the “spirit of law.”
  3. Genuine compliance: See the benefits of the vision. Does everything excepted and more. “Follows the letter of the law.” ”Good soldier ”
  4. Formal compliance: On the whole, sees the benefits of the vision. Does what´s expected and no more. “Pretty good soldier”.
  5. Grudging compliance: Does not see the benefits of the vision. But, also, does not want to lose job. Does enough of what´s expected because he has to, but also lets it be known that he is not really on board.
  6. Noncompliance: Does not see benefits of vision and will not do what’s expected. I won’t do it; you can’t make me”.
  7. Apathy: neither for nor against vision. No interest. No energy. Is ot five o´clock yet?”

Optimera systemet med ett designsystem

Oavsett om vi skalar agilt eller driver ett antal parallella projekt vill vi undvika suboptimering i att flera initiativ ”uppfinner hjulet” eller att vi tappar bort den sammanhållna identiteten och upplevelsen. Vi vill heller inte gå bort oss kring de icke funktionella kraven och vänta med att ”fixa till dem på slutet”. Ett designsystem skapar förutsättningar för att bygga innovation effektivt och omfamna de icke funktionella och regulatoriska kraven och bygga in dem som affärsvärde i designsystemet. Ett exempel på ett icke funktionellt krav är tillgänglighet.

I ett designsystem beskriver vi komponenter, mönster och interaktion både med pixlar, riktlinjer och kod. Ett designsystem är gemensamt och uppdateras på ett ställe men används och utvecklas på flera ställen. Designsystemet ger oss en sanning, i kod. Designsystemet föder produkt/tjänst –produkt/tjänst föder designsystemet. Designsystemet är ett system. Ett system blir aldrig färdigt. Därför trivs designsystemet i en lean-agil kontext. Exempel på publika designsystem att inspireras av är: https://www.lightningdesignsystem.com/ och http://designsystem.morningstar.com/

Optimera systemet som en helhet

Oavsett hur tydlig man är och hur uppdaterad manualer och riktlinjer man har är det lätt hänt att en designer eller utvecklare drar iväg åt ett håll som passar det enskilda initiativet ”här och nu” men inte främjar systemet som en helhet. En framgångsfaktor är att optimera systemet som en helhet, något som projektorganisationer har mycket svårt för att göra men som den Lean-Agil kontexten är riggat för. I SAFe beskrivs det i princip nummer 2 ”Apply systems thinking.”

Ett designsystem är en konkret artefakt som främjar systems thinking och optimering av helheten.

Få alla team att utveckla systemet

När ett agilt team organiserar sig för att utveckla affärs- och kundvärde över tid bör teamet inte bara utgå från kund- och affärsbehov för sin produkt/tjänst. Teamet måste beakta alla behov som organisationen har och alla delar som affären värderar inklusive icke funktionella och regulatoriska krav. Om alla team samlar sig runt ett designsystem och tillsammans utveckla och optimerar systemet får vi det perspektivet. Team utvecklar sin produkt och tjänst men samtidig optimerar teamet systemet som en helhet genom att utveckla designsystemet. När vi beskriver och ”bygger in” icke funktionella och regulatoriska krav i systemet lyfter vi dem från ”måste göra” till faktiskt affärsvärde i fundamentet.

Ett centraliserat designsysstem ger teamen tid till mer innovation och decentraliserad initiativ

När vi skalar agilt ger vi teamen självbestämmande men för att optimera systemet som en helhet behöver vi en viss grad av centralisering. Ett designsystem är ett exempel på centraliserad styrning – som i sig ger teamen tid till mer innovation och decentraliserad initiativ.

Designsystemet behöver ett syfte och en vision

Ser vi designsystemet som en produkt och tjänst behöver vi också ge den en vision och syfte så att team och individer samlas  kring och omfamnar idén. Visionen ska bland skapa förståelse för varför det enskilda initiativet behöver stå tillbaka för helhetens bästa. Optimera system som en helhet kan initialt ta längre tid men lönar sig alltid i längden. I en teambaserad kontext med ständig utveckling och lärande istället för projekt med överlämningar och ”start/stop” är det naturligt för de allra flesta att optimera systemet som en helhet före lokal optimering.

Placera systemet i Lean UX Center of Excellence (LUXCE)

SAFe identifierar behovet av att hålla ihop UX-perspektivet när vi skalar agilt och inför begreppet Lean UX Center of Excellence (LUXCE). LUXCE blir naturligt ansvariga för Lean UX och för designsystemet för alla team och tåg. Det ger förutsättningar för en sammahållen upplevelse och en effektiv utveckling. Varje produkt/tjänst behöver ett team som har lite mer ansvar för produkten/tjänsten. Det vi i den gamla världen kallade förvaltning. För designsystemet får LUXCE  det uppdraget.

Ett centraliserat designsysstem ger helheten en sammanhållen upplevelse som möter de icke funktionella kraven och ger teamen mer tid till utveckling och innovation. Det är en investering som är lätt att räkna hem.

 



Team som äger effekten testar och analyserar bäst över tid

Användningstester är en av flera metoder i arbetet med kundcentrerad utveckling. Men oavsett hur ofta och högt vi påminner vår omvärld om det är det fortfarande vanligt med att man bara refererar till användningstester som grund för beslut. “Tester visar att alla användare föredrar Z”.

Det är också vanligt att användningstester som en del i en tidigare utforskning blir sanningar för helhetsbeslut över tid. ”Vi testade det på användare i projekt X för 3 år sedan …”.

  • Jag tror vi än en gång kan behöva förtydliga vad användningstester är i metodlådan och vilka indikationer vi kan förvänta oss av dem.
  • Vi behöver också prata mer om lärokurvor – dvs hur lång tid tar det att lära sig nya mönster. Utveckling och innovation kräver tålamod.
  • Arbeta mer med hypotester där validering av hypotesen defineras, dokumenteras  och kommuniceras.
  • Test och datanalys måste ägas av teamet. När vi tester i projekt som lämnas över riskerar vi att tappa sammanhang och detaljer.

Dataanalys och användningstester

  • Dataanalys berättar för oss VAD våra användare gör, NÄR de gör det och på VILKEN enhet och hur OFTA de gör det.
    • kvantitativ metoder = kundernas beteende
  • Användartester berättar för oss VARFÖR kunderna gör som de gör.
    • kvalitativa metoder = kundernas motivation.

Lärokurva och sätt att lära

Att testa en gång eller analysera en datapunkt är att helt bortse från lärokurvan. Tester måste upprepas för att ge svar på om användarna lär sig och därmed bör teamet äga effekten hela vägen över tid. Lösningen ska bevisa sig med hjälp av data och tester över tid.  Ett användningstesttest är för vagt för att ge mer än en indikation – en indikation på i vilken riktning man ska fortsätta utforska.

”Analyspunkt” bör utgöras av flera metoder – test och data.

Teamet testar bäst

Att minska antalet överlämningar är en av många drivers i agilt och Lean. Även när det gäller användningstester måste det gälla. Optimala är om teamet testar det de innoverar och optimerar (optimera = förvaltning i gamla världen). Om interaktionsdesignern sitter med funderingar på olika problemlösningar  är det den personen som måste testa olika varianter för att kunna ta sig vidare i arbetet.

Team som äger effekten testar bäst över tid.