Agile Marketing: så börjar du tillämpa metoden

Eftersom jag förra veckan publicerade en guide om Trello, tänkte jag att det kunde vara användbart att förklara hur jag tillämpar Agile-metoden i mina projekt.

Du kanske inte känner till agila metoder särskilt väl.

Eller så tror du kanske att de bara är till för mjukvaruutveckling och digitala produkter.

Inget kunde vara längre från sanningen: de kan faktiskt tillämpas på vilken process, vilket projekt eller vilken avdelning som helst.

Och den här artikeln har två mycket tydligt avgränsade delar:

• I den första berättar jag lite om vad agila metoder är och hur allt började. Teorin bakom dem och deras begrepp.
• I den andra delen ska jag förklara hur jag tillämpar de delar av metoden som jag gillar i marknadsföringsteam, så att du, om du är intresserad, kan börja använda dem i ditt eget team redan nu. Den praktiska och operativa delen.

Om du redan känner till den första delen kan du hoppa direkt hit.

Vi börjar från början.

Del 1: Vad Agile-metoden innebär

Det är ett förhållningssätt till beslutsfattande inom projektledning som fokuserar på att utveckla funktionalitet inkrementellt och iterativt, vilket ger användaren / kunden mer värde i varje cykel.

Den uppstod först inom mjukvaruutveckling och började snabbt därefter tillämpas inom andra områden, som projektledning av alla slag (inte bara mjukvara), produktutveckling, UX och marknadsföring.

Den står i motsats till vattenfallsmodeller -där en del av projektet måste vara färdig innan nästa kan påbörjas- eftersom de anses vara alltför byråkratiska, och lägger stor vikt vid kommunikation mellan parterna, framför dokumentation.

Låter bra, eller hur? Men du kanske undrar hur allt detta uppstod.

Det ska du få se nu.

Agile-metodens historia

I mitten av 90-talet uppstod en rörelse mot strukturerad projektledning, som kulminerade i en konferens 2001 i Snowbird, Utah.

Där myntades för första gången termen “Agile Methodology”, “Agile Alliance” bildades och “Agile Manifesto”, som samlar metodens principer, publicerades.

Agile Manifesto

Du kan läsa originaldokumentet här:

http://agilemanifesto.org/

Manifestets fyra värden

Som du kan se via länken ovan står det i dokumentet:

“Vi finner bättre sätt att utveckla programvara genom att utveckla själva och hjälpa andra att utveckla. Genom detta arbete har vi kommit att värdesätta:

• Individer och interaktioner framför processer och verktyg
• Fungerande programvara framför omfattande dokumentation
• Kundsamarbete framför kontraktsförhandling
• Anpassning till förändring framför att följa en plan

Det vill säga, även om det finns värde i det som står till höger, värdesätter vi det som står till vänster mer.”

Och dessa fyra värden delas upp i följande tolv principer.

Agile-manifestets tolv principer

Du hittar dem här:

http://agilemanifesto.org/principles.html

Men jag kopierar dem åt dig:

1. “Kundnöjdhet. Det är grunden för allt. Den uppnås genom att leverera värdefulla produkter som fyller ett behov.
2. Välkomna nya krav. Att ändra sig längs vägen är inte att ta ett steg bakåt. Alla förslag eller lösningar är välkomna om de förbättrar produkten.
3. Veckovisa leveranser. Att dela upp arbetet i produktiva faser är grunden för metoden. Om möjligt ska en genomföras varje vecka.
4. Framsteg går att mäta. Processernas utveckling är inte subjektiv. Den kan mätas med konkreta indikatorer.
5. Hållbar utveckling. Sättet projekten genomförs på måste i sig garantera deras kontinuitet. Det handlar inte om att göra saker bara för sakens skull.
6. Nära samarbete. Projektledarna bör arbeta där uppgifterna faktiskt utförs, inte från sina kontor.
7. Kommunikation ansikte mot ansikte. Den ansvariga chefen måste kommunicera sina budskap effektivt, helst personligen. Regelbundna möten med både kunden och medarbetarna rekommenderas.
8. Motivation och förtroende. Processerna lyckas bara om de som genomför dem är motiverade och samarbetar i ett klimat av förtroende och solidaritet.
9. Teknisk excellens och bra design. Formen får aldrig gå förlorad, och inte heller kvaliteten på arbetet. Allt hör ihop.
10. Enkelhet. Uppgifter ska vara så enkla som möjligt. Om någon inte kan utföras på det sättet måste den delas upp i iterationer tills komplexiteten har minskat.
11. Teamens självstyre. Även om det bör finnas någon som följer upp arbetsgrupperna måste de kunna organisera sig själva. För mycket hierarki skapar beroenden mellan medarbetarna.
12. Anpassning till förändrade omständigheter. Projekt slutar sällan på samma sätt som de började. Det är avgörande att de som genomför dem kan anpassa sig till de olika omständigheter som kan uppstå.”

