De sidste 5 måneder har jeg været del af et eksperiment med at indføre Scaled Agile Framework (SAFe) i vores organisation – som navnet antyder et framework til at skalere agilitet så det adresserer nogle af de udfordringer der følger med store udviklingsorganisationer. Mange har spurgt til mine erfaringer og bedt mig om at blogge, men jeg har ikke gjort det før nu – ganske simpelt fordi jeg ikke kunne svare på det ofte spurgte spørgsmål: Var det en god ide for os at indføre SAFe? Det kan jeg stadig ikke, men nu har jeg accepteret at svaret forbliver “it depends” – det afhænger af hvilke øjne der ser og hvilket aspekt vi ser på, så lad os bare tage et hurtigt kig ind i maskinrummet.
Konteksten: Jeg sidder til hverdag i en afdeling kaldet “Digital Experience Platform”. Afdelingen består i øjeblikket af 6 udviklingsteams + det løse. Jeg sidder som Scrum Master for 2 erfarne Scrum-teams. “Platform” skal forstås som at dette har været tænkt som backend-teams dvs. vi lever i en verden med komponent-teams og ikke feature-teams. Det er ikke helt så sort-hvidt i hverdagen, men i store træk passer det meget godt.
I indførslen af SAFe har vi haft nogle specifikke udfordringer. Der er ting i SAFe som ikke fungerer specielt godt for os (og de er automatisk mere synlige end de ting som bare fungerer). Min holdning har indtil videre været at mange af disse gnidninger har været med til at vise os hvilke ting vi skal arbejde med. Ikke fordi vi skal tilpasse os til SAFe, men fordi det er problemområder – og SAFe er bare lommelygten som vi bruger til at skinne lys på vores svagheder. Enkelte gnidninger har dog været på grund af hvad jeg ser som uhensigtsmæssigheder i SAFe.
Release trains og de tilhørende organisationer er et godt eksempel på en ting i SAFe som ikke virker for os endnu. Vi har indført SAFe i samarbejde med vores søsterafdeling som står for at lave websites og andre digitale produkter på platformen som vi leverer. Første take på release trains fulgte vores nuværende afdelingsstruktur, sådan at platforms-teamsne er på samme release train og produkt-teamsne er på samme release train. Typisk er det sådan at platforms teams har mest brug for at koordinere med produkt-teams (og driftsafdelingen) og omvendt og i langt mindre grad med andre platforms-teams. Det samme gælder for produkt-teamsne – de skal koordinere med platformsteams men ikke så meget med hinanden, da de typisk arbejder på uafhængige produkter. Release trains er sat i verden for at koordinere afhængige teams, så de giver mindre mening, når man deler release train med teams man ikke har afhængigheder til. Det gør mange koordineringsmøder i SAFe såsom SAFe-udgaven af “Scrum of Scrums” langt mindre brugbare. Begrundelsen for dette valg af release trains var at der til et release train tilhører en koordinerende organisation og den organisation var allerede opbygget på afdelingsniveau. SAFe sætter her fingeren på det ømme punkt at den nuværende afdelingsopdeling ikke er ideel.
Et punkt hvor der er en fornemmelse af at vores organisation ikke passer så godt på SAFe er produktstørrelsen. SAFe virker som om det er optimeret til at mange teams skal arbejde sammen om ET fælles produkt – og uanset at vores mange små produkter trækker på den samme store platform, så føles det ikke som om at vi helt er i den kategori (selv om man kan tolke det sådan). Det kan især mærkes i diskussionerne om prioriteten af features (WSJF). Her bliver det snarere en konkurrence mellem produkterne (og forskellige brugergrupper/kunder) end en prioritering af hvor vores fælles produkt skal udvikle sig som det næste. Dertil kommer at de enkelte udviklingsgrupper er specialiseret indenfor nogle bestemte opgaver (f.eks. søgning, analytics, CMS) og dermed kan man ikke opnå idealet om altid at arbejde på det vigtigste uden at nogen sidder uden opgaver. Vi står nu overfor valget om at nærme os SAFe-idealet ved at gøre teamsne mere generelle, beholde vores specialiserede teams og så kun dele enkelte opgaver (dem som ikke falder naturligt i et bestemt team) eller lave en hybrid. Der er fordele og ulemper ved alle mulighederne og meget politik i sådan en beslutning. Dette kan både ses som at SAFe ikke passer til vores vilkår eller at SAFe har sat fingeren på en af vores svagheder.
Den værste ting som indførelsen af SAFe har ført med sig er en normalisering af story points på tværs af teams til estimering. Ideen bag er at man skal kunne sammenligne investeringsudgiften på features så man kan prioritere den fælles backlog. Den foreslåede metode er at man “rebooter” teamsnes estimeringsskala sådan at 1 point = 1 dag. Efter den første kalibrering kører man så relativ estimering igen, hvor skalaen så “bare” er den nye skala. Desværre er det i praksis meget svært at komme tilbage til en relativ skala, når man en gang har bundet den til en tidsenhed. Der er også en kæmpe fælde at falde i her, når vi også blander velocity ind i ligningen – potentielle samtaler der går i retning af “hvorfor har I kun lavet 24 dages arbejde i en program increment (PI), når I har 140 mandedage til rådighed?” eller “hvorfor vil I kun tage 24 dages arbejde ind i jeres plan for næste PI, når I har 140 mandedage til rådighed?” – endnu værre kan blive en sammenligning af teams (på et intetsigende grundlag) og dermed kan vi pludselig komme til at høre om et “effektivt team” og et “dovent team” uden at det har hold i virkeligheden. Estimering og planlægning er svært nok uden at man spænder ben for sig selv og denne normaliseringsøvelse kan gå slemt ud over tilliden mellem teams og ledelse, hvis den bruges forkert. Dermed ikke sagt at øvelsen ikke kan føre gode ting med sig – såsom samtaler om hvilke vilkår man giver forskellige teams, som fører til at de har iøjnefaldende forskellig fremdrift målt på den samme skala.
Teamsne oplever nok ikke en markant stor forskel på at leve i en SAFe-verden og i en Scrum-verden, men min egen rolle som Scrum Master har udviklet sig. Ikke nok med at jeg nu også skal kende til SAFe udover Scrum (Scrum Masteren ejer jo processen), så er der også ekstra koordinering bygget ind i rollen i SAFe. Retrospectives på release train-niveau (inspect and adapt – IA) er et godt eksempel – Scrum Masterne skal indsamle teamets input og tage med til et fælles møde om forbedringsmuligheder, hvilket er meget brugbart, fordi det også giver et større løftestang til at rykke på impediments. Et andet eksempel på en tilføjelse til Scrum Master-rollen er “Scrum of Scrums”-SAFe-møder, hvor Scrum Masterne mødes to gange om ugen og giver status og følger op på afhængigheder – en lidt mærkelig tilføjelse til en rolle som ellers har mere fokus på hvordan vi gør ting end hvad vi gør. Status er mere et Product Owner-domæne i Scrum, og jeg må da også sige, at jeg endnu ikke har set værdien i disse møder… det føles snarere som dobbelt-arbejde og træden over tæerne på Product Ownerne i organisationen.
Et sted har teamsne dog mærket en forskel – vi mødes hver ottende uge (SAFe siger ellers hver tiende uge) og planlægger sammen hele afdelingen (og søsterafdelingen) inklusiv ledelsen i to dage. Bestemt en udfordring for mennesker der ikke er så sociale anlagt (eller folk som foretrækker stilhed), men også en stor forbedring af synligheden af vores fælles udfordringer og visioner (“forbedring” afhænger igen af øjnene der ser – nogen er ligeglade med det store billede). Vi har ikke faciliteter til at rumme os alle på en god måde indenfor virksomheden, så vi tager den ude i byen – hvilket bryder hverdagsfølelsen og forbedrer fokus. Den store udfordring udover støjniveauet er, at man bestemt ikke er effektiv med så mange mennesker i samme rum og det giver mange afbrydelser i planlægningsprocessen. Til gengæld har man de folk man skal bruge til at tage beslutninger i samme rum på en gang og det er effektivt. Om det opvejer den betydelige omkostning der er ved at samle folk for at planlægge i to dage er svært at sige. Det kommer nok an på hvor svært det er at få de rigtige mennesker i tale i hverdagen. Øvelsen skal dog ikke undervurderes – det er utroligt svært at se 8-10 uger ind i fremtiden og forudse hvad man kan komme ud for og hvilken koordinering der er tiltrængt. Man sætter sig nogle mål (PI-objectives) som er rare pejlemærker i hverdagen, men man kan også komme i en situation, hvor man ved efter et sprint at de opsatte mål for de næste 3-4 sprints er fejlagtige og man er nød til at lave nye.
Ovenstående er et ufiltreret kig ind i vores maskinrum og et udtryk for nogle af de udfordringer vi har haft undervejs i vores indførsel af SAFe (hvilket potentielt siger mere om os end om SAFe). Der er mange andre udfordringer (og potentiel værdiskabelse), som jeg bare ikke nåede til at nævne f.eks. Product Owner-rollens udvikling, distribuerede teams, dynamiske teams og Innovations-sprintet (IP).
Andre vil nok have andre udfordringer afhængigt af deres nuværende organisation og vilkår – skriv endelig en kommentar her, hvis du har spørgsmål eller vil tilføje noget om din egen erfaring med SAFe.
Spændende at du blogger om det.
Hvis idé er det at prøve at indføre SAFe? Hvad forventer i at få ud af det?
Jeg kender ikke til SAFe. Andet end lige at have kigget lidt på dine links.
Men når jeg læser dit blogindlæg, virker det somom at i har indført en del synkronisering, fælles møder osv. som i ikke havde før. Er det korrekt?
Det virker lidt som de modsatte af hvad vi har gjort. Vi har gjort hvad vi kan, for at højne autonomiteten. Både hos den enkelte udvikler, teamet og afdelingen. Vi har fjernet synkroniseringspunkter hvor de ikke gav mening og prøver aktivt at gøre dem unødvendige, hvis vi kan. Jeg tror personligt på, at det er den eneste måde at skalere teams og samtidig sikre at udviklingshastigheden bevares (Og sikre at det blive ved med at være sjovt at gå på arbejde – min egen lille kæphest)
Jeg mangler lidt af historikken til at kunne svare på oprindelsen til SAFe fordi jeg ikke har været med fra starten. Det jeg har hørt er at motivationen kom på grund af de kontroverser der var i snitfladen mellem en traditionel produktionsvirksomhed og en agil udviklingsafdeling. Man ville gerne løse nogle af de problemer der opstår i lagene over udviklingsafdelingen.
Det er klart at min vinkel på tingene er mindre sigende i den transition, fordi jeg ikke sidder i de lag. Jeg hører om forbedringer, såsom en mere agil tilgang til budgetlægning, en større forståelse for hvad udviklingsafdelingen rent faktisk sidder med (mindre black-box) og herunder en forståelse for hvad der er vores største impediments – hvilket formentlig løser et udsnit af de tidligere gnidninger.
I min rolle har det konkret medført mere synkronisering og fælles møder. Det har du helt ret i. Som jeg også skriver, så stiller jeg mig meget tvivlsom overfor visse møders gavnlighed mens andre er en forbedring i forhold til situationen før.
SAFe har indført en kortlægning af vores afhængigheder og koordineringspunkter og det er første skridt på vejen til at fjerne dem og i hvert fald synliggøre flaskehalse, så de kan fjernes. Det ene af mine teams var netop en flaskehals, og vi har med synliggørelsen af det mærket stor opbakning til og opprioritering af et projekt som skal løse den flaskehals og lægge mere ansvar udenfor teamet. Mit andet team er netop startet på et nyt projekt, hvor de netop har tænkt ind i arkitekturen at det skal kunne udvikles af flere teams, så de ikke bliver en flaskehals. Jeg er ikke sikker på at vi ville have haft det fokus, hvis det ikke var for SAFe.
Med hensyn til om det er sjovt at gå på arbejde, så er det svært at sige om SAFe har haft en positiv effekt – nu er det netop en af vores organisations mærkesager at være “best place to work” og sjov er en stor del af det (den slags kommer måske nemmere, når man arbejder i en legetøjsbiks), så vores udgangspunkt var ret godt :). Hvis det lykkes os at få løst de problemer som SAFe har tydeliggjort (og jeg er fortrøstningsfuld, selv om den slags altid går for langsomt) bliver det sjovere at gå på arbejde for den individuelle udvikler – så er de nemlig med minimal indsats blevet mere produktive og har oplevet at de i højere grad arbejder på det rigtige med mindre spild. At vi lige nu har indført mere spildtid for min egen rolle, tror jeg er midlertidigt. Vi er stadig i begyndelsen af transitionen og vi tilpasser udførslen hele tiden efterhånden som vi bliver klogere. Af andre roller tæt på mig kan jeg nævne Product Owneren (POen) – jeg tror næppe det er blevet sjovere at være PO hos os efter indførslen af SAFe og den er sværere at rette op på i vores tilfælde. Hvis SAFe bliver nøglen til at få omstruktureret vores organisation til noget mere hensigtsmæssigt, så bliver det også sjovere at være PO, fordi det bliver nemmere at levere og det enkelte team/PO ikke længere får ansvar for ting der ligger udenfor deres kontrol. Risks er meget mere synlige efter vi har indført SAFe og det betyder at ledelsen skal forholde sig til dem – også selv om det er accepterede risks. Den enkelte PO står mindre alene med problemerne. Måske er det faktisk på nogle punkter blevet sjovere at være PO hos os efter indførslen af SAFe.
Jeg er meget enig i at selvkørende teams og højnet autonomitet er vigtigt. Det løser bare ikke de problemer vi har haft, hvor den agile udviklingsafdeling har mødt resten af organisationen. SAFe flytter måske også bare nogle af de problemer – det er noget jeg har svært ved at se fra min egen placering i vores ret dybe organisation.
Det lyder skide godt med synliggørelse af flaskehalse. Mere af det :-). Tak fordi du deler
Enig – og tak for kommentarerne :). Er glad for enhver chance for at uddybe de uklare punkter.
Det må være noget af et projekt at give sig i gang med SAFe blot som eksperiment uden at være fast besluttet på, at det er vejen at gå. – Stærkt. Jeg finder det rigtig godt du har publiceret end blog indtastning ang. dette eftersom ikke så mange andre, har gjort dette og kunne jeg finde noget, har det langt fra været brugbart til noget som helst. Virker til de også har set SAFe som den bedste mulighed for at samle mange tråde et sted. Plus nu har jeg fået mere indblik i, hvad Scrum Master vil sige, tak herfra.
Hvordan blev SAFe rullet ud i jeres organisation, blev de forskellige aktører uddannet i SAFe inden jeres første ART launch?