Biobank Sverige ITs arbetssätt

Hela Biobank Sverige ITs arbetssätt utgår från agila principer. För den som vill ha en bättre introduktion eller uppdatering av vad det innebär än vad vi kan ge här rekommenderar vi varmt följande introduktion som satts ihop av Henrik Kniberg på Crisp och går igenom mycket av grunderna till agilt arbetssätt. https://www.youtube.com/watch?v=502ILHjX9EE
Resten av denna sida förklarar hur just Biobank Sverige IT jobbar för att vara agila.

Metodik

Biobank Sverige IT strävar efter att vara en integrerad del av verksamheten för att på så sätt bättre förstå våra utmaningar och behov. Vi tror inte att man kan bygga bra lösningnar om man inte förstår vilket problem de ska lösa och var i alla olika processer de passar in.

Vi tror också att det är väldigt värdefullt att förså hela verksamheten för att på så sätt hjälpa till att se vilka delar som har mest nytta av IT-stöd så att vi kan hjälpas åt att prioritera de lösningarna som kräver lite IT-resurese och ger stor utdelning för verksamheten.

Detta leder till ett ständigt lärande och nya insikter. En traditionell roadmap med lång planering är därför inte optimalt. Vi jobbar med ständig prioritering av vad vi ska göra allteftersom vi lär oss nya saker eller upptäcker nya utmaningar eller möjliga lösningar.
Det betyder inte att vi inte har ett mål eller en plan, men att det är viktigare att vi gör det mest värdefulla först än att följa en plan. Det är det vi menar när vi säger att vi är agila och finns fint summerat på https://agilemanifesto.org/

Praktik

Roller

• Produktägare
  Produktägaren är den som har sista ordet när det gäller prioritering av ärenden (och också om de över huvud taget ska göras). Produktägarens viktigaste uppgift är att väga kostnad mot nytta för varje ide som kommer in. Hur stor nytta en funktion har är det bara verksamheten som vet och det är därför mycket viktigt att produktägaren pratar med verksamheten, dels med indovoder, dels med olika referensgrupper för att kunna förstå.
  På samma sätt pratar produktägaren med utvecklingsteamet för att förstå kostnaden (tiden) för att bygga funktionen och om de får andra konsekvenser (t.ex. att vi behöver avtal med extern leverantör för signering).
  Produktägaren gör sedan en bedömning av vilka ärenden som ger mest nytta för pengarna och prioriterar utefter det

• Scrum-master
  Scrum-masters uppgift är att skydda utvecklingsteamet så att de kan jobba effektivt. Det betyder allt ifrån att vara kontaktperson till att se till att möten och annat planeras på ett sätt som passar för att alla ska få en så bra och effektiv arbetsmiljö som möjligt. Scrum-master är ofta en av utvecklarna i utvecklingsteamet.

• Utvecklare
  De som utgör kärnan av utvecklingsteamet och bygger mjukvaran.

Vardag

Vi jobbar i treveckors-cykler, så kallade sprintar. En sprint är tre veckor och följer alltid samma mönster

En sprint börjar alltid med sprintplanering. Inför sprintplaneringen har produktägaren prioriterat de ärenden som ska göras och utvecklingsteamet har bedömt storleken på dem (detta görs på refinement, se nedan).
Baserat på hur mycket som hunnits med på tidigare sprintar planerar man för hur mycket man tror kommer hinnas med, de ärendena utgör sedan sprinten.

Refinement görs varje onsdag. Här preseneterar produktägaren de ärenden som kommer i kommande sprintar och går igenom de med teamet som hjälps åt och se hur de kan lösas och ungefär hur mycket tid det kommer ta att lösa. Varje ärende får en poäng som är teamets bästa gissning för hur stort det är.

Retrospektiv är ett möte i slutet av varje sprint där alla i utvecklingsteamet, scrum-master och produktägare gemensamt går igenom vad som fungerat bra och vad som fungerat mindre bra i sprinten. Det viktigaste är förslag på förändringar, ofta mindre justeringar, som vi inför genast och sedan uvärderar igen tre veckor senare. På så sätt strävar vi alltid efter att jobba så effektivt och bra som möjligt.