Jag vet inte vad du tycker, men om du någon gång har varit involverad i utvecklingen av digitala produkter, är det svårt att inte hålla med om precis varenda punkt.

Mycket svårt.

Så mycket att metoden i dag, tack vare sin nytta inom ursprungsområdet, som sagt har överförts till ledning av alla typer av projekt och till och med hela sektorer.

Man talar om “Agile Product Design”, “Agile Marketing” och “Agile Management”, där fokus alltid försöker läggas på:

• Kommunikation ansikte mot ansikte.
• Transparens.
• Kundnöjdhet.
• Enkelhet.
• Inkrementell utveckling och kontinuerlig förbättring.

Börjar du se poängen med metoden?

Nu går vi vidare till de viktigaste delarna.

Grundläggande delar och begrepp i Agile-metoden

Bra. Allt som förklarats hittills låter väldigt fint, men för att komma igång måste vi omsätta teorin i praktiken och förklara de olika delar som gör planering och genomförande möjligt.

Frameworket

Även om alla agila metoder bygger på samma principer och värden tillämpar de dem på olika sätt.

Och dessa olika sätt att göra saker är de olika frameworks eller referensramarna.

Det finns flera, var och en med sina regler, fördelar, rekommendationer och nackdelar. De två vanligaste och mest kända är Kanban och Scrum.

Kanban

Det uppstod i Japan efter andra världskriget, som hade lämnat landet i en ekonomisk och teknisk katastrof.

På 50-talet utvecklade Toyota ett produktionssystem “just in time” (JIT) där varje del tillverkades precis i rätt ögonblick, varken före eller efter, och som beskrevs som “mycket effektivt och ändamålsenligt”.

För att genomföra det använde man kort som identifierade materialbehovet i produktionskedjan.

Metoden tar alltså idén med kort och likställer varje kort med en uppgift.

Man skapar en tavla med en kolumn för varje status som en uppgift måste gå igenom, till exempel:

• Definierad.
• Pågående.
• Avslutad.
• Granskad.

Det här är ett exempel på en enkel tavla, men den kan göras så komplex som projektet kräver. Ett mer komplext exempel skulle kunna vara:

• Definition.
• Analys.
• Utveckling
• Tester.
• Produktionssättning.
• Dokumentation.

Tavlan ser olika ut för varje företag eller team beroende på behoven och kan användas både för nya utvecklingsprojekt (“lansera bloggen”, “öppna en TikTok-kanal”) och för underhålls uppgifter (“granska webbplatsens banners”) eller återkommande uppgifter (“granska affiliateprovisioner”, “veckovis ecommerce-rapportering”).

Tavlan kan vara fysisk (vilket rekommenderas för att den ska vara synlig och transparent för hela teamet) eller digital, och det är där Trello kommer in.

Scrum

Den liknar den föregående, eftersom principerna och filosofin de bygger på, som sagt, är desamma.

Namnet kan översättas som “klunga” och kommer från rugby, när hela laget går ihop.

De skiljer sig i små detaljer, kanske eftersom Scrum anses vara mer restriktivt och enligt min erfarenhet är mer inriktat på utveckling av digitala produkter:

