's Picture

11 tips för dig som vill bygga en agil organisation

Postad av Martin Almgren

För ungefär ett år sen började vi på Bonnier News Lifestyle en resa med mål att bygga en ny produktutvecklingsavdelning från grunden med fokus på livsstilstjänster och kommersiella satsningar. Idag så driver vi bland annat sajterna Allt om Resor, Leva & Bo, Hälsoliv, Mitt Kök och Allt om Bilar.

Jag var först in på den nya avdelningen och har under nio månaders tid varit med och tagit fram det agila arbetssätt som idag är vår vardag. Nedan har jag listat några konkreta råd till dig som vill bygga en agil organisation.

Var flexibel - det finns inte någon ”mall”

Jag får ofta frågan vad den perfekta processen är eller exakt hur den perfekta produktägaren ska vara – varpå jag brukar hävda att det inte finns något allmängiltigt svar. Alla organisationer har sina egna utmaningar och kräver ett unikt bemötande och en unik uppsättning verktyg och processer. Inte nog med det - alla organisationer förändras och därför så är de processer och de krav som ställs på en produktägare och ett team evigt föränderliga.

Ha tålamod

Det är inte sällan vi produktägare hamnar vid rodret för en digital transformation, där en agil utopi hägrar vid horisonten. För att färden dit ska vara framgångsrik så är det av yttersta vikt att produktägaren ser till att involvera alla berörda parter i förändringsprocessen. Att kommunicera värdet av det agila tänket är A och O, och ibland är det en process som tar tid. Ingen organisation blir agil i en handvändning.

Involvera

Vi började med att hålla återkommande demos och skicka veckovisa nyhetsbrev där vi berättade om vårt arbete. Ganska snart därefter flyttade vi in i samma öppna kontorslandskap som våra redaktioner och lät dem vara med på våra stand-ups och användningstester. Idag så involverar vi stakeholders och redaktörer i våra dagliga diskussioner kring skisser, kod och lärdomar.

Eftersom yrkesstolthet och prestige tenderar att bygga murar och motverka samarbete så har vi försökt sudda ut linjerna mellan våra roller. Att kunna grunderna i Sketch, Google Analytics och JavaScript är något alla i teamet eftersträvar. Att få en bättre förståelse för alla delar av produktutvecklingsprocessen gynnar helheten, och vi arbetar aktivt med att involvera inte bara teamet utan alla våra kollegor. Det finns få saker som är så kraftfulla för att kommunicera vårt arbetssätt och våra kompetenser som att låta stakeholders och redaktörer vara delaktiga i en pardesign eller parpogrammering.

Coacha

Försök arbeta för en kultur där vägledning snarare än direktiv är normen, där frågor möts med motfrågor snarare än svar. På så sätt så pressar du beslutsfattandet neråt i organisationen och får en rad positiva bieffekter: fler kollegor blir aktivt involverade och känner ägandeskap, organisationens specialister får större inflytande och du minskar avståndet mellan användare och beslutsfattare.

Fokusera på lärdomar

Vi försöker följa en rad populära mantran (sense and respond, insight-driven-development o.s.v.) som på olika sätt uppmanar till en utforskande, reaktiv inställning till produktutveckling. Snarare än att maximera antalet features vi lanserar så är vårt fokus att maximera antalet lärdomar vi kan dra. Ju snabbare vi kan avfärda en idé eller hypotes, ju mer tid har vi frigjort till något som hjälper oss leverera ett konkret värde till användarna och affären.

En följd av detta är att vi faktiskt har gått så långt att vi försöker presentera vad vi har lärt oss snarare än vad vi har producerat på våra demos.

Keep it simple, stupid!

KISS är ett mantra som är vanligt förekommande i programmeringsvärlden och som tål att tas i beaktning inom alla delar av produktutveckling. Mantrat är snarlikt fail-fast-learn-faster-tänket som vi delar med teamen som bygger Expressen.se och som ligger till grunden för den evigt underskattade frågan kan vi lära oss mer genom att göra mindre?

