Bytelab implementerer SAFe som nyt rammeværktøj til agil produktudvikling

Som IT-virksomhed er det utroligt vigtigt, at ethvert udviklingsprojekt løber så effektivt som overhovedet muligt. Dog kan det være svært at planlægge hele udviklingsprocessen på forhånd, da nye IT-projekter ofte er helt nyt territorie. Derfor har traditionelle vandfaldsmodeller ikke været optimale at bruge, fordi de lægger op til, at man skal planlægge alt på forhånd.

I stedet for de traditionelle vandfaldsmodeller er der udarbejdet en række nyere metoder og værktøjer til at sikre, at en virksomhed kan levere bedre softwareprodukter hurtigere og mere effektivt. Det var også den primære grund til, at Bytelab allerede for flere år siden tog en række agile værktøjer til sig for at sikre en bedre og mere flydende leverance. Nu har vi så nået en vis størrelse og behov, som gør os klar til at implementere et af de mest kendte og anerkendte agile rammeværker – SAFe.

Vi har inddelt dette indlæg i to dele. Den 1. del er en kort og overordnet introduktion til SAFe med en beskrivelse af de mest gængse termer. Er du allerede velbevandret i SAFe, vil vi derfor anbefale dig at springe direkte til del 2, hvor du kan læse mere om Bytelabs rejse ind i SAFe-universet, samt hvilke features vi netop har planlagt i vores allerførste PI-planning.   

 

DEL 1

Hvad er SAFe?

Scaled Agile Framework® blev første gang introduceret tilbage i 2011 og kan betegnes som en overbygning til Scrum, der har sin oprindelse helt tilbage i midt 90’erne. SAFe har nemlig adopteret flere elementer og begreber fra Scrum, som er et af de mest anerkendte agile rammeværker i verden. Scrum er dog bedre egnet til små teams, hvor der er fokus på at organisere og administrere arbejdet i de specifikke teams, hvor SAFe omfavner flere elementer som tilgodeser hele organisationen.

SAFe er kort fortalt et skalerbart rammeværktøj, der kan være med til at sikre en effektiv levering af nye produkter med den højest mulige værdi for kunderne. SAFe bidrager blandt andet til, at organisationens agilitet forbedres dramatisk, produktiviteten accelereres, time-to-market forkortes, kvaliteten øges og medarbejderinvolveringen stiger. Der er derfor rigtig mange positive følgevirkninger, hvis man forstår at udnytte SAFe optimalt.

 

Ud fra ovenstående billede er det tydeligt at se, at der er utrolig mange elementer, roller, niveauer og lignende i SAFe. Det betyder dog ikke, at man som organisation skal benytte sig af dem alle for at opleve den fulde effekt. Det gode ved SAFe er, at der stilles nogle rammer, metoder og værktøjer til rådighed, som kan tilpasses alt efter behov og type af organisation.

 

Fire versioner af SAFe

Helt grundlæggende findes der fire forskellige versioner af SAFe, som kan tilpasses alt efter behov. De fire versioner er: Essential SAFe, Large Solution SAFe, Portfolio SAFe og Full SAFe.

Groft sagt kan man sige, at jo større virksomhed, desto flere elementer, roller og niveauer vil man typisk benytte sig af for at styre den samlede udviklingsproces. Er man en lille virksomhed med få medarbejdere og 3-10 teams, vil de to øverste niveauer formentlig ikke være nødvendige. Hvorimod større virksomheder med flere hundrede eller tusinde medarbejdere kan have stor glæde af at bruge alle fire niveauer.

I Bytelab har vi valgt at implementere Essential SAFe grundet vores størrelse og antal teams. Essential SAFe består af to niveauer, Team- og Programniveau, og disse vil blive uddybet i de følgende afsnit.

 

Teamniveau

I hvert niveau er der klart definerede aktiviteter, ansvarsområder og roller, som har vigtige funktioner i den agile udviklingsproces. Det første niveau kaldes for Teamniveau og er fundamentet for SAFe. I dette niveau finder man bl.a. betegnelsen iterationer (sprints i Scrum), hvilket er en fastafgrænset periode på fx 14 dage. Iteration betyder ”gentagelse” og er byggestenene for hele den agile udviklingsproces. Hver iteration gennemføres efter samme model hver gang for at sikre, at udviklingsarbejdet kan strømlines og dermed er så effektivt som overhovedet muligt.

I hver iteration ligger en række opgaver klar, som udviklingsteamet har engageret sig til at kunne løse. Opgaverne kommer fra en Team Backlog, som håndteres af en Product Owner. Det er PO’ens ansvar at sikre, at teamet altid arbejder på de vigtigste opgaver, der kan skabe den højest mulige værdi for kunderne. Der ligger en stor opgave for PO’en i hele tiden at optimere og prioritere backloggen, så de vigtigste opgaver ligger i rangeret orden.

