På tidigt 1900-tal definierade Vilfredo Pareto (känd italiensk
sociolog, nationalekonom och moralfilosof) den så kallade paretoprincipen. Paretoprincipen
är en empirisk regel enligt vilken 20 procent av orsakerna ofta står för 80
procent av verkan. I Vilfredo Paretos exempel visade han att 20 procent av
den italienska befolkningen (funktionerna) innehade 80 procent av egendomen
(värdet).
I perspektivet utveckling
kan vi applicera Paretoprincipen
på hur vi ska bryta ner och lansera våra
features. Principen säger oss att vi får ut 80 % av värdet genom endast 20 % av
funktionerna. En stor mängd av
de funktioner vi utvecklar används aldrig eller sällan och skapar således inget
eller litet värde. Fokus borde således läggas på de 20 procenten.
I böcker om Agil
systemutveckling refereras ofta till Paretoprincipen. Ser vi på den tionde
principen i det agila manifestet ”Enkelhet – konsten att maximera
mängden arbete som inte görs – är grundläggande” går den hand i hand med
Pareotprincipen. Konsten att maximera mängden arbete som inte görs det vill säga fokusera på de 20 procenten, fokusera inte
på ”allt”.
Tongivande i Agil
systemutveckling är att fokusera på att utveckla och leverera i små batchar
vilket ger oss snabb feedback om det vi gör adderar värde eller inte. I stora
projekt vet vi inte förens i slutet vilka de 20 procenten var som stod för en
majoritet av värdet. I projekt krävs det att vi utvecklar 100 procent för att
vi i efterhand ska kunna konstatera vilka av alla funktioner (de 20 procenten) var
som gav 80 procent av värdet.
Hantera och
prioritera kön
Men hur vet vi vilka
av de features vi ska göra är inom ramen för de 20 procenten som potentiellt utgör 80 procent av värdet? För att optimera värdet behöver vi addera
mekanismer från lean.
I lean produktutveckling är små batchar och hantering och prioritering
av köer tongivande. Genom att prioritera innehållet (små batchar) i kön genom
att små jobb med högt potentiellt värdet får gå först minimerar vi risken att
träffa fel bland våra features.
Y-axeln som beskriver effekthemtagningen säkrar vi genom att
leverera ofta för att ta hem feedback kring hur mycket värde vi skapar. Här hjälper
oss SCRUM med struktur för att säkra den processen.
X-axeln som utgörs av de funktioner, eller features, vi
utvecklar säkrar vi genom lean produktutveckling och värdebaserad prioritering.
Mekanismerna i Lean startup som bygga-mäta-lära hjälper oss.
Sammanfattning
Paretoproncipen och agilt driver på oss att lansera tidigt och ofta med inställningen att en stor del av värdet kommer från en mindre del av de totala antalet features.
Lean hjälper oss att prioritera ibland alla features och ta
små beslut ofta.
I lean strävar vi efter att optimera flödet och tiden mellan idé till effekthemtagning (Time to market). Att styra på den parametern är framförallt gångbart i en statisk kontext. I en dynamisk kontext som digital utvecklg behäver vi fler parametrar.
I digital utveckling i en komplex kontext blir tiden från idé till kunskap (Time to knowledge) central. När vi släpper ny funktionalitet till användaren och får feedback är det kunskap genom feedback vi främst är ute efter. Affärsvärdet kan realiseras initialt men det är över tid som den stora potentialen finns. Där behöver vår affärsprocess vara inbyggd i vår utvecklingsprocess. Time to cash sker iterativt och genom att se på affärsvärde som något vi upptäcker över tid – inte som något fördefinierat.
Kunskap kan vi ofta hämta hem snabbare än värde
Därför är det viktigt att vi jobbar smartare och drivs av att lära oss genom feedback för att upptäcka det potentiella affärsvärdet genom iterativa lanseringar. Kunskap kan vi ofta hämta hem snabbare än värde men utan kunskap riskerar vi att missa var värdet finns på en rörlig marknaden där vi behöver kunna anpassa oss och ställa om snabbt till nya krav. Nokia var duktiga på time to market och time to cash på en befintlig marknad men missade time to knowlege.
Time to market, time to knowledge och time to cash är beroende av varandra men skiljer sig åt i hur vi mäter dem och vad vi vill att de ska göra och när. Det är när vi optimerar de tre delarna utifrån ett helhetstänk vi kan få rejäl utväxling. Var för sig gör de marginell nytta.
Time to market (output) – hur agil är vår pipeline?
Time to knowledge (outcome) – hur lär vi oss och går från “magkänsla” till “vi vet”?
Time to cash (outcome) – hur affärdriven och iterativ är vår utvecklingsprocess?
Time to market – tiden det tar för att ta en produkt till marknaden. Det är en lagging indicator, vi konstaterar tiden i efterhand. Värdet att få ner tiden är primärt kopplat till att vi vill lära oss snabbare inte nödvändigtvis att vi skapar värde snabbare. Det finns inget egenvärde i time to market – möjligen för ett systemteam. Time to market säger inget om värdet vi vill uppnå men spelar stor roll i hur snabbt vi kan få svar på om det finns något värde att hämta hem på marknaden.
Time to knowledge – tiden det tar från att vi definerar vår hypotes till att vi validerar den. Mätvärdet vi vill validera med är en leading indicator. Eftersom vi vill lära snabbt utvecklar vi i små batchar uttryckta som hypoteser som ger oss snabb feedback vilket gör att vi lär oss snabbare. Mätpunkter där vi validerar sätts upp som ”learning milestones”.
Time to cash – tiden det tar från idé till att vi skapar intäkt. Är intäkten högre än kostnaden för utvecklingen? Vi mäter över tid eftersom intäkter skapas över tid. Mätvärdet är av monetär art.
Time to cash och time to knowledge kräver att vi definera “learning milestons” där vi utvärderar löpande med objektiv data.
Time to cash surfar på time to market
Är inte detta vattenfall tänker du? Nej, inte om vi gör det i samma process, i samma loop, men ser det som olika mätvärden som har olika syften under olika tidshorisonter. En leading indicator surfar på en lagging indicator. Time to knowledge & cash surfar på time to market. Ju smidigare pipeline för time to market ju snabbare time to knowledge & cash.
Sammanfattning
I digital affärsutveckling är Time to market ett medel för att nå kunskap och intäkter
Affärsvärde upptäcker vi när vi utvecklar, det kan vi inte definera på förhand
Det är viktigare att vi lär oss snabbt än att vi jobbar snabbt
Att jobba snabbt leder sällan till att vi lär oss snabbt
Vår framgång bygger på att vi lär oss snabbare än våra konkurrenter (time to knowledge)
Ju smidigare pipeline för time to market ju snabbare time to knowledge & cash.
Den digitala transformationen är större än omställningen från resursoptimering till flödeseffektivisering. Transformationen utmanar också kulturen. Vi säger att vi förändrar kulturen efter att vi förändrar organisationen. När vi går från projektleverans till teamleverans förändrar vi en del av organisationen genom att vi sätter vi upp virtuella organisationer och introducerar nya metoder inom produkt- och systemutveckling. Om vi säger att vi förändrar kulturen efter att vi förändrar organisationen har vi ändå mycket att vinna på att inleda förändringen under metodskiftet.
Vi behöver både utmana hur vi tänker och hur vi gör. I förlängningen kräver transformationen att vi utvecklar vårt språk och vårt tänkande – där bor kulturen.
En gång lärde vi oss fel att nyckeln till ekonomisk framgång är effektivitet. Om vi tror på det kommer vi att fokusera på mätvärden som kapacitetsutnyttjande och hantera utvecklingsprocessen
med hög utnyttjandegrad (resursoptimering). Vi kommer mäta leverabler (output) utan att reflektera över värdet (outcome).
En gång lärde vi oss fel att att nyckeln till ekonomisk framgång är
överensstämmelse med planen. Om vi tror på det kommer vi att fokusera på att förhindra och korrigera avvikelser från planen. Vi kommer att investera kraft i att hantera oväntade hinder och ignorera nya möjligheter (innovation uteblir).
I omställningen från projekt och vattenfall till agila team och lean-agil
utveckling är språket centralt. Hur man förhåller sig till orden ”snabbare”, ”plan” och ”effektivare” avslöjar en del var man är i sin agila omställning. Vi behöver hjälpas åt i berättelsen att navigera rätt bland orden och att välja ett språk som bäddar för en uppdaterad kultur.
Vi ska inte jobba snabbare, vi ska jobba smartare.
Det finns flera saker som trumfar att jobba snabbare. Små batchar tex. En stor del av Lean produktutveckling bygger på processer för att jobba med mindre batchar. Vi omfamnar mindre batchar därför mindre batchar ger feedback snabbare och realiserar potentiellt värde snabbare. Det har inget att göra med att vi jobbar snabbare eller effektivare eller att kunderna får snabbare leveranser. Kunder vill inte nödvändigtvis få snabba leveranser de vill få rätt (= värde) leveranser.
Vi ska inte jobba snabbare, vi ska jobba smartare tillsammans och medlet är små ekonomiskt och storleksmässigt kvantifierade batchar uttryckta som hypoteser som ger oss snabb feedback vilket gör att vi lär oss snabbare och kan ta bättre ekonomiska beslut.
Genom att levererar i små batchar (iterationer och inkrement) tar vi mindre risker och vi hämtar hem det potentiella värdet snabbare. Det leder också till att vi får snabbare feedback. Och det är bara genom feedback baserad på objektiv data från våra IT-system och från våra kunder och användare som vi kan lära oss. I den projektdrivna kontexten sker lärandet sent eller aldrig.
Jobba snabbare spelar ingen roll om vi inte attackerar våra köer och storleken på jobben i dem, som exemplet nedan visar:
Jobba snabbare -> Små jobb -> Snabb feedback = ny kunskap snabbare
Jobba snabbare -> Stora jobb -> Långsam feedback= ny kunskap senare
Sammanfattning
Snabbar och effektivare (på fel sätt) väcker ett skadligt beteende som vi vill transformera oss från.
Vi ska inte jobba snabbare, vi ska jobba smartare.
Det här är en variant på ett klassiskt radband. Tanken med “Värdeloopsarmbandet” är att det ska hjälpa till att ge vägledning och fokus i transformationen. Det här är en första MVP. Håller konceptet? Ge gärna feedback: klas.fjarstedt [snabel-a] gmail.com
Få fokus på vägen till värdet med hjälp av Värdeloopsarmbandet
Alla tider hela tiden, är tider i förändring. De som är och har varit framgångsrika är de som surfar med förändringen och inte strävar mot. Det som nu sker i takt med digitaliseringen är att förändringen accelererar. Ett dynamiskt och komplext tillstånd är vardag och vi måste möta den vardagen genom att ständigt utveckla både våra produkter/tjänster och de processer vi utvecklar dem med. En agil organisation med ett lean-agilt mindset utvecklar båda.
I denna föränderliga värld finns det ett antal kärnvärden och principer som är tidlösa. Värdeloopsarmbandet är till för att hjälpa dig i vardagen att hitta kraften framåt genom att påminnas om ett par principer inspirerade av bland annat systemtänkande, lean och agilt.
När du fastnar i gamla hjulspår eller om någon har ett destruktivt traditionellt synsätt kring frågor i en dynamisk kontext – andas och följ värdeloopen från den vita Värdepärlan genom – Ledarskapspärlan (rosa) – Motivationspärlan (grön) – Kunskapspärlan (gul) – Kommunikationspärlan (cerise) – Hypotespärlan (pistage) – Innovationspärlan (mörkblå) – Flödespärlan (orange) – Jag-Du-Teampärlorna (genomskinnliga) – Helhetspärlan (blå).
Värdepärlan
Den vita värdepärlan – början och slutet på loopen. När alla färger reflekteras framträder vitt och när alla andra pärlor samverkar skapas förutsättningar för värde.
Målet, som Lean har lärt oss, är att leverera den maximala mängden kundvärde på den kortast möjliga hållbara ledtiden med den högsta möjliga kvaliteten för kunder och samhället i stort. Hög moral, säkerhet och kundnöjdhet är andra viktiga mål och syften. Där börjar och slutar crikeln.
Ledarskapspärlan
Den rosa ledarksapspärlan påminner oss om att vi alla är ledare för minst en person – oss själva. Där börjar ledarskapet. Att leda oss själva och andra innebär att kunna kommunicera och visualisera vart vi ska och varför. Hur vi tar oss dit svarar teamet bäst på.
Att leda andra innebära att lära andra. Och för att lära andra måste du som ledare hela tiden lära. Och när vi lär och lär ut blir vi också varse perspektiven och inser att bara för att vi tittar åt samma håll ser vi inte samma sak. Genom empati skapar du som ledaren en förståelse för att olika männsikor ger gruppen olika perspektiv som rätt aggregerat skapar kreativitet.
Motivationspärlan
Den rosa motivationspärlan påminner oss om våra inneboende grundläggande drivkrafter. När vi föds är vi av naturen nyfikna. Det som motiverar oss är syfte, mästerskap och självstyre. Med tiden är det lätt att tappa bort de inre drivkrafterna.
Syfte manar oss att göra något som känns meningsfullt och viktigt utöver det monetära. Mästerskap väcker drivkraften att bli bättre, att lära oss mer. Självstyre är vår grundläggande vilja att styra oss själva. Du äger din egen motivation och inget hindar dig från att påverka andras.
Kunskapspärlan
Den gröna kunskapspärlan utmanar oss att accelererar vårt lärande. Den är vår katalysator när vi står inför en transformation. Den påminner oss om att intelligens och personlighet kan utvecklas – att min potential är okänd. Den stärker mitt dynamiska mindset och gör lärandet till ett mål i sig. Den uppmanar mig att alltid vara hungrig efter kunskap och att alltid vara villig att erkänna när jag inte vet.
Kunskapspärlan tar “att lära” förbi lärandet till en plats där nytänkande uppstår, där lärande innebär att tänka om och då också omfatta en avgörande sinnesförändring i oss.
Kommunikationspärlan
Den gula kommunikationspärlan välkomnar motståndet och olikheterna och påminner oss om grundbetydelsen i kommunikation – att ”göra något gemensamt”. Kommunikation bäddar för förflyttning. Om jag inte har förmågan att förflytta mig i tanken när jag möter på motstånd kommer jag heller aldrig att utvecklas. Dialogen hjälper oss att vidga våra gränser tillsammans och diskussionen visar våra enskilda åsikter.
Det är inte bråttom att förstå. Det är bråttom att få oss att förstå att vi behöver förstå. Kommunikation hjälper oss med det.
Hypotespärlan
Den cerisa hypotespärlan hjälper oss att gå från jag tycker till vi vet, där vi vet uppstår i den hypotesdrivna utvecklingen när vi validerar eller falsifierar med objektiv data. Hypotesdriven utveckling gör oss alla till hungriga forskare som jagar data i form av värdeindikatorer att validera med.
Hypotesen tar oss från stelheten i det linjära tänkandet in i det cirkulära där vi tar oss framåt i den ständiga loopen bygga–mäta–lära. From know-it-all to learn-it-all.
Innovationspärlan
Den mörkblå innovationspärlan uppmanar oss om att inte upprepa samma recept utan att utforska någonting nytt. Den öppnar våra ögon mot omvärlden och tar oss ut i verkligheten där kundernas faktiska behov väntar på innovativa lösningar.
Innovationspärlan påminner oss om att innovation bara kan hända om vi ger den tid och kraft. Därför fyller vi aldrig våra agendor till 100 % utan lämnar alltid tid till reflektion och omvärldsspaning – innovatörens luft och vatten.
Använd inte innovationens inneboende kraft till att lura systemet, använd det till att utveckla det. Innovera systemet som en helhet.
Flödespärlan
Den orangea flödesspärlan påminner oss om värdets väg från idé till konvertering. Se till att den vägen blir så kort som möjligt utan att gör avkall på hållbarhet och kvalitet. Målet är inte snabbhet, det är ett medel. Ju snabbare vi är i vårt flöde desto tidigare får vi feedback från kunder och systemet. Genom feedback lär vi oss. Ett jämnt flöde skapar harmoni som både lärande och konvertering mår bra av.
Jag-du-teampärlorna
De tre jag-du-teampärlorna är genomskinliga, lika osynliga som kraften i teamet när vi arbetar tillsammans mot samma mål. Teamet består av individer där jag tillsammans är stark. Ett team är inte, ett team blir – genom individerna. För att det ska hända behöver vi en grundläggande respekt för människor. Människor är inte resurser, människor är kompetenser och i teamet aggregerar vi kompetenserna till en förmåga vida överstigande den individuella.
Helhetspärlan
Den blå helhetspärlan är vår version av den blå planeten som astronauterna ser från månen. Först med den blicken kan vi förstå hur saker hänger ihop och att en del är beroende av en annan fast att det vid första anblicken inte verkar så.
Helhetspärlan uppmanar oss att ta ett steg tillbaka och betrakta vår omgivning i ett helhetsperspektiv. Då blir det uppenbart att vi måste optimera systemet med den blicken. Lokal optimering driven ur falska incitament är inte bara destruktiv för den enskilda leveransen utan också för alla delar i systemet. Se skönheten i helheten och kom ihåg att delarna också är helheter. Och det är bara vi som helheter som kan optimera systemet.
”Veckans mest udda nyhet – från Tessla!” (Dog mode) ”Volvo i bottenskiktet i ny kvalitetsmätning” (Lexus och Toyota i topp)
”Jaguares Tesladödare en dröm att köra”
Tesla kan svara blixtsnabbt på ett kundönskemål (Dog Mode) med att uppdatera mjukvaran i bilen som förstås blir en PR-succe. Men sett till produktivitet i fabriken ligger de många gånger efter liknande bilar i antalet skeppade Teslas per anställd. Väntelistan är lång och konkurrenterna börjar komma i fatt. (Se tex Jaguare-rubriken)
Toyota, som inte just nu kan slå Tesla i snabbhet med sina mjukvarauppdateringar, är å andra sidan bra mycket mer effektiva i fabriken och dessutom bäst i klassen kring kvalitet.
Vem kommer vinna i längden då? Alla biltillverkare kommer att kunna leverera elbilar i framtiden men vem kan leverera med kortast möjliga ledtid och kontinuerligt erbjuda förbättringar via mjukvaruuppdateringar?
Ja, svaret står väl skrivet i taket på Lean-huset. Den som kan leverera: Värde med kortast möjliga hållbara ledtider och högsta kvalitet för människor och sammhället …
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 hursnabbtvi 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 …
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
Börja med att anamma inställningen att alla är utvecklare. Sen har vi olika prefix som tex systemutvecklare, verksamhetsutvecklare, metodutvecklare, UXutvecklare osv … Men alla är utvecklare helt enkelt. Och därför behöver vi oftare utveckla tillsammans.
Varför vi ska mobbutveckla och hur det fungerar kan du läsa och lyssna mer om via dessa länkar:
Som ledare handlar det om att skapa förutsättningar för att få det att hända
Men hur kommer du igång? Eftersom det handlar om förändring kan du per automatik inte räkna med draghjälp. Som ledare handlar det om att skapa förutsättningar för att få det att hända. Effekten av mobbutveckling måste upplevas och det går inte bara genom teori förstå fördelarna. Seeing is believing. Så, kavla upp armarna och:
Hitta minst två personer som du delar drivet och intresset med. Helst en kodare (driver) och en UX:are (navigatör). Men två personer gör ingen mobb. Men det är en början.
Är du produktägare – gör aktiviteten till ett mål med sprinten. Kom ihåg att ett agilt team utvecklar sin produkt/tjänst och utvecklar hur vi arbetar tillsammans. Markera det senare som PO genom att göra way of working viktigast i en sprint. Helt plötsligt är sprintmålet ”vi ska mobbutveckla”.
Hämta/låna/köp en stor TV-apparat.
Fixa ett bord att ställa framför teven (finns ofta bord i källaren).
Muta in en plats som blir dedikerad till mobbutveckling
Sätt upp lappar på vångingsplanet som berättar vad ni gör. Kommunicera och missionera – iterera.
Boka in de ni vill samarbeta med (team, personer, projekt). Kalla dem till platsen där skärmen står. ”Är mötet här? Ja, och nu upphör mötet och overgår till utveckling.”
Ganska snabbt får ni anhängare. Håll dem varma. Behåll momentum genom att bjuda in och boka upp.
Sätt upp mål kopplat till själva aktiviteten. ”Vi ska mobbutveckla x timmar innan jul”.
Blogga internt om vad ni gör och med vilka och förstås vilken effekt ni skapar.
Vill du ha draghjälp från SAFe kan du slänga upp princip 1, 2, 8 och 9 på väggen och peka på om nån skulle få för sig att ifrågasätta vad som händer.
Varje morgon passerar jag två gratisparkeringsplatser inom 200 meter från varandra. För båda gäller att behovet av parkering är större än utbudet.
På den ena parkeringsplatsen (nummer 1) nyttjas ytan till ca 85 %. På den andra (nummer 2) nyttjas ytan till 100 %. Skillnaden på parkeringsplatserna är markeringarna i asfalten. På parkeringsplatsen som nyttjar sin yta till 100 % (nummer 2) finns det tydliga markeringar för parkeringsrutorna vilket det inte gör för den andra.
Människan har svårt att naturligt optimera system i ett helhetsperspektiv. Tänk till exempel på klimatförändringarna och orsakerna till dem.
Ett missförstånd jag springer på då och då är att autonoma agila team “får göra precis som de vill”. Så är det förstås inte och tur är väl det. Decentraliserade team behöver centraliserade riktlinjer, de behöver tydliga markeringar i marken. Annars riskerar vi lokal optimering. Optimera systemet som en helhet: jag får en parkeringsplats och använder ytan för att optimera att fler får parkeringsplats. Lokal optimering: jag får en parkeringsplats men på bekostnad av 1,5 platser.
Team ska naturligtvis utveckla sin produkt och tjänst och samtidig optimerar teamet systemet som en helhet. Oavsett vad de gör behöver de bland annat ta ett gemensamt ansvar för affärsvärde, kundvärde, regulatoriska krav, kvalitet mm.
Markeringarna i marken för ett team är riktning och riktlinjer.
Riktning ger vi teamen genom vision, syfte och strategiska teman. “Min bil är viktig men den är en del i en större helhet.”
Riktlinjer via bland annat Intentional architecture och design system (UX,UI). “Det blir plats för fler om jag parkerar bilen inom en specificerad ruta. Då får fler plats och kan lägga tid på att skapa värde istället för att leta parkering.”
När vi optimerar lokalt skapar vi sekundära behov i andra delar av systemet som tex leta parkeringsplats. Att lösa sekundära behov är som bekant slöseri. När vi alla optimerar systemet som en helhet får vi mer tid och kraft till innovation och utveckling.
Systemet optimerar inte systemet. Parkeringsplatsen optimerar inte sig själv. Människor optimerar systemet. Och människor behöver riktning och riktlinjer för att göra det bra.
A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system. The secret is cooperation between components toward the aim of the organization. – W. Edwards Deming
Din konkurrensfördel är inte dina idéer eller dina produkter. Din konkurrensfördel är kvalitén på din kod och hur snabbt du kan få ut den till användarna. Idéer är lätt att kopiera. Antingen är man först ut på marknaden och drar nytta av det eller så är man tvåa och surfar på ettans lärdomar och misstag. Vinnaren är per automatik ingen av dem. Vinnaren är den som snabbats kan iterera sina idéer i en föränderlig värld. Inte nödvändigtvis vare sig den som är först ut eller tvåa.
Det är när vi integrerar vi lär oss. Både hur systemet fungerar och vad kunderna tycker om vår produkt. Att snabba på lärandet är att ta ett aktivt beslut kring överlevnad i en värld som ständigt förändras.
The Continuous Delivery Pipeline i SAFe representerar förmågan att leverera ny funktionalitet till användaren ofta. Det vill säga att lära sig snabbare. I SAFe är den själva ryggraden i tågets värdeström. Den har nu blivit så pass central att den ses som en av fem nyckelkompetenser för Lean Enterprises.
DevOps, som är en del av pipelinen, har sedan tidigare i SAFe fått ett eget team i System teamet som ska driva upp den förmågan. Ett smart sätt att utveckla den IT-och kulturförmågan.
Men hur får vi hela pipelinen att snurra? Ett knep kan vara att använda ett Strategiskt tema för att höja upp (affärs)värdet av The Continuous Delivery Pipeline. I stor sätt alla företag oavsett inriktning och produkter skulle kunna sätta ett strategiskt tema kopplat till att utveckla pipelinen.
Default strategiskt tema för random tåg/portfölj: Develop The Continuous Delivery Pipeline
Alla team i tåget behöver bidra till utvecklingen av pipelinen
Continuous Delivery Pipeline = affärsvärde
Börja resonera kring Cost of delay. Vad kostar det oss om vi inte gör det? Vad kostar det oss om vi inte har förmågan att göra det?
Visualisera och attackera flaskhalsarna som uppehåller sig i pipelinen. De hindrar effektivt affärsvärde att nå marknaden. Klockan tickar …
Använd DevOps Health Radar för att identifiera organisationens förmåga och för att identifiera epics, features och enablers
Se Continuous Delivery Pipeline som IT-förmåga, metod (hypotesdriven utveckling) och förmåga till monitorering
Bygg kompetens och förmåga kring det
Idéer blir till hypoteser, blir till kod, blir till affärsvärde, blir till kunskap. Hur snabbt kan du iterera den processen?
Att spana kring framtida produkter och tjänster kan vara nog så roligt. Men i vår strävan att utveckla och utvecklas behöver vi förhålla oss till att all utveckling uppstår och försvinner i parenteser. Det ser vi lättare om vi tittar bakåt i tiden än framåt. Tittar vi bakåt får vi hjälp med att komma förbi substantiven och istället fokusera på verb och processer i en kontinuerlig föränderlig värld. Då kan vi börja förstå att allt lever bara inom korta parenteser i tiden. Frågan är bara hur mycket tid det är i mellan.
Sett till den digitala utvecklingen kopplat till webben och internet är tidshorisonten bakåt försvinnande kort. Så nära i tiden som 1991 gick startskottet för det vi känner som world wide web i och med att Tim Berners-Lee publicerade den första webbsidan.
Sedan dess har en mängd olika tekniker, produkter och tjänster uppstått och försvunnit. Substantiv som har levt i små korta parantares. Och i sin respektive parantesen varit den absolut hetaste sak man kunde tänka sig. Allt medan de basala behoven är konstanta – äta, sova, bo, kommunicera, socialisera, leka, dansa osv. Bara inom området musik har vi sett flertalet substantiv komma och gå i korta parenteser, som tex MiniDiscen, mp.3-spelaren och CD-spelaren.
När vi är inne i en parantes är det lätt att ta den för universell och evig. Tittar man enkom på statistiken kopplat till substantiven i en uppgång är det lätt att bli fartblind. Lex Nokia, Kodak, Facit, Alta Vista, Adobe Flash, WAP m fl.
Är det så att substantiven gör oss blinda? Är det tjänsten eller kanalen som gör produkten framgångsrik? Vad behöver vi för data för att svara på det?
Allt för länge har vi tagit statiska beslut i en dynamisk värld
Peter Senge förklarar Blackfoot folkets synsätt på världen i klippet nedan.
Blackfoot folkets förhållningssätt har gjort att de har existerat i 15 000 år. Bra mycket längre än andra civilisationer. Det finns oerhört mycket att lära av det förhållningssättet när vi utvecklar nya produkter och tjänster. Allting är i ständig utveckling. Förändringen är dynamisk. Vi blir aldrig färdiga.
designa och koda för förändring
Men hur ska vi som individer och organisationer förhålla oss till den ständiga förändringen? Genom att inspireras av att titta bakåt i tiden och förstå att allt är substantiv i paranteser och när vi utvecklar nya produkter och tjänster kommer de bara leva en kort tid. Vi måste designa och koda för förändring – från början. Och eftersom allting är i ständig förändring måste vi lära oss nya saker hela tiden.
Two years after the end of their careers, 78 percent of NFL players have gone into personal bankruptcy or have severe financial concerns, writes Aftonbladet. Could it be a result of too little purpose and too much vision?
In the western world it is seldom funds that missing but rather a lack of purpose. Projects and development initiatives are allocated funds, but rarely succeed in delivering beyond expectations or in some cases deliver at all. We have all the prerequisite but we deliver “just okej”. Few ends up in position 1-3 of Peter Senges 7 possible attitudes in relation to a vision. The methods and the leadership that define and communicate meaning shine with their absence.
When players in the NFL have reached their goals and made their money, can their financial concerns be a sign of lack of meaning (purpose) in a larger context? The first of seven mortal sins according to Deming: Lack of constancy of purpose.
Lack of meaning when the lights go out at the stage rarely bodes well.
Vision, purpose and strategy separately
To achieve short-term victories, a vision can suffice. “I will run 5 km in 22 minutes” (vision). But then what (purpose)?
With only a purpose defined, we do not get the energy and focus that a vision gives us when we visualize it for our self and communicate it outward. “I want to feel better so I run” (purpose).” But where do I want (vision)?
Without a strategy, we are not effective in achieving our vision and living our purpose. “I will run 5 km in 22 minutes because I want to feel better. (vision and purpose) ” But how do I train then (strategy)?
Create prerequisite for change
To achieve real change, we need to articulate and communicate both vision, purpose, strategy and mission. We need to highlight their relations and context to the individual and the team. We need to give everyone a meaning to gather around.
Pia Sundhage inspiringly describes in her book “Spela på bästa fot : att leda med glädje” how she led change in the US national team in soccer. When she took over the team for the 2008 Olympics, the given goal / vision was Olympic gold. But the success came by communicating the need for change and she did not stop at the vision, she also defined and communicated a purpose and a strategy.
The goal / vision (what): Win Olympic gold
Purpose (why): Change. Getting better together. To develop the game from physics soccer to technical soccer . “Win respect for the way we play”.
Strategy (how): Fitness training with the ball. Pulse measurement. Fitness test. Play a lot of training games.
Decentralize decisions and optimize the system as a whole
When we develop in a scaled context, we need vision, purpose, strategy and mission so that decentralized decisions in the teams do not lead to local optimization. Optimizing the system as a whole is an important principle in Lean-Agil development. Vision, purpose, strategy and mission become guidelines that keeps teams and individuals focused without sacrificing their own initiatives and solutions. Vision and purpose gives an understanding of what we do now and what lies in our roadmap going forward.
Internal and external motivation
If vision is the goal, then purpose is the way. By focusing on the road
(purpose) we often deliver a better result on our journey towards the vision. Knowledge
workers who are driven by inner motivation deliver higher quality than those
driven by external motivation, says Daniel Pink. Inner motivation defines Pink
as autonomy, purpose and masteryand
examples of external motivation are financial bonuses.
By working actively with both vision, purpose, strategy and mission, we move in the same direction in and between teams and between products and technologies and we gain a shared understanding of strategy and priorities.
Summary
It is not enough with just a vision or just a purpose. We need both to create direction and meaning. Or as Nietzsche said “Whoever has a why to live for, endures every how“.
Två år efter karriärens slut har 78 procent av NFL-spelarna gått i personlig konkurs eller har svåra ekonomiska bekymmer, skriver Aftonbladet. Kan det vara ett utslag av för lite syfte och för mycket vision?
I västvärlden är det sällan medel som behövs utan mening som saknas. Projekt och utvecklingsintiativ tilldelas medel men lyckas sällan leverera över förväntan eller i vissa fall leverera över huvud taget. Vi har alla förutsättningen men levererar bara ok. Få hamnar på den över halvan av Peter Senges 7 möjliga attityder i förhållande till en vision. De metoder och det ledarskap som definerar och kommunicear mening lyser med sin frånvaro.
När spelarna i NFL har nått sina mål och tjänat sina pengar kan deras ekonomiska bekymmer vara ett tecken på avsaknad av mening (syfte) i ett större sammanhang? Den första av sju dödliga synder enligt Deming: Lack of constancy of purpose.
Brist på mening när lamporna på scenen har släckts bådar sannerligen sällan gott.
Vison, syfte och strategi var för sig
För att nå kortsiktiga segrar kan det räcka med en vision. ”Jag ska springa 5 km på 22 minuter” (vision). Men sen då (syftet)?
Med bara ett syfte definierat får vi inte den energi och det fokus som en vision ger oss när vi visualiserar den för vårt inre och kommunicerar den utåt. ”Jag vill må bättre så jag springer” (syfte).” Men vart ska jag då (vision)?
Utan en strategi är vi inte effektiva i att nå vår vision och leva vårt syfte. ”Jag ska springa 5 km på 22 minuter för jag vill må bättre. (vision och syfte)” Men hur tränar jag då (strategi)?
Skapa förutsättning för förändring
För att nå förändring på riktigt behöver vi artikulera och kommunicera både vision, syfte, strategi och mission. Vi behöver synnliggöra samband och kontext för individ, team och tåg. Vi behöver ge alla en mening att samlas kring.
Pia Sundhage beskriver inspirerande i hennes bok Spela på bästa fot : att leda med glädje hur hon drev förändring i USA:a landslag . När hon tog över laget inför OS 2008 var det givna målet/visionen OS-guld. Men framgången kom genom att hon kommunicerade behovet av förändring och hon stannade inte vid visionen utan definierade och kommunicerade även ett syfte och en strategi.
Målet/visionen (what): Vinna OS-guld
Syfte (why): Förändring. Att bli bättre tillsammans. Att utveckla spelet från fysik fotboll till teknisk. ”Vinna respekt på sättet vi spelar på”.
Strategi (how): Konditionsträning med boll. Pulsmätning. Jo-jo test. Träningsmatcher.
Decentralisera besluten och optimera systemet som en helhet
När vi utvecklar i en skalad kontext behöver vi vision, syfte, strategi och mission för att decentraliserade beslut i teamen inte ska leda till lokal optimering. Att optimera systemet som en helhet är en viktig princip i Lean-Agil utveckling. Vision, syfte, strategi och mission blir en vägledning som håller team och individ fokuserade utan att göra avkall på egna initiativ och lösningar. Vision och syfte ger förståelse för vad vi gör nu och vad som ligger i vår roadmap framöver.
Inre och yttre motivation
Om visionen är målet är syftet vägen. Genom att fokusera på vägen (syftet) levererar vi ofta ett bättre resultat på vår resa mot visionen. Kunskapsarbetare som drivs av inre motivation levererar högre kvalitet än de som drivs av yttre motivation, visar bland annat Daniel Pink. Inre motivation definierar Pink som självbestämmande, syfte och mästerskap och exempel på yttre motivation är ekonomiska bonusar.
Genom att arbeta aktivt med både vision, syfte, strategi och mission drar vi åt samma håll i och mellan team och mellan produkter och tekniker och vi får en delad förståelse för strategi och prioriteringar.
Konceptuellt exempel på vision, syfte, strategi och mission (PI-objective)
Artefakt
Exempel
Kommentar
Vision – kan formuleras som en händelse med ett/flera substantiv
”Jag ska vinna Wimbledon, stå överst på prispallen och få en prischeck på 1 mkr.”
Jag ser det framför mig och målet är belöningen. Yttre motivation.
Med bara vision är det stor risk att man tappar sugen när man når visionen (eller inte når dit). ”Vad ska jag göra nu …? Vad är det för mening med det här egentligen…?” (Inte helt ovanligt tex idrottsmän som ”bara” haft vision som medel).
Syfte – att göra resan mot visionen meningsfull
”Jag ska vinna Wimbledon och på vägen dit ska jag på mina resor på touren stötta fattiga barn och motivera dem att börja läsa böcker och börja idrotta.”
Om man då inte når sin vision finns det ändå en större mening med det man gör. “Vägen är målet.” Inre motivation.
Strategi kan då formuleras olika för visionen och syftet
Strategi för visionen: träna mer på servar och nätspel.
Strategi för syfte: samarbeta med en välgörenhetsorganisation , bygga nätverk bland andra tennisspelare osv.
Hur (strategi) pendlar mellan operativa aktiviteter och själsliga. Vi tränar och utvecklar både kropp och själ.
Mission (PI-objective) definierar de strategiska aktiviteter och vad man vill uppnå i närtid på resan mot visionen.
PI 1: ”Inför Wimbledon som startat om 3 månader kommer jag nu fokusera min träning på nätspel för att förbättra antal dödande slag.”
PI 2: ”Efter Wimbledon kommer jag spendera de kommande tre månader med att fokusera på att höja min kondition. Jag vill öka min syre upptagning med 20 %.”
Missionen varierar beroende på var vi befinner oss i relation till visionen.
Mall för definiera och kommunicera vision, syfte, strategi och mission i SAFe
I SAFe när vi startar ett tåg har vi mycket att vinna på att definera vision, syfte och strategi. Mission (PI-objective) blir utfallet av första PI-planeringen. Mallen nedan kan hjälpa till att täcka in alla aspekter inför en tåguppstart och under tågets första PI-planering.
TRAIN NAME: ___________
Program vision (what we want to achieve with our work)
_____________________________________________
Program purpose (why we want to achieve it)
_____________________________________________
Program strategy (how we going to do to achieve it)
_____________________________________________
Product vision(s) (what we want to achieve with our product(s))
_____________________________________________
Product strategy (how we going to package, sale and deliver the product)
______________________________________________
Program PI objectives (mission in near term towards the program vision)
PI 1: __________________________________________
TEAM NAME:____________
Team vision
_____________________________________________
Team purpose
_____________________________________________
Team strategy
_____________________________________________
Team PI objectives (mission in near term towards the product vision)
PI 1: ________________________________________
Sammanfattning
Det räcker inte bara med en vision eller bara ett syfte. Vi behöver båda som draghjälp för att skapa riktning och mening. Eller som Nietzsche sa “Den som har ett varför att leva för, uthärdar varje hur“.
Commitment: Wants it. Will make it happen. Creates whatever ”laws” (structures) are needed
Enrollment: wants it. Will do whatever can be done within the “spirit of law.”
Genuine compliance: See the benefits of the vision. Does everything excepted and more. “Follows the letter of the law.” ”Good soldier ”
Formal compliance: On the whole, sees the benefits of the vision. Does what´s expected and no more. “Pretty good soldier”.
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.
Noncompliance: Does not see benefits of vision and will not do what’s expected. I won’t do it; you can’t make me”.
Apathy: neither for nor against vision. No interest. No energy. Is ot five o´clock yet?”
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.
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.
