Vi har ju många olika sajter (och viljor) på tv4, och prioritering av vad som är viktigast är därför sällan helt självklart. Här berskriver jag hur vi gjort för att få bättre ordning på webbutvecklingsarbetet och prioriteringen av vårt jobb de senaste åren.

Hur det var
För några år sedan när TV4 just lanserat nya sajter i Polopoly utgick mycket av utvecklingsarbetet från ett antal (ofta långa) listor. De här listorna var från början “restlistor” med utvecklingspunkter som inte hunnits med till sajternas lansering.  Saker tog sällan bort från listorna vilket gjorde att de snabbt blev långa, inaktuella, dåligt prioriterade och ospecificerade. Beställarna var många och utvecklarna få, så för att få igenom just sina punkter fick beställarna tjata ihärdigt eller skrika högt. Prioriteringen mellan sajterna blev såklart inte optimal.

Ny metod – scrum eller nått annat?
Vi behövde jobba mer strukturerat, och den metod som var på modet för dagen var Scrum. Problemet var bara att vi inte var helpeppade på att ta in en scrum-guru för att införa fem-sex nya möten  i veckan som skulle äta av vår redan knappa tid. Vår metod-missionär Brian hade lösningen -  vi tog det ett steg i taget. Inga kurser och avstamp och “nu-jädrar-kör-vi” utan mer en långsamt framväxande strukturering över ett år eller två. När en del var på plats och fungerade gick vi vidare till nästa. Inga lösningar infördes innan det fanns ett problem att lösa. Det gjorde att metoden aldrig åt upp all vår tid och inkörningssträckan blev visserligen lång men å andra sidan oproblematisk. Innan något nytt infördes visste vi tydligt vad vi ville få ut av det.

Vår väg till bättre ordning (kanske något rakare än vad den egentligen var)
Steg ett: Listorna i papperskorgen. Papperstickets blev nya hårdvalutan
Första steget mot ordning var att teknikavdelningen slutade att låtsas ta ansvar och bry sig om sajternas långa önskelistor. Vi satte upp en mötesstruktur där vi samlade in önskemål på utveckling kontinuerligt, och allt som togs med från mötet var ett par papperstickets med det som var hetast just nu.  “Långa listorna” åkte i papperskorgen. De flesta saknade dem inte ens.

Steg två: Prioriteringsmöten och väl avgränsade sprintar
För att skapa lugn åt utvecklarna gick vi vidare med att skapa avgränsade sprintar och ett priomöte innan varje sprint. Utmaningen för oss var att få de beställare som var vana att skjuta från höften fem dagar i veckan att respektera att de behövde ha framförhållning. Det här kom vi inte i mål med förrän långt senare, i början sprack planeringen mer eller mindre varje vecka på grund av akuta fixar, men strukturen var ändå en förutsättning för att få koll på prioarbetet. Med en fast tidsram tvingades man inse att tiden inte räckte till allt, och när man nu pressade in något märkte man plötsligt att något annat föll ur.

Steg tre: Få in beställarna i prioriteringen
För att få ordning på prioriteringen släppte vi in beställarna på våra priomöten. En person från beställarsidan som hade övergripande ansvar för alla sajter fick sitta med på priomötet och sätta prioriteringen tillsammans med oss. Det var väldigt effektfullt när vi fyllde bordet i mötesrummet med papperstickets. Allt från pixelpet till stora strukturförändringar  låg på bordet och allt skulle in i en enda orm. Efter många “Men… det här är ju också viktigt” (ofta följt av en lång suck) kom vi fram till ett tiotal tickets som prioriterats, och ett sextiotal som prioriterats bort.  Nu hade beställarna varit med och valt de tickets som skulle göras, och vi slapp spilla tid på att argumentera och planera om vår tid när arbetet väl pågick.

Steg fyra: Kommunicera vad beställarna kunde förvänta sig varje vecka
När vi såg att beställarna började förstå hur vår process fungerar började vi skicka tydliga mejl med vad som ingick i en release och vad som inte fick plats. Så ärliga som möjligt och gärna med en rad om vad vi tvingats välja bort. Ofta svarade de som inte fick med just sin viktiga punkt med vändande mejl, och då kunde vi på en gång tala om hur vi resonerat och varför den punkten inte hanns med. Om prioriteringen ifrågasattes kunde vi förstås hänvisa till den som hade det övergripande ansvaret. Det skedde i själva verket rätt sällan, för när valen synliggjordes förstod beställarna bättre varför deras saker inte hanns med.

