Välj en sida

Under de sista 10 veckorna av hösten jobbar vi för Bonnier Broadcastings streamingtjänsters utveckling med en process kallad Agile Release Train.

Bonnier Broadcastings teknikavdelning (BBR Produkt & Teknik) startades för drygt 15 månader sedan. Under den tiden har vi haft fokus på:

  1. att få ihop våra två streamingprodukter TV4 Play och C More i en gemensam organisation som tar ansvar för teknikplattformen och
  2. tekniskt bygga en stabil grund för denna teknikplattform. När vi startade var vi två organisationer och två teknikplattformar.

Framgent så har vi fokus på att göra ännu mer gemensamt och att utveckla helheten i teknikplattformen samtidigt som vi levererar värde i de båda produkterna.

Vi har i många år förbättrat oss inom agil systemutveckling och kommit väldigt långt på team-nivå. Våra team har en förfinad och optimerad process för att leverera efter teamets bästa förmåga.

Det vi kan förbättra oss på är helhetsleveransen. Vi har inte haft något bra verktyg för att prioritera och följa upp på programnivån (dvs totala leveransen mot verksamheterna) eller något spetsigt verktyg för att prioritera mellan våra olika verksamheter.

I vintras införde vi ett verktyg i organisationen som vi kallar för topp-tio-prio OTT där vi varje fredag prioriterar det viktigaste att färdigställa kommande veckor oavsett om det är för TV4 Play, C More eller vår bakomliggande teknikplattform för våra streamingtjänster. Detta för att skapa större tydlighet – i de fall det uppstår resurskonflikt så ska man som medarbetare veta vilket initiativ som är viktigast att prioritera sin tid för.

Det har tagit oss en bra bit på vägen och varit värdefullt med tanke på den fas vi var i då. Nu är det dags att lyfta oss vidare genom att bli effektivare i de stora initiativen, som kräver mer koordination och samverkan mellan våra olika team.

[Fotocred Emelie Lindgren]

Vi är idag 14 team enbart inräknat de som arbetar med våra streamingtjänster (Produkt & Teknik jobbar även med vanlig tv-tv och våra digitala tillväxttjänster fotbollskanalen.se och köket.se), och vi är fler än 80 personer som jobbar i dessa team.  Vi har för ofta hamnat i situationer där ledtider i våra leveranser orsakas av att olika initiativ inte är färdigdefinierade och väntetider mellan interna team, då våra olika roadmaps inte alltid är i synk.

Som exempel: Backend-teamet (väldigt förenklat då vi inte har ”ett” backend-team) levererar v.21 och klientteamen som ska ta vid för att testa och vidareutveckla har inte tid förrän v.24. Där tappar vi tre veckors ledtid i kod som varken är verifierad eller kan tas vidare hela vägen till produktion.

Detta vill vi förbättra. Vi vill minska ledtider som är oekonomiska och som samtidigt gör oss mindre förutsägbara för omgivande avdelningar som måste ta hänsyn till innehållsfönster, marknadsföringsfönster och tablåstarter. Där finns också aspekten att all utveckling och alla initiativ inte är lika mycket värda om de inte lanseras tidigare än ett visst datum. Levererar vi senare kan vi vänta med utvecklingen till ett bättre lanseringsfönster.

Kort sagt, med detta arbete vill vi öka vår effektivitet, bli mer ekonomiska samt mer förutsägbara som utvecklingsorganisation gentemot oss själva och mot affärsverksamheten. Att veta vad som ligger i horisonten och vad som inte är på gång ger också mindre stress på köpet.

Enter ART (agile release train)

Några av oss hade läst och inspirerats av Don Reinertsens, Product Development Flow och Dean Leffingwells, Agile Software Requirements när ett gäng av oss gick kursen SAFe-Kickstart i våras hos Crisp. Från dessa inspirationsområden fick vi en verktygslåda som vi använde som grund när vi definierade vårt ART-verktyg.