Når en iteration når sin afslutning, vil der være et Review, hvor opgaverne præsenteres for relevante interessenter. Efter hvert review går teamet sammen og udfører et såkaldt Retrospective, hvor de snakker om, hvad der kunne være gjort bedre i løbet af iterationsperioden med henblik på at forbedre dette til næste iteration. Dernæst vil der igen ske en Iteration Planning, hvor PO’en og teamet forbereder den næste iterationsperiode med de vigtigste opgaver, hvorefter det hele gentages i en ny iteration.

 

Til at være med til at sikre den bedst mulige gennemførelse af hver iteration er der udpeget en Scrum Master. Dennes ansvar ligger i at praktisere de agile værdier og sikre, at udfordringer hurtigst muligt ryddes af vejen, når de opstår. Det er derfor ofte en udvikler, som får dette ansvar og dermed kan være med til at støtte og vejlede de andre udviklere i deres arbejde. Derudover kan det også være Scrum Masterens opgave at facilitere Daily stand-ups, som er et kort møde, hvor teamet mødes hver morgen og får vendt dagens opgaver og eventuelle afhængigheder/udfordringer.  

Iterationer er inddelt i såkaldte Program Increments (PI), som er en fast defineret pulje af iterationer. Normalt er hvert PI mellem 8-12 iterationer. Formålet med et PI er at sikre, at der løbende sker en synkronisering af de forskellige teams’ arbejde, således alle teams arbejder hen imod de samme mål og de samme produkter. 

 

Programniveau

Hvor teamniveauet er det grundlæggende udviklingsarbejde med faste rammer, faste teams, faste roller og faste aktiviteter, indeholder Programniveauet nogle af de samme elementer blot på tværs af teams. Efter hver iteration samles alle teams til en System Demo, hvor de nye features bliver præsenteret. Når et PI når sin afslutning, afholdes der et Inspect and Adapt, hvor de forskellige teams demonstrerer produktets nuværende stadie overfor programniveauets interessenter. Evalueringen af Inspect and Adapt lægger fundamentet for de opgaver, som de forskellige teams skal løse i næste PI.

For at få helt styr på det næste PI afholdes der en PI-Planning, som er et event, hvor alle teams mødes med de forskellige PO’er og Scrum Masters samt relevante interessenter og roller på programniveauet. Formålet med PI-planning er at få udarbejdet, forfinet og prioriteret en fælles Program Backlog med opgaver, som skal ligge til grund for de forskellige Team Backlogs. Derudover er det essentielt at få udformet PI objectives, som er de forretningsmæssige og tekniske mål, der skal opfyldes inden for PI perioden.

Som det forhåbentligt fremgår i ovenstående afsnit, minder elementerne og processerne meget om hinanden på team- og programniveau. Dog er det nogle nye roller på programniveau, der styrer slagets gang på tværs af de forskellige teams. Her møder vi fx Release Train Engineer, Business Owner, Product Manager og System Architect.

Det er Release Train Engineerens (RTE) opgave at facilitere og forberede PI-planning. Derudover har denne person også ansvaret for både Scrum of Scrums og PO sync. Ved Scrum of Scrums mødes alle Scrum Masters og deler deres viden fra deres teams. Det samme gælder for PO sync, hvor PO’erne mødes og diskuterer de forskellige produkter og løsninger.

Business owneren står for forretningens resultater og har den overordnede rolle i SAFe.

Product Manageren kan sammenlignes med PO’en på teamniveauet. Denne person har fokus på at forstå kundernes behov og ønsker samt ansvaret for at beskrive indholdet af program backloggen og prioritere opgaverne.

Sidst men ikke mindst, har vi systemarkitekten, som sørger for, at organisationen har de rigtige infrastrukturer og tekniske rammer til at udvikle og levere produkterne. Vi kunne blive ved med at beskrive, tegne og forklare mere om SAFe, da der er mange flere elementer, men vi har valgt at holde her.

Hvis du ønsker at lære mere om SAFe, kan du læse meget mere her: www.scaledagileframework.com

 

DEL 2

I del 2 kan du læse om, hvorfor vi hos Bytelab har valgt at bruge SAFe. Derudover vil vi forsøge at give et indblik i selve implementeringsprocessen samt afholdelsen af vores første PI-planning.   

Hvorfor SAFe hos Bytelab?

Vi har igennem flere år benyttet os af en række forskellige principper og metoder fra agile rammeværk, men vi er nu nået en størrelse, hvor det er nødvendigt at implementere et større og bedre værktøj til at håndtere softwareudviklingen, så vi fortsat kan skabe mest mulig værdi for vores kunder.

Her er SAFe et godt værktøj, som giver os de rette metoder og teknikker til at styre og synkronisere flere og større IT-projekter uden at gå på kompromis med kvaliteten eller leveringshastigheden. Faktisk er det målet, at vi skal blive endnu bedre og hurtigere til at levere værdiskabende produkter til vores kunder.

Som vi har beskrevet i del 1, er der fire forskellige versioner af SAFe, hvor vi i første omgang har valgt Essential SAFe, da vi trodsalt ikke har en kæmpe udviklingsafdeling og ikke er fordelt på flere lokationer.

 