• Rekommenderar tvärfunktionella team. I Kanban är specialiserade team tillåtna.
• Specifika roller: Scrum Master, Product Owner och utvecklingsteam är obligatoriska i Scrum; i Kanban kan du ha dem eller inte
• Iterationer med bestämd längd (mellan 1 och 4 veckor): sprintar (det läggs stor vikt vid detta).
• Förändringar: det som tas in i en sprint är låst och önskade ändringar skjuts upp till nästa sprint för att man ska kunna mäta burn-processen eller Burndown (det är inte riktigt så enkelt). I Kanban är ändringar lättare att genomföra, eftersom en funktion med lägre prioritet kan bytas ut mot den nya önskade.
• Ceremonier med fast tidslängd.
• Ny tavla i varje sprint jämfört med Kanbans bestående tavla.

Av alla dessa skäl föredrar jag personligen Kanban för Agile Marketing, och det är den jag ska förklara i den här artikeln.

Faktum är att det inte är vanligast, men jag har både sett och arbetat med hybridmodeller:

• Scrum för nyutveckling och Kanban för återkommande uppgifter inom samma team. Det var modellen vi hade på Lowi.
• Metoden “Scrumban”, som lånar delar från båda.

User stories

Kanske metodens kärna.

Det är ett enkelt sätt att beskriva en kortfattad uppgift som skapar värde för användaren eller kunden.

De skrivs vanligtvis på kort (för hand på post-it-lappar eller digitalt) och innehåller:

1. Titel: kort, för att kunna hänvisa till den.
2. Beskrivning: Som [användarroll] vill jag [funktionalitet] så att [Storyns mål]. Exempel: "Som blogganvändare vill jag se relaterade artiklar i slutet av artikeln så att jag kan fortsätta läsa om ämnen som intresserar mig”.

Dessutom måste de ha följande egenskaper:

1. Oberoende: av varandra. De ska kunna hanteras separat även om de hänger ihop. I en annonskampanj skiljs till exempel designuppgiften från copywritinguppgiften, även om de naturligtvis måste vara relaterade.
2. Förhandlingsbara: omfattning och detaljer överenskommes mellan båda parter och omförhandlas vid behov, till exempel genom att dela upp uppgiften i två delar.
3. Värdeskapande: de måste skapa verkligt, konkret värde för kunden.
4. Uppskattningsbara: det vill säga att insatsen som krävs för genomförandet kan analyseras. I tid eller utvecklingspoäng.
5. Små: om de är för stora och inte kan uppskattas måste de delas upp.
6. Verifierbara: testbara, med binära acceptanskriterier (godkänd eller inte godkänd).

När uppgiften är formulerad placeras den i tavlans första kolumn och flyttas mellan kolumnerna när statusen ändras.

Backloggen

Det är samlingen av projektuppgifter som redan är formulerade och fortfarande väntar på att hanteras.

Teamet

Beroende på metod kan det vara nödvändigt eller inte att ha vissa roller i teamet.

I Scrum är det till exempel vanligt att ha:

• Product Owner: affärsansvarig för produkten.
• Scrum Master: problemlösare och facilitator för utvecklingen. Personen kan vara teamledare eller inte.
• Utvecklingsteam / specialister (UX, designers, SEO…): alltså de personer som kommer att utföra merparten av uppgifterna.
• Tech lead: tekniskt ansvarig för teamet. Det kan vara samma person som har rollen som Scrum Master.
• QA: testning.

I Kanban behövs inte dessa roller, även om det är sant att ju tydligare varje teammedlems roll är definierad, desto lättare blir det att bedöma uppgiften och sedan utföra den.

Sprintar

Längden på en iteration, cykel eller leverans där en eller flera prioriterade nya funktioner eller förbättringar (features) i en digital produkt släpps, eller där relevanta uppgifter i cykeln genomförs (“skapa Instagram-innehåll”).

Normalt varar de mellan en och fyra veckor. Inom digital produktutveckling brukar de vara två eller tre, medan de inom marknadsföring mycket väl kan vara en vecka.

Sprintens mål

Inom produktutveckling har man ett Sprintmål, som samlar merparten av de funktioner man avser att genomföra.

I andra typer av projekt är ett sådant mål inte alltid nödvändigt.

Ceremonier

Så kallas de teammöten som hör till metoden.

Det här är de vanligaste, och var och en har sin längd, frekvens och sina mål:

De används för att analysera och iterativt förbättra utveckling och processer