I stort ser det ut som följer i dessa fem punkter:

  1. Vi gör en gemensam planering och utvecklingsroadmap för kommande 10 veckorna.
  2. Roadmappen ska täcka in 50-60% av teamens totala kapacitet. Resten av tiden går till oplanerat arbete som incidenter, felsökning, stabilisering av kodbasen och buggfixar samt korttidsplanerad utveckling som går till teamet direkt från produktägaren.
  3. Vi avsätter rejält med tid upfront för planering av 10-veckors-perioden där vi bryter ned initiativen, fastställer scope och lösningar samt mappar beroenden mellan teamens leveranser.
  4. 10-veckors-perioden delas upp i 4+1 sprintar.
  5. Vi planerar in arbetet i 4 av dessa sprintar och lämnar den 5:e sprinten till innovation och hardening.

Vad är ART och vad är inte ART

Hur införde vi detta?

Vi gjorde enligt klassisk projektmetod en baklängesplanering för att införa processen.

Sista veckan för release innan jul blev sista veckan i sprint 5. Då visste vi när vi skulle starta sprint 1 och veckan innan blev planeringsveckan.

Alla projekt, features och epics som påverkar någon av de 14 delaktiga teamen i vår streamingutveckling tog vi fram och bedömde mognadsgrad i en grov bruttolista. Efter sållande insåg vi att allt inte var redo för utveckling och därmed lyfte vi ut ett antal initiativ.

Därefter gjorde vi en prioritering med hjälp av en formel baserad på cost of delay för varje initiativ. WSJF-formeln (Weighted Shortest Job First). Efter att ha graderat alla initiativ med bas av formeln var vi tvungna att lyfta några av måste-projekten som inte fick den score de behövde (eller snarare vi kan inte påverka dess viktighet inom utveckling, de ska göras).

Nu hade vi en prioriterad bruttolista som kunde gå in i planeringen.

WSJF-formeln för prio

Planeringsfasen gick till så att vi samlade samtliga på Produkt & Teknik och gick igenom processen, gick igenom allas ansvar och agendan för planeringsveckan. Omedelbart efter startade planeringen i teamen, mellan teamen och våra fördjupningssessioner för de större initiativen. Den konkreta uppgiften för varje team var att skapa en planering för hur dessa initiativ ska implementeras med tanke på beroenden mellan andra team och ens egna arbetsbelastning i teamen. Några initiativ var tvungna att strykas och några highlightas som stretch-goals. Samtliga som jobbar med vår utveckling var med i detta planeringsarbete.

Efter planeringsveckan hade vi en plan med releaser som ska genomföras från varje team med koppling till varje initiativ.

Vi gjorde alltså en stor planering för hela ART:en – dvs 5 sprintar.

Vårt tåg – uppdelad i sprint-arbeten och leveranser per initiativ

Vi detaljerar inför varje kommande sprint fyra saker:

  1. Vilka kundreleaser gör vi i denna sprint?
  2. Vilka enabler-releaser gör vi i denna sprint?
  3. Vilka nya initiativ planerar vi ska starta sitt (implementations)-arbete i denna sprint?
  4. Vilka risker ser vi för sprinten?

Efter varje sprint följer vi upp de releaser vi genomfört och i de fall några inte genomförts gör vi en bedömning om de utgör någon risk för den stora planen. Varje fredag 15.00 följer vi upp framdriften under ett stormöte på golvet där vi går igenom tavlan.

Releaser per sprint

Vi har en ödmjuk approach till införandet av den här processen. Vi har infört denna process utan extern hjälp av certifierade coacher eller liknande. Det har stundtals känts utmanande men jag tror vår team-effort stärkt oss i själva genomförandet även om vi redan efter en sprint har en lång lista på saker vi kan göra bättre till nästa ART. Vi kommer lära oss längs med vägen vad som funkar och inte och vi har medvetet varit försiktiga i att anamma för mycket av SAFe-ramverket. Vi gjorde det på vårt sätt.

En bättre planering och medvetenhet för att hantera beroenden i stort över teamen, är det som kommer att göra oss bättre på att leverera med minskad ledtid och därmed med ökad hastighet. Det är min övertygelse.

Marcus Lindén – Chef för utveckling & integration på Bonnier Broadcasting