Sprintdemo
På sprintdemo, eller bara demo, visar produktägaren upp vad som gjorts i senaste sprinten och vad som planeras i nästa sprint för alla intresserade. Detta är det i särklass viktigaste mötet för den som vill veta hur det går och vad som är på gång. Alla är välkomna på sprintdemo och det brukar vara många (20-50) från allt från labb till SKR som är med på sprintdemo.

Lösa trådar
Hur mycket man än planerar kommer det alltid småsaker som hamnar lite åt sidan. Vi har därför valt att avsluta våra sprintar på torsdagen vecka tre och låta utvecklingsteamet få en dag att beta av de där småsakerna som aldrig hinns med. Helst ska vi ha tid i sprinten att göra även de sakerna och är listan tom kan vi alltid smygstarta på något från nästa sprint eller jobba med krav, behov, skisser eller annat som behöver göras.

Daily standup
Varje dag kl 15-ca 15:30 träffas hela Biobank Sverige IT och går igenom status. Det innebär att alla berättar kortfattat vad man jobbar med just nu och om man stött på några hinder. Det är också ett tillfälle att stämma av eventuella frågor som kan röra allt från när vi ska produkttionssätta till frågor om driftmiljö eller VAB. Allt som kan vara av intresse för hela Biobank Sverige IT att känna till.

Planen ovan representerar bara de fasta möten vi har enligt vår metodik. Utöver detta har vi möten vid behov för att prata framtida behov och krav, reda ut eventuella oklarheter i sprintens ärenden och mycket annat.

Hur får vi reda på behoven?

Behov kan variera väldigt i storlek och komplexitet, allt ifrån att justera formulering i en text till en applikation där medborgare kan hantera sina samtycken.
Det är därför viktigt att dels aktivt samla in behov, dels lyssna på alla de som på ett eller annat sätt använder eller påverkas av de system vi bygger.

Alla idéer, små och stora, förtjänar att lyssnas på och att tas på allvar, men det betyder inte att alla önskemål kommer att kunna tillgodoses. Produktägaren måste ständigt göra avvägningar mellan behov och kostnad. Vissa behov prioriteras och löses snabbt, andra läggs i vår backlogg för att lösas senare medans ytterligare andra måste avfärdas.

Det absolut viktigaste när vi planerar vårt arbete är att förstå behovet, inte att få uppgifter. Genom att förstå varför någonting behövs kan vi tillsammans med verksamheten hitta bästa möjliga lösning som gör att behovet uppfylls. Ibland kan det vara något helt annat än urspringsförslaget.

Ett bra exempel på detta är kravet i SBR där man hela tiden ville ha uppdaterad folkbokföringsadress när man tittade på ett samtyckesärende. Efter lite samtal kring detta visade det sig att det var för att man när som helst ska kunna skicka brev. Ytterligare diskussioner om när och varför man skickade brev ledde istället till en lösning där systemet automatiskt genererar (och snart skickar) breven. Något som inte hade hänt om vi inte pratat om syftet med funktionen.

Hur kommer vi till ärenden?

När vi börjar förstår ett behov jobbar vi mycket med skisser och lösningsförslag. Beroende på uppgiftens omfattning kan dessa visas för referensgrupper i omgångar och förfinas (t.ex. samtyckeshanteringen) eller bara stämmas av med några få intressenter vid enstaka tillfällen (t.ex. registerutdrag som stämts av med DSO:er)
Oavsett hur detta arbete går till är det alltid i dialog med slutanvändare och andra intressenter. Vi försöker också alltid bryta isär större uppgifter så att vi kan leverera så tidigt som möjligt och lära oss mer innan vi går vidare istället för att leverera allt vid en stor release på slutet.
På sprintdemo visar vi alltid det som har utvecklats så att alla som är intresserade vet vad vi gjort och vart vi är på väg.