*Denne blogpost er for dig der ønsker en grundig introduktion til Scaled Agile Framework*
Arbejder du med softwareudvikling i en stor organisation? Så giver jeg en is, hvis I ikke slås med et eller flere af disse problemer:
- Det er svært at få produkter og features ud af døren i den hastighed forretningen ønsker sig.
- Ubehagelige overraskelser er mere normen end undtagelsen i slutningen af et udviklingsforløb. I lang tid ser det ud som om alt er på sporet, indtil det pludselig ikke er tilfældet længere.
- Der er sjældent overskud til strategiske initiativer, da størstedelen af kapaciteten går til vedligeholdelse og færdiggørelse af eksisterende initiativer.
- SAFe® er et framework, som giver store organisationer en måde at høste de fordele ved agil udvikling, der længe har været forbeholdt mindre organisationer. Således kan organisationer med op til flere tusinde udviklere indføre agil udvikling og få fordele i form af bedre produktivitet, kvalitet og mere tilfredse medarbejdere og kunder.
- I deres oprindelige udformning hylder hver af de agile metoder princippet om “small is beautiful”. Man hører ofte advarsler fra agile praktiker, om at undgå at vokse over en vis størrelse som organisation. Derfor er der også kun meget begrænsede værktøjer og praksis til at håndtere skalering i disse metoder.
Min personlige erfaring med agil softwareudvikling i store projekter
I 2000-2006 var jeg som udviklingschef i SAS Institute del af et dansk team, der deltog i et stort initiativ, som involverede mange teams i USA og Danmark. I Danmark tog vi eXtreme Programming og senere Scrum i anvendelse. Vi oplevede på den ene side at det gjorde os langt hurtigere og bedre til at levere kvalitet. På den anden side var det frustrerende at se, hvor lidt det egentlig kom til at betyde for det samlede programs evne til at levere produkter.
Afhængigheder på tværs af teams, uklarheder om ansvar og opgaver og en ikke-eksisterende fælles tilgang til arkitektur var de store syndere.
Vi gjorde dog en ting, der skabte en markant forbedring på tværs af teams. Et relativt simpelt ITsystem hvor alle teams, kunne melde prioriteter og deadlines ind på tværs af programmet. Herved blev vore afhængigheder synlige, og vi indførte et ugentligt møde til at følge op og koordinere planer på en horisont på 1-2 uger. Denne forbedring var nok til, at vi med besvær kunne levere produkter, som vi tidligere næsten ikke kunne få ud af døren. Samtidig kunne vi alle se, at der stadig var et kæmpe potentiale for forbedring.
En del år senere faldt jeg tilfældigt over en artikel om “Lean Construction” og “Last Planner” – hvori forfatterne, Greg Howell og Lauri Koskela, sammenlignede agile metoder i software udvikling med lean-inspirerede metoder i byggeriet som var meget succesfulde. De fandt mange ligheder og fremfor alt konstaterede de at begge henter deres praksis fra det samme paradigme: adaptiv styring af processer.
Jeg var begejstret. I byggebranchen kan man i høj grad tale om afhængigheder, som en begrænsning man må leve med. Der er både tyngdekraften – at man ikke kan starte med at bygge 5. salen, selvom man har alle materialer til den, og der er en optimal sekvens af arbejdet, så man får færrest problemer, hvis man lægger rør inden man støber gulv, for endelig tilsidst at male.
Var der en måde at håndtere disse brutale afhængigheder på, måtte vi kunne lære noget i softwareudvikling, med vores langt mindre firkantede, men ikke desto mindre, kostbare og indtil nu svært håndterbare afhængigheder indenfor det agile paradigme.
Det førte til et mangeårigt samarbejde med Sven Bertelsen – Grand Old Man indenfor bedre metoder i byggeriet – på dansk kaldet Trimmet Byggeri, hvor vi sammen inspirerede softwarevirksomheder og elektronikvirksomheder til at bruge lean og agil tænkning i deres produktudvikling.
Vi fokuserede særligt på metoden Last Planner, som kort fortalt har 2 overordnede principper:
1. Lad de, der skal udføre arbejdet planlægge det (deraf navnet). De ved nemlig bedre end nogen andre, hvad der er muligt og hvad der skal til for at planerne kan lykkes.
2. Arbejd med 3 tidshorisonter:
Den overordnede projektplan, som først og fremmest tjener til at identificere problemer og risici og gøre afhængigheder og optimeringer synlige. Den rullende faseplan, hvor man kigger 3-6 uger ud i fremtiden. Har vi hvad der skal til? Er der problemer med leverancerne? Og endelig ugeplanen, som er en plan for hvad summen af teams (sjak – når det er byggeri) kan nå på en uge.
Det var et stort skridt fremad for mig, fordi det forklarede, hvorfor vores simple styringssystem virkede og gav mig nye værktøjer til at planlægge og styre bedre, uden at falde i fælden med centraliseret, overdetaljerede planer, som aldrig er nyttige, men derimod ofte virker stik imod hensigten, og gør det vanskeligere at gennemføre projekter.
Samtidig begyndte andre at tale om en radikalt anderledes tilgang til afhængigheder: Opløs dem, ved at samle alle de kompetencer, der er afhængigheder imellem på et team – et såkaldt featureteam. Det er særligt Craig Larmann og Bas Vodde, der har fremført dene idé, som den centrale måde at skalere agil udvikling på. En indlysende rigtig idé, som dog har nogle begrænsninger.
I en række tilfælde er feature-teams ikke nogen god idé, eller meget vanskelige at få til at fungere. For eksempel opnår man langtfra altid en god effekt ved at sætte mainframe, front-end og mobiludviklere i samme team. Der kan være så langt mellem kompetencerne, at fordelen ved at være tæt på dem man har afhængigheder til er mindre end fordelen ved at være tæt på nogen, man kan have meningsfuld faglig sparring med.
Dette er endnu tydeligere, hvis man udvikler produkter der både har software, hardware og mekanik involveret. Her er der mindst 3 faggrupper som har meget forskellig faglighed og som arbejder med meget varierende tidshorisonter. Sætter man teams sammen med den bemanding, vil det næsten altid fejle. Her må man i stedet have en tilgang, der sikrer kommunikation og synkroniseret udvikling mellem delvist specialiserede teams.
I 2013 trådte Scaled Agile så ind på scenen – i det mindste for mit vedkommende. Jeg så Dean Leffingwell, som er en af de centrale personer bag Scaled Agile Framework, fortælle om konceptet på konferencen Agile 2013 i Nashville. Han præsenterede modellen og og fortalte om de foreløbige erfaringer. Det var tydeligt for mig, at det var endnu et skridt på vejen til at håndtere en del af de problemer, der hjemsøger store softwareprojekter.
SAFe er et udbygget og velbeskrevet framework, som bl.a indeholder en strategi for selve transformationen fra en traditionel måde at arbejde på, til agil og lean udvikling. Derudover indeholder det en række strukturer, roller og ritualer, som alle vil kunne bidrage til at få teams i store programmer til at arbejde sammen på en måde, der vil give langt bedre resultater.
Kernen i Scaled Agile Framework – Introduktion til SAFe
Helt primært tager SAFe hånd om afhængigheder og lægger på samme måde som Last Planner metoden fra Lean Construction planlægning i hænderne på de der har interesse og viden om det, der skal planlægges.
Det gøres ved identificere det team af teams, der arbejder sammen mod et fælles mål: Et **Agile Release Train** (undskyld mit denglish) – og at definere de aktiviteter der finder sted i dette team.
Kernen er at skabe mulighed for at planlægge sammen. Der er med 8-10 ugers mellemrum en 2 dages planlægnings aktivitet, hvor alle i programmet arbejder sammen om at planlægge aktiviteterne for det næste **Program Increment (PI).**
Disse to dage afsluttes med mål for den kommende periode, en risikovurdering og måling af planens troværdighed.
I hverdagen arbejder alle involverede teams i synkroniserede sprints, dog med nogle afvigelser: Udover team og sprint demoer, laver man fælles system demoer, som viser færdige features, der er summen af mange teams samarbejde. Der er ligeledes tværgående aktiviteter – Scrum-of Scrums for både scrum masters, og Product Owners, som anvendes til problemløsning og koordinering mellem teams.
Dette er der også i hver arbejdsopgave, som ikke har deres oprindelse i forretningsmæssige mål, men som har til formål at holde arkitekturen i en tilstand, som muliggør smertefri udvikling af fremtidige features. Det kalder man i SAFe en **Architectural Runway**
Ved afslutningen af et PI, laves en fælles demo og et struktureret problemløsnings retrospektiv, som sikrer at udfordringer der rækker på tværs af programmet blive adresseret globalt og ikke bare lokalt i det enkelte team.
Agil på 3 niveauer
Rammeværket Scaled Agile Framework adskiller sig fra andre metoder, ved meget eksplicit at forholde sig til sammenhængen mellem strategiske mål og den praktiske udførelse i teams og teams af teams.
Således indfører SAFe agilitet på 3 niveauer:
• Team: Her arbejder selvorganiserende teams sammen i et Scrum/XP setup med fokus på kvalitet og samarbejde.
• Program niveau: Her er aktiviteter, der foregår på tværs af team for et eller flere ART’s. Der er også personer dedikeret til koordination på dette niveau, ligesom der er funktioner, der betjener hele ART’en og ikke kun det enkelte team.
• Portfolio: Også på dette niveau, styres der efter en agil proces, der fremfor alt sikrer at der kun arbejdes med et begrænset antal samtidige ting, så man derved undgår, at der startes flere ting, end det er muligt at få udviklet. Ved at styre portfolioen i en agil proces, der hænger sammen med den måde resten af organisationen arbejder på, opnås både fleksibilitet og overblik.
Billede: SAFe Big picture (Vær opmærksom på at der er kommet et opdateret SAFe Big picture version 6.0, Du kan se SAFe 6.0 big picture på Scaled Agile s hjemmeside)
Implementering af Scaled Agile Frwamework i organisationen
Det er ikke nødvendigt at foretage en større re-organisering for at kunne implementere SAFe.
Kernen i en SAFe implementering er identifikation af et eller flere agile release teams (ART’s) og lader dem planlægge og eksekvere program increments (PI’s) sammen.
De funktionelle siloer, der i traditionel softwareudvikling har den væsentlige bivirkning at sinke processer fra start til slut, betyder langt mindre når man lader folk arbejde sammen på tværs af siloerne.
Således vil arbejdet i praksis blive udført i selvorganiserende multifunktionelle teams, hvor som minimum udvikling, test og produkt ejerskab er lokaliseret i teamet. Andre funktioner f.eks UX eller DEVOPS, vil man i nogen tilfælde placere i de enkelte teams og i andre vil det være en funktion der er delt mellem flere teams.
De enkelte teams kan enten sammensættes feature teams eller komponent teams. SAFe anbefaler ikke, at man har en organisering med kun komponent teams, da feature teams som regel er mere effektive, men i praksis har man ofte en blanding. Helt centralt er synliggørelse og minimering af afhængigheder, som der altid er masser af.
Der er også nogle vigtige funktioner, som er designet til at gå på tværs af de enkelte teams, og derved sikre koordination og konsistens. Der er dels tale om rollen som RTE (Release Train Engineer) der bedst kan beskrives som scrum master for helt ART’en, dels rollen som System Arkitekt. En system arkitekt i SAFe har et meget praktisk orienteret ansvarsområde: At sørge for kvaliteten af “The Architectural Runway”, som kort fortalt går ud på at systemet hele tiden er i en tilstand, så man kan implementere de features der er prioriteret, uden af skulle igennem kostbart, uplanlagt redesign.
Ledelsens rolle
I SAFe har ledelsen en veldefineret rolle i den agile proces, hvorved virkeligheden på direktionsgangen og virkeligheden i udviklings- eller IT-afdelingen kommer til at udgøre et sammenhængende hele. Der er en veldefineret vej fra strategiske initiativer til konkrete features og produkter og der er synlighed af metrikker og rapportering, der er relevant i en agil kontekst og som tilfredsstiller behovene for gennemsigtighed og overblik.
Det er en vigtig opgave for ledelsen at sikre at beslutninger træffes på de rette niveauer. I de allerfleste virksomheder kan langt flere beslutninger træffes decentralt. Beslutninger der har potentiel effekt udover det enkelte team, skal træffes på et højere niveau, end beslutninger med knap så vidtrækkende konsekvenser. Teams skal gives forudsætninger og værktøjer til at kunne træffe de nødvendige beslutninger. Således vil en implementation af SAFe føre til en øget klarhed over, hvad der kan besluttes hvor, med flere beslutninger overladt til de enkelte teams.
Som en del af implementeringen bliver alle involverede i programmet og transformationen – inklusive ledelsen, uddannede i SAFe’s grundelementer. Derved undgås det ofte scenarie at man indfører agil udvikling i en virksomhed, uden at ledelsen har forstået, hvordan det agile paradigme adskiller sig fra den traditionelle måde at arbejde på. Det kan medføre nogle unødvendige spændinger og frustrationer, og kan i værste fald være en medvirkende årsag til, at den agile transformation fejler.
SAFe er ikke en spændetrøje og der er rigtig mange måder at implementere SAFe rammeværket på, men der er dog nogle ting der altid går igen:
- Træning af alle der indgår i initiativet fra ledelse til medarbejdere
- Identifikation og opstart af et eller flere Agile Release Trains
- Det første Program increment, inklusive 2 dages fælles planlægning, system demoer, Scrum of Scrums og et Program Increment, afslutning med fælles Demo og problemløsning.