Saker vi lärt oss om prioritering

Eftersom vi är en liten webbutvecklingsgrupp här på fyran har det alltid varit en utmaning för oss att välja vad vi ska göra och vad vi inte ska göra. Vi har många beställare från olika sajter med olika projekt och krav, men inte resurser till att jobba med mer än ett par projekt samtidigt. Den här utmaningen har förstås alltid funnits, men efter att vi börjat jobba mer iterativt och strukturerat har valen blivit synliga och vi har därför behövt göra tydligare och mer välmotiverade val. Här kommer några lärdomar vi dragit när det gäller prioritering.

Involvera rätt personer och tala om vem som står för prioriteringen
För oss var det viktigt att få med oss en person från beställarsidan i prioarbetet som kunde ta beslut på en övergripande nivå. Innan beställarsidan själva var med och tog ansvar för helheten hamnade vi ofta i rättviseprioritering där alla intressenter skulle få lika mycket tid snarare än att vi gjorde vad som var viktigast just nu. När vi väl fick med någon med helhetsansvar från beställarsidan blev det lättare att välja bort saker och få tydligare fokus på vad som är viktigast. Det blev också tydligt för beställarna på våra olika sajter vem de skulle prata med för att kunna påverka prioriteringen.

En grupp behövs för att göra en prioritering, men bara en kan ha sista ordet
Det vore orimligt att låta en person göra hela prioriteringen. Ingen har så bra koll både på verksamhetens behov och tekniken att de kan ta ansvar för helheten på egen hand. Samtidigt är det svårt att som grupp välja mellan flera lika viktiga projekt. Vi löser det genom att vi i utvecklingsgruppen grovprioriterar tickets per projekt och resonerar oss fram till ungefär i vilken ordning saker bör göras. Sen får den ansvarige från beställarsidan välja mellan projekten och göra de svåra affärsmässiga val som ibland uppstår.

Var tydlig med vad som planeras i sprintarna
Inför varje sprint listar vi vad som ska utvecklas i en punktlista så att beställarna kan se vilka tickets som finns med. Vi skickar också med en förklaring i löpande text om hur vi gjort prioriteringen och vilka projekt och sajter vi fokuserar på under sprinten.

Var lika tydlig med vad som väljs bort
I ovan nämnda mejl listar vi också de puckar som är viktiga men som ändå hamnat utanför sprinten. Innan vi började lista vad som valts bort trodde beställarna ofta att deras punkt tappats bort vilket ökade stressen både hos dem och hos oss som fick ta emot upprörda mejl och samtal.

Hitta en gräns för när något är så akut att prioriteringen måste ändras
Akuta fixar dyker ju alltid upp, och då gäller det att bestämma om vi ska släppa det vi har för händerna för att ta itu med saken eller om den kan vänta.  En bra utgångspunkt i de situationerna har varit att jämföra med den aktuella priotavlan. Är det viktigare att få ut fixen snabbt än att hinna med de tickets som sitter längst ner på priotavlan? Ofta blir valet enkelt när man jämför.

Synliggör konsekvenserna när prioriteringen ändras
De gånger vi väljer att klämma in något i prioriteringen under pågående sprint är vi också noga med att kommunicera ut vad som fick prioriteras bort för att få igenom snabbfixen.  För oss har den kommunikationen gjort att snabbfixarna minskat rejält.

Dribbla inte med tickets som ändå aldrig kommer att hinnas med
Det är lätt att tickets blir liggande vecka efter vecka trots att man inser att de aldrig kommer att hinnas med. Såna tickets gör prioarbetet onödigt krångligt och skapar samtidigt en falsk förväntan hos beställarna att jobbet snart ska utföras. Är en ticket för lågt prioriterad för att rimligen komma med i prioriteringen de närmsta tre-fyra sprintarna är det bättre att ta bort den, så får man skriva en ny ticket om den blir aktuell igen.

Alla ovanstående lärdomar handlar egentligen om öppenhet och tydlighet. Ju bättre vi blivit på att vara raka och tydliga med prioriteringen desto mindre tid har vi behovet ägna åt argumentation och snabba fixar, vilket har gett oss mer tid till utveckling.

Fler visningar i bruset på Play

Idag släpptes första numret av DN:s iPad-anpassade version, kallad DN+. Den bygger på plattformen News+ från Bonnier som har ett uttalat mål att liksom  papperstidningen ha en början och ett slut (50 sekunder in i presentationsfilmen). I TV-världen vill vi istället locka till fortsatt tittande och det finns inte någon självklar början och absolut inte något slut.

Därför har funktionen för att titta vidare i TV4 Play varit central. När man tittat färdigt på ett klipp eller program så vill vi tipsa om andra program som tittaren kan vara intresserad av.

Det finns två viktiga beståndsdelar i en sådan funktion:

  1. Få ut relevanta klipp
  2. Presentera på ett förståeligt sätt

Det första görs idag genom att visa fler program/klipp i samma kategori som det klipp man för tillfället tittar på. I första hand de som är från samma program men i annat fall sådana från samma kategori eller genre.

Det senare handlar mycket om att göra det lätt att förstå i vilken ordning klippen visas. Klickar jag för att titta på ett annat klipp bör inte förslagen på liknande klipp ändras alltför mycket eftersom chansen är påtaglig att man vill titta på ytterligare klipp som visades i listan första gången.

Det finns en del corner cases som varit lite luriga att lösa. Om vi visar sex klipp åt gången i vyn och det finns åtta klipp, ska vi då visa de sista klippen ensamt? Vi vill ju att användaren ska ha flera alternativ men samtidigt att funktionen ska bete sig förutsägbart.

