Agile methodology eller agila arbetsmetoder är lite av ett buzzword och har varit så i säkert 10 år. Det började nog inom utveckling, men numer används det för att beskriva arbetsmetoder inom alla möjliga processer. I den här artikeln fokuserar vi mest på den klassiska definitionen och hur den bäst kan nyttjas för affärsutveckling.

Vi börjar med definitionen. Vad är agilt? Enklast brukar vara att jämföra med motsatsen, som kallas Waterfall Methodology eller vattenfallsmetoden. Och kanske allra bäst beskrivs det genom den här klassiska bilden på hur uppdraget består i att bygga en bil.

I den översta, vattenfallsmetoden så bygger man först ett bra hjul. Beställaren kan inte testa eller förstå något av den tänkta slutprodukten. Sen bygger man vidare, men inte förrän den är helt klar så kan beställaren testa produkten. I detta exemplet verkar ju tillverkaren ha förstått kraven hyfsat, för beställaren ser ju relativt nöjd ut. Det kan bli värre än så, vilket jag kommer prata mer om längre ner i denna artikel.

I den understa, agila metoden, där målet är detsamma; Att bygga en bil. Men man bygger i små iterationer, där varje iteration går att testa och ge feedback på. Då kan man göra små justeringar längs vägen och beställaren blir som synes supernöjd!

Denna förenklade bild visar på hur den slutresultatet i en process där beställaren är med och ger feedback i små iterationer, leder fram till en bättre produkt. Huruvida en cabriolet är bättre än en bil med tak, må ju såklart vara upp till var och en. Men i det tänkta exemplet så blev beställaren alltså mer nöjd efter att ha haft möjlighet att vara med och påverka längs vägen. Det är en väldigt viktig ingrediens i ett agilt arbetssätt.

Jag har själv jobbat med webutveckling i 20 år, så mycket av mina referenser och exempel kommer relatera till just denna typ av utveckling. Men jag kommer senare i artikeln också översätta det till affärsutveckling och hur det kan appliceras där.

Den här bilden visar schematiskt den stora skillnaden mellan metoderna.

Vattenfallsmetoden

Mycket tid läggs av beställaren för att sammanställa samtliga krav på produkten. Det här är enda tidpunkten i processen man kan komma med krav. Efter detta steg är det mer eller mindre kört.

Nästa steg är designfasen, där man alltså ritar upp lösningen och dess alla flöden. Beställaren kan för all del ibland vara med i denna fas, men allt är ju schematiskt och fortfarande omöjligt att förstå slutprodukten.

Sen sker utvecklingen. Programmerarna kodar och det blir ett system av det. I vattenfallsmetoden så utvecklas samtliga ingående delar i kravspecifikationen till så nära perfektion det är möjligt. Utvecklingen kan ta månader eller år, beroende på storlek på projekt.

I testningsfasen så har man en (förhoppningsvis) fungerande produkt. Först testar bolagets egna utvecklare så att det fungerar enligt kravspecen. Därefter testar några representanter från beställaren systemet i sin helhet. Och här kommer problemen med vattenfallsmetoden; Några få personer ska testa av ett helt system. Upplever de att det fungerar, så kommer det att skickas ut till kanske 10.000-tals användare. Och risken är nu väldigt stor att enskilda delar av systemet inte alls fungerar som man hade tänkt. Placering av knappar är kanske lätt att lösa, men om hela flödet visar sig vara feltänkt? Det flöde som hela systemet är byggt på. Då måste i värsta fall stora delar av systemet byggas om, och månader av utvecklingstid och kostnad kan vara bortkastade.

Agil metod

I den agila arbetsmetoden så jobbar man istället i korta cykler. Man ”itererar” dvs gör om samma cykel om och om igen, där man för varje varv kommer ett litet steg framåt.

Likt vattenfallsmetoden börjar varje iteration, eller ”sprint” som det ofta kallas, med en kravställning. Den är dock inte alls lika omfattande, utan beskriver egentligen i första steget, det absolut mest grundläggande som produkten ska klara av. Absolut inga ”nice to have-features” i det här läget.

Designfasen är kort och utvecklingen börjar direkt. Sprinten testas av och produktionssätts med de funktioner som är klara. Istället för att några få testare kommer med feedback på en redan färdig produkt med massvis av funktioner, så kommer nu istället 10.000 riktiga användare med feedback på en smal produkt med få funktioner. Med den feedback man får, så gör man en ny kravställning för kommande sprint och designar och utvecklar nästa version. Efter testning, så släpps den uppdaterade versionen med fler funktioner än tidigare. Återigen, får man in feedback från 10.000 riktiga användare på relativt få funktioner och kan ta det vidare därifrån.

När man tar de här små, små stegen framåt så säkerställer man längs hela processen att man är på rätt väg, istället för att hålla tummarna att det blev rätt när allt är klart, och försent att rätta till.

Agilt inom affärsutveckling

Att jag är en varm förespråkare för agila metoder hoppas jag att ingen har missat vid det här laget. Men nu har jag pratat om agila metoder inom system- och webutveckling. Så hur översätter vi och applicerar detta till affärsutveckling?