Steg fem: Tidsuppskattning av tickets
Man kan tycka att vi började tidsuppskatta tickets sent, men det var först nu vi hade fått tillräckligt bra koll på processen för att kunna börja planera sprintarna mer exakt. Så länge saker pressades in från höger och vänster skulle en detaljerad uppskattning varit omöjlig. Vi var nu i ett läge där vi började kunna hålla ute störande snabbfixar och brandsläckningar och kunde därför tidsuppskatta arbetet på en rimlig nivå.

Steg sex: Sprintstatistik
För att få koll på hur många poäng vi skulle ta med i varje sprint behövde vi få koll på hur mycket vi klarade av. En enkel siffra på avklarade tickets per sprint hade räckt långt, men för att synliggöra hur arbetet gått ännu mer började vi göra Burn down charts. Jag vet fortfarande inte om vi har mer nytta av dem än vad vi hade haft av en enkel totalsumma, men de ser å andra sidan fina ut på väggen.

Steg sju: Retrospektiv
Ju mer metod och ju fler möten man kör, desto större anledning att finslipa metoden. Därför började vi köra retrospektiv efter varje sprint för att utvärdera sprinten och hur vi jobbat. Retrospektiven vi kör är oftast enkla, men det viktiga är att få diskutera några minuter varje vecka så att arbetet inte stelnar i sin form. Retrospektiven mynnar alltid ut i en åtgärdslista.

Steg åtta: Time boxing
När vi hållit ett par tidsuppskattningsmöten och retrospektiv som dragit iväg på tiden och vi började känna att mötena åt för mycket av vår tid införde vi time boxing. Morgonmöte 10  min, retrospektiv 15 min, tidsuppskattning 45 minuter och prioritering 30 minuter. Alla möten går fortare när man vet vilken tid man har att röra sig med, och med den här tidsåtgången kunde de fasta mötena begränsas till 190 minuter på en tvåveckorssprint, vilket blir ungefär 20 minuter om dagen.

Steg nio: Längre sprintar
När vi började att strukturera oss var en vecka per sprint allt vi kunde hinna med eftersom ingen i organisationen hade den framförhållning som krävdes för att planera längre perioder framåt. Efter att ha kört med veckorytmen ett år hade vi skapat oss rutiner och utrymme för att förlänga sprintarna till två veckor och därmed minska den tid som gick åt till möten.

Steg tio: Demos
När vi börjat få ordentlig snurr på utvecklingen och fått till en rytm och ett flyt införde vi demos efter varje sprint. Det här kändes rimligt först när vi kommit upp till tvåveckorssprintar (annars hade demoförberedelser stulit för mycket tid). Behovet kom av att vi kände att sprintarna flöt in i varandra och vi satt och småjobbade med förra veckans rester i nästa sprint vilket gjorde tiden svårare att uppskatta.

Vad vi har vunnit på att strukturera oss
Grundförutsättningarna för vårt utvecklingsarbete är på många sätt detsamma idag som tidigare – ett konstant inflöde av idéer och utvecklingsförslag och beställarna är till och med fler. Skillnaden är väl det här:
- Vi gör alltid det som är mest prioriterat för verksamheten som helhet just nu.
- Beställarna vet vad som gäller och slipper spilla energi på att tjata på att utvecklarna aldrig gör vad de vill
- Stressen minskar med synliga prioriteringar, ingen behöver ha dåligt samvete för att något inte hinns med

Nästa steg?
Det finns mycket vi skulle kunna göra för att gå vidare för att få strukturen ännu tydligare. Ordnad backlog, regelbundna releaser kopplade hårdare till sprintarna, parprogrammering och kanske en elektronisk tickettavla (mest för att göra prioriteringen än mer tydlig för de som inte sitter just på den plats där vi sitter) är några. Men det tar vi senare.

No related posts.