• Daily: varje dag berättar teammedlemmarna mycket kort vad de ska göra den dagen och om något blockerar en tidigare uppgift, så att man kan diskutera stegen för att undanröja blockeringen. Det bör ta ungefär fem minuter.
• Sprint plan: när den pågående sprinten avslutas samlas teamet för att diskutera hur nästa sprint ska genomföras och uppskatta uppgifterna.
• Refinement: det är steget före den föregående ceremonin. Under refinement ska varje story vara tillräckligt tydlig och begriplig för teamet och omfattningen vara definierad så att den kan uppskattas i Sprint plan.
• Retrospektiv: efter att sprinten avslutats analyserar man hur det gick, vilka problem som uppstod och vilka förbättringspunkter som kan tas med till framtida sprintar.

Om vi talar om marknadsföring, är alla dessa ceremonier verkligen nödvändiga?

Lite längre fram ger jag dig mitt svar, för här slutar teorin.

Nu ska jag förklara hur jag har tillämpat det från grunden i olika team och projekt.

Du kommer dessutom att se att tillvägagångssättet är mycket enkelt och att det inte krävs radikala förändringar eller nya verktyg för att börja tillämpa agila principer.

Del 2: Processen för att införa Agile-metoden i Marketing

Om du aldrig har arbetat med agila metoder tidigare vill jag först att du läser manifestet och dess principer flera gånger, för egentligen räcker det för att förstå och börja tillämpa vissa begrepp.

Det handlar om ett tankeskifte där jag skulle säga att det viktigaste är att prata och komma överens mellan parterna (chefer, det egna teamet, externa team…) med vetskapen om att alla söker det gemensamma bästa.

För det andra, vara flexibla. Förstå att förändringar kommer och att de måste accepteras. Även om de stör oss. Det betyder inte att alltid “ge efter”, utan att gå tillbaka till föregående punkt: prata och komma överens.

För det tredje och sist, mäta. För mätning är det enda sättet vi har att veta hur optimal vår prestation är, hur teamet presterar och om alla åtgärder vi gör verkligen är värda besväret.

Bra, när du väl har fått in det i huvudet kan vi börja prata om systemet.

Systemet för Agile Marketing

Tanken bakom det är att ditt team kan genomföra ett begränsat antal uppgifter under en viss tid.

Den tidsperioden kallar vi sprint, och till att börja med är det enklast att låta den vara en vecka.

Du måste alltså organisera ett system så att rätt antal uppgifter utförs varje vecka (sprint).

Hur många uppgifter är det? I början vet du inte, eftersom du inte har någon historik. Därför är det bästa du kan hoppas på i de första sprintarna att uppskatta med en viss felmarginal, som minskar ju mer erfarenhet du och ditt team får.

Dessutom har ni ännu ingen erfarenhet av att formulera uppgifter, vilket lägger ytterligare ett lager av svårighet ovanpå uppskattningen.

Men lugn, den här osäkerheten varar inte länge: när du har genomfört flera sprintar, mätt och lärt dig att formulera uppgifterna korrekt har du data för att uppskatta varje uppgift mycket bättre.

Med den utvecklingen i åtanke är det första steget att hitta ett verktyg där du kan skapa backloggen och skriva in alla uppgifter i sprinten.

Verktygen för Agile Marketing

Det finns flera, beroende på om du föredrar online eller offline.

Fördelarna med varje typ?

Onlineverktyg är mer omedelbara och kan kosta väldigt lite, medan offlinelösningar i princip består av en tavla och några post-it-lappar, och gör det mycket tydligt för hela teamet vad man arbetar med samtidigt som arbetet synliggörs för verksamheten.

Min rekommendation?

Förutom i de fall där det är absolut nödvändigt att göra allt pågående arbete helt synligt, börja med ett onlineverktyg.

Jag rekommenderar två, beroende på hur övertygad du är om systemet: Excel om du vill testa och Trello om du redan tror att det här är något för dig.

Agile Marketing med Excel

Jag säger Excel eftersom det är mest utbrett, men vilket kalkylblad som helst (Google Sheets, LibreOffice…) fungerar.

Tanken här är inte så mycket att prata om Kanban och tavlor, utan att börja tillämpa agila principer direkt.

