Skalering af agilitet er et populært emne. Især DAD, LeSS og SAFe forsøger at give svar på hvordan store virksomheder kan komme med på den “agile” vogn. En ting er dog lidt overset; Er I sikre på at I er nød til at skalere?
Lad mig uddybe. Du har en stor IT-organisation, men arbejder alle IT-folkene sammen? Arbejder de på samme produkt? Kunne du (eller din chef) flytte nogle teams ud i en anden afdeling uden det ville påvirke det daglige arbejde på produktionsniveau (ledelsesperspektivet ville være anderledes, men ville det daglige arbejde for IT-folkene?)? Det største problem som skalering af agile forsøger at løse er koordinering af arbejde mellem teams, men hvis der ikke er brug for sådan en koordinering, så er det skønne spildte kræfter.
Hvor mange har ikke stået til et Scrum-of-Scrums og tænkt “hvorfor skal jeg have denne viden?” “hvad kommer det mig ved?” (altså helt reelt og ikke bare for at være på tværs). Det sker ofte, når man forsøger at koordinere ikke-relaterede teams. Den gode nyhed er at hvis man har stået i sådan en frustrerende situation, så er der måske et let svar; lad være med at skalere og koordinere. Scrum bygger på samarbejde og hvis der ikke er brug for samarbejde, så lad være med at tvinge det igennem. Der kan stadig være brug for koordinering, men mere på niveau med den koordinering I ville lave med teams udenfor virksomheden – a la de melder ud hvornår noget nyt er på trapperne i deres produkt, og I står klar til at bruge det.
Jeg forsøger bestemt ikke at sige at skalering af Scrum og andre agile metoder ikke kan være nødvendigt. Der findes få store, store produkter, hvor mange, mange teams arbejder sammen ud fra den samme vision og har en høj grad af samarbejde – uden at dette store produkt kan splittes op i mindre dele som der kan arbejdes på uafhængigt. Disse produkter er bare ikke så udbredte som man skulle tro, når man ser tilslutningen til agile skaleringsmetoder.
DAD, LeSS og SAFe har stadig gode ideer som man kan have gavn af selv om man ikke skal skalere. Min erfaring kommer fra SAFe. SAFes storrums-planlægning er en fantastisk ting, hvis ledelsen føler sig afkoblet fra dagligdagen. Der findes dog andre løsninger på dette problem – er det virkelig nødvendigt at tvinge alle uafhængige teams til at planlægge sammen for at det er nemmere for dig at følge med? Med den udgift og opgivelse af fleksibilitet som det medfører? Svaret kan være ja i visse organisationer, mens andre måske kunne finde en billigere og nemmere løsning. Storrums-planlægning har også andre fordele – cheferne mødes og der er plads i deres dag til at få diskuteret de store udfordringer som går på tværs. Måske har de allerede løst dit problem et andet sted i organisationen? Sådan et møde og erfaringsudveksling er meget værdifuldt, men igen, der er andre måder at opnå det samme. Fælles frokost cheferne imellem hver anden måned kunne måske give samme resultat uden at 100+ medarbejdere skal blandes ind i løsningen.
En anden fordel jeg har set ved indførslen af SAFe, er at gøre andet end it-afdelingen mere agilt. Agil budgetlægning for eksempel. Lad være med at forsøge at se et år eller fem ind i fremtiden, hvis det ikke virker for jer. Få de store rammer på plads og find så en kadence for hvor ofte man skal mødes og aftale næste periodes budget. Måske har du brug for SAFe-indførelse for at overbevise organisationen om at det er en god ide, men ville det ikke være rart, hvis du kunne nøjes med mindre?
Jeg har før skrevet om fordele og ulemper ved SAFe, så jeg vil ikke fortsætte her, men bare konkludere at der er fornuft i disse skalerings-mekanismer, men de er dyre og måske unødvendige. Hvis man ikke har brug for samarbejde og koordinering, så er der billigere måder at opnå samme forbedringer som disse metoder tilbyder og potentiale for at undgå nogle af ulemperne.
Hvis man er i den heldige situation i en stor virksomhed at skalering ikke er nødvendigt, hvad er så mulighederne? Mit svar; autonome arbejdsgrupper som f.eks. Spotifys squads, tribes og guilds. Forretningen og IT samarbejder – mod et fælles mål. Tænk på denne enhed som en forretning i forretningen. Giv den arbejdsro, budget og folk til at opnå målet. Split ud frem for at samle løst koblede teams.
Skalering er dyrt og besværligt, så vær glad, hvis du ikke har brug for det.
Amen!
Hørt, og man kan jo designe sin arkitektur(software,hardware og organisation) så det ikke er nødvendigt at arbejde så tæt sammen. Da jeg studerede synes jeg høj samhørighed og lav kobling var lidt trivielt, men det er jo i virkeligheden det, det hele handler om 🙂
Jo højere omkostninger der er ved samarbejde mellem to organisatoriske enheder (kulturforskelle, fysiske afstand osv.) jo lavere kobling skal der være mellem de to enheders arbejde.
Jep. Conway’s law. Din arkitektur kommer til at afspejle din organisation – eller omvendt. Endnu en grund til at der er meget at vinde ved at splitte monolitter op i organisationen og i koden.