Jag vet inte hur många gånger vi har påbörjat arbetet med en hypotes med intentionen att utveckla ett intrikat multivariat-test, för att i slutändan förkasta idén efter att ha gått ner i entrén med en hastigt ritad pappersskiss och frågat förbipasserande om input.

Identifiera minsta skeppningsbara förbättring

Vi produktionssätter kod flera gånger om dagen. Det är något som genomsyrar allting vi gör. Ändå så händer det ibland - ofta när vi har hittat en riktigt intressant user story - att vi börjar bygga elefanter/bilar/valfri agil antagonist. Nu fokuserar vi hårt på att alltid ifrågasätta scope på de saker vi jobbar med, med målsättningen att hitta delleveranser som ger ett användar- och affärsvärde under processens gång.

Arbeta med målsättningar. Dagligen.

Vi har sedan några månader arbetat med tydligt definierade målsättningar. I vårt fall har vi valt att använda OKR:er, vilket låter oss sätta målsättningar som går att spåra rakt igenom verksamheten - från ett övergripande strategiskt plan ner till var och ens personliga utvecklingsplan.

I den dagliga verksamheten så är det till stor hjälp att kunna gå tillbaka till våra målsättningar för att se om de hypoteser som vi driver verkligen linjerar med våra målsättningar, och om de har potential nog att hjälpa oss nå dessa mål. Det iterativa arbetet driver oss ibland ur kurs, och vi har kastat både en och två riktigt starka hypoteser efter att de visat sig ligga utanför ramarna för våra nuvarande målsättningar.

Prioritera potentiella förbättringsområden, inte lösningar

Vi föredrar ett arbetssätt där utforskning och implementation är en tät sammanvävd process med korta lärdomsiterationer och ett nära samarbete mellan redaktörer, UX-designers och utvecklare. Att sätta en produktägare eller UX-designer på ett omfattande förarbete för att ha underlag för att göra en prioritering av utvecklarnas tid går stick i stäv med denna filosofi.

Idag har vi en backlog med medvetet generiska epics såsom ”bildspel”. Vad vi ämnar göra med t.ex. bildspelen låter vi förbli osagt till vi har kommit igenom de första lärdomsiterationerna och fått en tydligare målbild. Det är inte sällan vi avbryter arbetet med en epic efter att ha insett att den inte har bäring på våra övergripande målsättningar.

Ifrågasätt alltid data

Vi jobbar med några av Sveriges största sajter och har några av Sveriges vassaste analytiker. Kombinationen av dessa två faktorer gör det i teorin väldigt enkelt för oss att driva en datadriven verksamhet, men i praktiken så blir vi kontinuerligt påminda om att vi måste vara försiktiga med data. Det är inte sällan vi blir fartblinda (1 000 konverteringar låter bra - tills man inser att man har 10 000 000 exponeringar) eller får tunnelseende (en tiofaldig förbättring på en metrik som ligger utanför våra målsättningar är inte en förbättring).

Nuförtiden ställer vi oss kontinuerligt frågor såsom tittar vi verkligen på all relevant data och är det positiva utfallet verkligen relevant för våra målsättningar?

Var modig

Sist, men inte minst, måste jag nämna ett av Expressens måtton – att vara modig. Rigorösa sliceningsprocesser, noggranna verifieringar via a/b-test och pedantisk granskning av datakvalitet i all ära – ibland tar vi leaps of faith när vi har konsensus kring en idé. Har vi tillräckligt kvantitativ och kvalitativ förståelse för problemområdet så händer det att vi lanserar fullständiga features direkt till användarna. Att våga lita på teamets kompetens är en grundsten i hur vi arbetar och ibland måste vi ge oss ut på djupt vatten för att nå de resultat vi söker.

PS. Missa inte vår nästa bloggpost, följ oss på Twitter!

Till startsidan