För det skapar du ett dokument där du lägger till alla uppgifter som ska göras, en under den andra. Det blir din Backlog.

Dessutom skapar du ett antal kolumner som hjälper dig att definiera varje uppgift, planera och mäta teamets prestation samt insatsen som krävs för varje uppgiftstyp:

I det här fallet har vi följande kolumner:

• Prioritet: även om vi skulle kunna lägga de högst prioriterade sprintuppgifterna överst skulle det göra filtrering svårare, så vi lägger till en kolumn.
• Varumärke: om du arbetar med flera kunder eller varumärken kan du segmentera efter vart och ett av dem.
• Uppgifter: här lägger vi bara till titeln eftersom det i allmänhet är uppgifter vi redan känner till och inte behöver mer omfattande beskrivningar.
• Kommentar: om vi trots allt behöver fler detaljer lägger vi till dem här.
• Uppgiftstyp: det gör att vi kan se hur mycket tid vi lägger på varje typ av arbete och analysera:
• Om den investerade tiden är värd det.
• Om genomförandetiden minskar ju mer erfarenhet personen får av att utföra samma typ av uppgift.
• Person: helt enkelt vem som ska utföra den.
• Uppgiftsstatus: Inte påbörjad, Påbörjad eller Avslutad.
• Startdatum: sprintens startdatum, vilket gör att vi kan filtrera vad som görs i varje sprint.
• Start: datum då uppgiftens status ändras från Inte påbörjad till Påbörjad.
• Starttid: tiden då en uppgift påbörjas.
• Sluttid: tiden då en uppgift avslutas.
• Insats i timmar: skillnaden mellan Starttid och Sluttid.
• Vecka: för att veta årets vecka och kunna jämföra framöver eller skapa diagram.

I varje sprint läggs de nya uppgifterna till med sitt Startdatum, och genom att filtrera på detta datum har vi den nya sprinten på plats.

Om det förstås finns kvarstående uppgifter från andra sprintar lägger vi till datumet för föregående sprint i filtret så att uppgifterna från båda visas.

Den här metoden fungerar så länge vi inte har uppgifter som ligger kvar längre än 2 sprintar; annars skulle de samlas på hög och vi skulle behöva ett annat system, till exempel att skapa en ny uppgift i den nya sprinten som ersätter den som inte blev klar i föregående sprint.

Bra, en mall som denna räcker mer än väl för att börja planera och tillämpa agilityns tre pelare: komma överens, vara flexibel och mäta.

När du sedan har hållit på ett tag -och ser att det fungerar- kanske du vill ta ett steg till. Då är det dags att byta verktyg…

Agile Marketing med Trello

Först och främst har du här en guide för att komma igång med verktyget.

När du har läst den och skapat ditt konto ska du veta att jag också har publicerat den här artikeln om hur man använder Trello för att tillämpa Kanban-metoden i marknadsföring, där jag går in mer på djupet, men här är ändå några snabba punkter:

1. Skapa bara en tavla till att börja med. Det är mycket enklare att hantera när du är ny.
2. På den tavlan skapar du 3 eller 4 kolumner, inte fler. De kan vara:
• Backlog: backloggen med alla uppgifter, både de i den pågående sprinten och alla andra som läggs till för framtida sprintar.
• To do: flytta uppgifterna som ska utföras i sprinten från Backlog till den här kolumnen. Uppgifterna med högst prioritet placeras överst.
• Doing: när sprinten har startat flyttar den ansvariga personen en uppgift från To do till den här kolumnen när arbetet på den börjar.
• Done: när en uppgift är avslutad flyttas den från Doing till den här kolumnen.
3. Om uppgiften måste valideras av någon annan än den som utförde den lägger vi till en femte kolumn, “Validated”.
4. När sprinten är stängd arkiveras alla färdiga uppgifter och vi börjar lägga den nya sprintens uppgifter i To do.

Enkelt, eller hur?

Nu återstår bara analyslagret: se vad som hände om något inte blev klart, om problemet låg i analysen av teamets kapacitet, i formuleringen av uppgiften, i uppskattningen av uppgiften…

Och ett sätt att ta itu med frågan är genom ceremonierna.

Ceremonier i Agile Marketing