Den foreløbige implementering

Vi har i de sidste måneder afholdt en række workshops og arrangementer for medarbejdere hos Bytelab med henblik på at skole dem så godt som muligt i SAFe. Til at hjælpe os med det har vi allieret os med Søren Weiss og Finn Leander, som begge er certificerede coaches i SAFe. De har bl.a. hjulpet Topdanmark, Aarhus Universitet, Danske Bank og mange andre med SAFe, så vi er i meget kompetente og trygge hænder.

Vi har arbejdet på højtryk for at finde de rette medarbejdere til de forskellige roller og fået etablereret tre teams i alt. Vi har valgt, at vores PI sekvens skal være på 9 uger, men kan blive justeret hen ad vejen.

Kernen i PI-planning er at finde svarene på to helt centrale spørgsmål i SAFe:

1. Hvad har vi til hensigt at levere til vores kunder?
2. Hvilken værdi har vi til hensigt at skabe for vores kunder?

Ved at have disse to spørgsmål for øje kan vi planlægge og levere de vigtigste features til vores kunder over de næste 2 ½ måneder. Når tiden er gået, kan vi så forhåbentligt præsentere resultaterne til stor glæde for vores kunder, hvorefter en ny omgang PI-planning finder sted – igen med præcis samme to spørgsmål for øje.

Hvad får vores produktkunder ud af det?

Det vigtigste for os er at levere de bedste løsninger til vores kunder, derfor er det klart, at den store og altafgørende begrundelse for vores implementering af SAFe er af hensyn til vores kunder. Det har været udgangspunktet fra begyndelsen, da vi i starten af 2019 besluttede os for at undersøge mulighederne for brug af et agilt værktøj til produktudvikling. Vores kerneprodukt, Bytelab Car Commerce, har utrolig mange elementer og funktioner, og her vil SAFe hjælpe med at fokusere og synkronisere disse, så BCC bliver endnu bedre.

Derudover skal SAFe være med til at effektivisere og fokusere udviklingsarbejdet, så kunderne oplever hurtigere releases og bedre features, som kan gavne deres forretning.

 

Hvor står vi nu?

Implementeringen af SAFe er en større proces, som kræver mange ressourcer og involverer rigtig mange medarbejdere hos Bytelab. Derfor kan vi heller ikke gøre det over natten, selvom vi gerne ville. Det bliver i stedet en rullende implementering, hvor vi løbende får strømlinet flere og flere processer. Vi skal have trænet medarbejderne i de nye metoder, så det kommer ind på rygraden og bliver en naturlig del af dagligdagen i Bytelab.

Vi har struktureret og tilpasset iterationerne og PI’s (9 uger) ud fra en grundig analyse af vores organisation og produkter. Dog vil vi hele tiden tilegne os ny viden og erfaringer, som kan bruges til at justere længden på iterationer, struktureringen af PI-planning og lignende, så det hele tiden giver mest mulig værdi for vores kunder.

Vores første PI-planning blev afholdt d. 24-25. september, hvor vores tre udviklingsteams fra Products and Delivery var samlet for at få lagt planen for de næste 9 ugers udvikling. Det var en vigtig milepæl, som var startskuddet til vores brug af SAFe. Tiden blev brugt på oplæg, øvelser og samarbejde i hvert team og på tværs af teams for sammen at nå frem til en skitsering af alle de features, som vi forventer/ønsker at udvikle over de næste 2 1/2 måneder. Vi påbegynder bl.a. arbejdet på en porteføljeliste til Bytelab Car Commerce som et tilkøbsmodul, så det bliver muligt at håndtere aktive kontrakter i BCC. Vi ønsker at lave et nyt interface, hvor man kan søge, sortere og få vist aktive kontrakter, kunder og biler. Derudover skal det være muligt at se, hvornår de forskellige leasingaftaler udløber, samt hvilken genberegningsstatus de forskellige biler har. Dette er et stort projekt, som ikke bliver færdigudviklet i vores første PI-periode.

Dertil forventer vi at levere digital signatur til lån, hvor denne funktionalitet indtil videre kun har været gældende til leasing. Det skal være muligt at foretage digital signering ved lån med manuel og automatisk styring af dokumenter til underskrift.

Derudover vil vi arbejde på en gennemgribende optimering af kreditvurderingen, så det bl.a. bliver muligt at differentiere imellem privat og erhverv. Vi gør bl.a. regnskabstal tilgængelige direkte på kreditvurderingsiden for erhvervskunder.

Og så vil vi kigge på vores i forvejen omfattende TCO-beregning til også at omfatte el- og hybridbiler, samt understøttelse af ladestationer. Det skal derfor gøres muligt at angive en specifik pris på el samt at oprette en tillægsydelse for et abonnement, så udregningen af TCO’en bliver præcis.

 

Ovenstående er blot et udsnit af de ting, som vi ønsker at kigge på i løbet af denne første PI-periode. Vi glæder os derfor til at fortælle meget mere til december, hvor vi afslutter det første PI og samtidig påbegynder det næste.