Jo, det är egentligen på exakt samma sätt. Låt oss säga att du vill införa ett lojalitetsprogram. Vattenfallsmetoden hade varit att du med hjälp av dina skarpaste kollegor och kanske en dyr konsult, knåpar ihop varenda detalj av lojalitetsprogrammet. Ni bekostar utvecklingen av ett dyrt system för att hantera det. Ni testar av att det funkar, och ni slår på stortrumman ut på marknaden om ert nya system. Men så flyger det inte… Era kunder var inte ett dugg intresserade av ert lojalitetsprogram och pengarna kastades rakt ner i sjön.

Ett ganska konkret exempel på detta var ju ICA’s nya lojalitetsprogram ”Stammis”, där man först satte så hög gräns för bonus att ensamstående pensionärer ofta inte hade en chans att få ut sin bonus. Just detta gick det ju ganska lätt att backa på för ICA, men det är ett exempel på hur ett försök till affärsutveckling med vattenfallsmetoden höll på att slå väldigt fel.

Börja med att fråga målgruppen

Om man ska utveckla ett nytt lojalitetsprogram, så kan man ju till att börja med skapa idén och skicka ut en undersökning bland kunderna, vad de tycker. Redan där hade man, som i ICA’s fall, fått feedbacken om att pensionärerna rasar mot bonusgränserna. Detta kan i vissa fall kallas för ”Smoke test”, d.v.s. man kollar av intresset innan man ens har funktionen på plats.

Om nu kundundersökningen eller marknadsundersökningen slår väl ut, så kan man utveckla idén och sätta den i verket, men utan att ha full automatisering för det administrativt. Det beror givetvis på vad det är. Ett företag i storleksordningen ICA skulle ju brisera av den administrativa bomb manuellt hantering av ett bonussystem skulle innebära. Men för många mindre företag och i andra sammanhang, så kan man låta kunderna uppleva t.ex. bonusprogrammet som väldigt väl fungerande, men hemma på kontoret sitter man och räknar på allt för hand med miniräknaren… Detta kallas ofta Wizard of Oz test och syftet är såklart att testa kundupplevelsen och användningen av systemet, innan man lägger pengar på att automatisera det.

Applicerar man alltid agila metoder i affärsutveckling, så kommer man spendera betydligt mindre pengar på fel saker. Man kommer våga testa fler idéer och med mindre resurser än någonsin successivt förfina de till perfektion.

Ställ rätt frågor, till rätt målgrupp

När man gör ett smoke test, d.v.s. någon typ av kundundersökning, så är det viktigt att man gör det på rätt sätt. Ställer man fel frågor, så får man nämligen fel svar. Jag har själv gjort exakt den tabben, när jag vi skulle göra ett smoke test för en tilläggsförsäkring. Min kund ville absolut implementera denna försäkring direkt, men jag insisterade på att vi skulle fråga kunderna om de var intresserade, innan de la pengar på den utveckling som det innebar med en fullskalig lösning.

Sagt och gjort, så lät man mig skicka ut undersökningen, och den primära frågan jag ställde var typ ”Skulle du i samband med köp av företagets produkter, vara intresserad av att köpa en allriskförsäkring för X kr som täcker det mesta?” och så lite finstilt om exakt vad den täcker. Så vad var fel med denna fråga? Egentligen ingenting, men problemet var att vi frågade personer som redan hade köpt produkten, som redan var lojala användare och som dessutom inte behövde lätta på lädret för att svara Ja på frågan. 70% av de tillfrågade svarade Ja, för priset för försäkringen var dessutom ganska förmånligt.

Det blev inte alls som vi hade hoppats

Detta var absolut tillräckligt för att gå vidare med ett Wizard of Oz test, där vi byggde funktionaliteten på hemsidan, men min uppdragsgivare hanterade alla försäkringar manuellt i typ en Excelfil ungefär på baksidan. Och här är jag väldigt glad att vi inte gick all-in på den fullskaliga lösningen, för det visade sig sen att mindre än 5% köpte denna tilläggsförsäkring!

Hur kunde det vara så stor skillnad mellan undersökningen och verkligheten? Svaret ligger i felet jag gjorde med målgruppen. Vi frågade lojala kunder som redan gillade och litade på varumärket och var det troget. Men vi försökte sen sälja försäkringen till en helt annan målgrupp, d.v.s. förstagångsköpare som inte hade något upparbetat förtroende för varumärket. Det blev en relativt dyr läxa, men hade vi kört vattenfallsmetoden, så hade vi även utvecklat hela systemtet för hantering av försäkringarna också. Och den smällen hade blivit ännu större!

Så för att sammanfatta den här artikeln, så är en agil arbetsmetod inom affärsutveckling det absolut mest effektiva sättet att hitta fungerande idéer som leder till tillväxt. Growth Hacking är det ramverk för agila arbetsmetoder inom affärsutveckling, som jag själv fastnat för och använder mig av. Det funkar lika bra för små företag som stora och lika bra för startups som för gamla etablerade företag. Är målet hållbar tillväxt med små resurser, så är Growth Hacking en bra agil arbetsmetod.

Har du några dråpliga exempel på när du körde ett vattenfallsprojekt eller kanske lyckade agila projekt? Eller kanske tvärtom? Dela gärna i kommentarsfältet.