I teoridelen pratade vi om fyra ceremonier:

• Daily.
• Sprint plan.
• Refinement.
• Retrospektiv.

Var och en genomförs med mycket tydliga mål, men jag tycker att de är starkt inriktade på digital produktutveckling och att alla inte är nödvändiga inom marknadsföring.

I praktiken beror det också på teamets storlek, för ju större teamet är, desto viktigare blir det att skapa ordning och lyssna.

Med det sagt, här är min syn på var och en:

Daily är oumbärlig. Det är den eftersom den hjälper teamet att fungera bra och löser blockeringar, samtidigt som alla vet var vi befinner oss.

En sprint plan är användbar, men inte nödvändig om teamet är litet (upp till 3-4 personer).

Och refinement, går ännu lättare att vara utan, eftersom ett team som har arbetat tillsammans länge inte behöver en separat session för att reda ut saker som kan lösas med ett Slack-meddelande eller ett 30-sekunderssamtal mellan de två parterna.

En retrospektiv är särskilt användbar om ett större problem har uppstått under sprinten. Att lyssna på varje medlems åsikt hjälper oss att fatta bra beslut om förbättringar.

Med det sagt tycker jag inte att de måste hållas efter varje sprint (särskilt inte om sprintarna är veckovisa), men däremot regelbundet och, som sagt, alltid när något problem av viss betydelse har inträffat.

Sammanfattningsvis tycker jag att ceremonier måste vara ett medel för att nå ett mål, inte ett mål i sig, vilket jag har stött på ibland.

Teamstorlek

Även om jag har använt systemet som beskrivits hittills i team med 10 personer tycker jag att några justeringar skulle behövas vid den storleken.

Däremot tycker jag att det är perfekt för mindre team på mellan 3 och 6 personer.

Om ditt team är mindre än så tror jag inte ens att Trello behövs. Excel och Slack (eller Telegram) kan mycket väl räcka.

Fördelar med Agile Marketing

Den största fördelen för mig är att kunna ha en överblick över alla uppgifter som ska göras i varje sprint, så att vi tydligt ser vilka vi hinner med och vilka som måste skjutas upp. Det är mycket enkelt att prioritera och tilldela uppgifter till personer.

Ur organisationssynpunkt är detta fantastiskt, framför allt eftersom teamet vet vad det ska göra och kan fokusera på det.

Nästa fördel är att vi, när systemet väl är implementerat, kan mäta och analysera varje typ av uppgift. Om du jämför insatsen med affärsnyttan kanske du blir förvånad och slutar med uppgifter som du har gjort i flera år (“Facebook-inlägg”).

Eller upptäcker vilken person i teamet som passar bäst för varje uppgift.

En annan fördel är att, särskilt om du använder Trello snarare än Excel, allt blir dokumenterat, så att vi har ett riktigt repository nära till hands.

Slutligen kan, om det behövs, som jag nämnde tidigare, en välfylld tavla eller backlog synliggöra värdet av det utförda arbetet för teamet.

Till sist är kostnaden för allt detta låg:

• I pengar, eftersom verktygen är gratis eller billiga.
• I tid, eftersom arbetsbelastningen visserligen ökar något, men jag hoppas att jag har gjort klart att det mer än väl lönar sig.

Slutsatser

Trots att artikeln är ganska lång har jag knappt skrapat på ytan av Agile-metoden.

Det är en introduktion för att du ska kunna fundera på om detta kan passa dig eller om ditt nuvarande system passar bättre.

Oavsett system vill jag ändå att du tar med dig de tre saker som jag ser som metodens viktigaste värden:

• Prata och komma överens mellan parterna.
• Flexibilitet.
• Mätning.

Under förutsättning att vi är överens om att allt detta i grunden handlar om att få arbetet / projektet framåt.

Med det sagt hoppas jag att jag har lyckats förklara värdet av att använda Agile-metoden i Marketingteam, eftersom den verkligen skapar mycket värde när den används rätt. Det säger jag av egen erfarenhet.

Så gör mig en tjänst och ge den en chans.

Även om jag verkligen inte är någon Scrum Master: om du tror att du behöver hjälp med att organisera ditt team i digitala projekt är det bara att skriva till mig.