När vi pratade om det i somras blev det snabbt tydligt att det blir alltför abstrakt att bara prata om utan att använda sig av visualiseringshjälpmedel. Då kommer kontorsprylarna snabbt till hjälp. Inplastade papper får bli avgränsare och våtservetter bli till klipp.

utveckling

Fortsätter sedan diskussionen på annat ställe i kontorslandskapet så är det istället postit-lappar som får tjäna som avgränsare och whiteboard-pennor blir klipp.

Utveckling del 2

Ute på webbplatsen kan nu funktionen se ut såhär (när det finns fem klipp in alles):
Titta-vidare-modul i TV4 Play

Många bollar i luften?

Øredev 2010 pratade Henrik Kniberg från Crisp om skillnader mellan Scrum och Kanban under rubriken “Kanban and Scrum – making the most of both“. Från den sessionen tog jag med mig ett bra exempel för att visa vad som händer om man försöker göra för mycket samtidigt (…och att det därför blir för lite gjort).

Kolla på exemplet här 13 minuter in eller läs vidare:

Så här gjorde Henrik: han tog upp en person (A) på scenen som fick agera “programmerare”. Programmeraren fick en penna och ett stort blädderblock. Sen fick ytterligare fem personer (B, C, D, E och F) gå upp på scenen och agera “beställare”.

Under tidtagning fick beställare “B” säga sitt namn varvid programmeraren “A” fick skriva ut beställarens namn på blädderblocket. Det tog 3.5 sekunder.

Därefter ska programmeraren utföra beställningar från alla beställare – men inte en beställning i taget utan alla samtidigt. Alltså startar tidtagningen och programmeraren “A” skriver på översta raden första bokstaven i “B” namn, därefter på nästa rad första bokstaven i “C” namn, sen samma sak med “D”, “E” och “F”. Sen fortsätta ett varv till med andra bokstaven i “B” namn, sen “C” osv. Det dröjer inte länge innan bokstäver missförstås, hamnar på fel rad eller hoppas över. Klockan tickar på och “A” skriver, suddar, lyssnar och försöker hänga med och fem beställare gör sitt bästa för att få sitt namn rätt. Någonstans vid 4-5:e bokstaven kollapsar mer eller mindre alla projekt.

Tiden har tickat på långt över de 5×3.5 sekunder som beställningarna hade tagit om de utförts en i taget; programmeraren är slutkörd och inget blev riktigt som beställarna tänkt sig (buggar och kvalitetsproblem, försenat och inte enligt förväntan).

Och hey – exemplet handlade om att skriva ner fem personers namn(!). Riktiga projekt innehåller komplexitet på helt andra nivåer.

Resten av presentationen var också bra men just det här exemplet har jag använt flera gånger sedan dess.

Rörligt i iPad?

Cecilia Beck-Friis, chef för Digitala medier på TV4-Gruppen, talar om den närmaste framtiden för rörligt material och vad som händer med TV4 Play under 2011 i Spotlight, som är presentationsprogrammet för våra annonsörer.

Tyvärr finns ingen direktlänk utan ni får följa länken och klicka på “Webb & mobil” och sedan på den första bilden.  Klickar man på den tredje bilden får man höra Tommy Jarnemark berätta om tankarna bakom TV4 Play.

The Wall (del I)

När vi för några veckor sedan möblerade om på avdelningen fick vi en tom vägg (tre gånger tre meter) bredvid oss. En bra yta för att sammanställa och visualisera information som vi alla har nytta av. Den ursprungliga skissen såg ut så här:

Väggen ska ge oss själva eller vem som helst som kommer förbi en överblick över situationen just nu.

Det här finns på väggen (eller är på väg upp):

Tid
En klocka. Visar tiden från husets centrala tidsstyrning. Det är en studioklocka av märket Evertz. Den är väldigt tydlig och ser till att vi hela tiden kommer ihåg att hålla nere mötestider (timeboxing, #8) och att vi kommer i tid.

Kvalitet/Status
En skärm som visar olika statusflöden. Visar bland annat resultatet av Continuous Integration-servern som Brian skrev om. Om vi slarvar med kvaliteten (till exempel checkar in kod som inte fungerar eller som har sönder några tester) eller något går ner (driftstörningar) så ska det visas här.

Vi kanske också lägger in lite trafik- eller andra visualiseringar. Eftersom det är en vanlig webbläsare räcker det med att presentera innehållet på en webbsida för att det ska kunna visas upp här. Just nu visar den också senaste publicerade klipp på TV4Play. Konstant ”work in progress” förhoppningsvis.

Idéer och skisser
En stor rit-tavla där vi kan skissa, rita, anteckna och brainstorma. Började användas redan någon timme efter att den monterats så det verkar som vi haft ett behov av en sån här. I glas.

Hastighet
Syns inte i skissen men vi har också plats för ett Burn Down Chart som visar hur vi ligger till i förhållande till arbetet vi åtagit oss. Den visar hur många poäng/enheter arbete vi betar av dag för dag under en sprint i förhållande till en idealkurva och totala åtagandet.

Prioriteringen
Det vi arbetar med just nu. Vi prioriterar i sprintar och varje ärende ska röra sig från vänster till höger (att göra, under arbete och Done!) och helst ska allt vara i högerkolumnen när sprinten är klar.

Så en person som kommer fram och undrar hur det går kommer genom väggen få en tydlig uppfattning om:
1. Vad vi håller på med.
2. Hur det går (och hur sprinten flyter på).
3. Status på drift och kvalitetsläget just nu.
4. Ifall vi har några nya idéer eller koncept på gång.
….vad klockan är.

Jag följer upp det här med några foton när allt sitter uppe.