Martin Ernst bloghoved

Er man safe med SAFe, eller kommer man kun halvt i mål?

Illustration: Concor

Denne blog er inspireret af, at jeg var blevet inviteret ud til et SAFe meetup møde arrangeret af en af mine gode samarbejdspartnere. Jeg kunne forstå, at jeg skulle føle mig heldig blot at få lov til at komme med, da dette møde hurtigt blev overbooket. Der var plads til 90 (gamle Ole), men efterspørgslen var så stor, at en venteliste hurtigt var en realitet.

”Det har været helt overvældende og viser, at timingen er rigtig. Virksomhederne har nu noget erfaring, og det vil de gerne videndele omkring”, siger Karina Nordvig Davids, Markedschef hos Concor. Indtryk fra dagen kan ses her. Der var indlæg fra PFA, Human Univerz, Simcorp og Ørsted.

Metoden er sekundær (av, den er ikke god, hvis man skal være ven med evangelisterne…?)

Jeg må indrømme, at en enkelt leverancemetode ikke kan bringe mit pis i kog. Jeg tager det som passer til virkeligheden. Måske fordi jeg typisk aldrig få lov til at starte et projekt op, men overtager efter andre, som har givet op. Dermed overtager jeg også den (i organisationen eller situationen) valgte ”strategi” eller metode – dvs. implementeringsmetoden eller rammeværket. Der er sjældent mulighed for at ændre radikalt i fremgangsmåden. Således står jeg med en ”arv”, som jeg må se på som et vilkår; der kan kun tunes og forbedres inden for ”rammen”.

Denne holdning betyder nok, at jeg vil få det meste af SAFe verdens ”followers” på nakken. For ikke at tale om evangelisterne. Plejer man ikke at sige, at man ikke kan diskutere med ”fanatikere og fulde folk”? I hvert fald fik jeg for nogle år siden ikke en opgave, da jeg ikke kunne recitere samtlige SAFe udtryk fra hoften over for en tydeligvis ”konvertit” (for at bruge Poul Henning Kamps udtryk). Den fejl kunne jeg nok have begået uanset om jeg havde en certificering eller ej.

Set ud fra en business case og gevinstrealiseringssynsvinkel (som altid er min vinkel), så er jeg hamrende ligeglad med om den understøttende enabler (IT, bro, tog, processer etc.) bliver fremstillet via en vandfaldsmetode, agil udvikling, pølsemaskine, tryllekunster, mesterbager, papir/saks etc.

Det jeg er mest interesseret i er, hvornår vi får enableren med dens nye funktioner, og om vi kan sikre den tilhørende adfærdsændring, så vi kan høste gevinsterne. Her er leverancesikkerhed essentiel. Vi skal have den rette scope i den rette kvalitet til den rette tid. Ellers vil interessenterne ikke bruge enableren – og gevinsterne udebliver. Så dør baby!

Jeg vil våge den påstand, at jeg har set lige så mange vandfaldsprojekter som agile projekter fejle i middelsvær grad, så hele business casen bliver udvandet, som en mojito udvandes efterhånden som isen i drinken smelter. Tilbage er kun en tynd drink, som man lige så godt kan skylle ud.

Hvorfor?

Hvorfor sker dette? Her er svaret lige så svært som spørgsmålet ”hvad er meningen med livet”?
For at fokusere igen på SAFe, så har vi et rammeværk og en metode, som vi har set det i forbindelse med PRINCE2, MSP, PMI, ITEL, EA (rammeværker i forskellige afskygninger) etc.

Dvs. vi har to generelle problemer her:
1) Vi kan være enig i rammeværkets indhold/metode og
2) Vi fejler ved ikke at implementere rammeværket helt.

Ad 1) SAFe er kendetegnet ved at tage det agile manifest og tilføje en programledelses governance m.m. Modstandere vil påstå, at man derved er gået helt væk fra det oprindelige agile manifest – og dermed er man slet ikke agil. Lidt frisk kan man sammenligne dette med, at bitcoins blev styret af en nationalbank. Væk er det autonome, da en central enhed har taget kontrollen. Min erfaring er, at man bliver nødt til at styre store projekter centralt – og der kan man ikke komme uden om rammeværker som SAFe, hvis man forsat vil lugte lidt af den agile tankegang, men have en central styring.

Ad 2) Det er set 1000 gange i historien, at governance processer ikke bliver implementeret ordentligt - eller værre endnu - sander til i ”hvordan vi gjorde før, vi fik indsæt her selv den metode, som I selv har implementeret". Det nytter ikke noget, at en CxO siger, at vi skal være agile, når det så ikke bliver en gennemsyret tankegang i hele organisationen – eller det bare helt generelt er implementeret forkert. En ikke korrekt brug bliver af Martin Fowler kaldet ”faux-agile” og af Ron Jeffers kaldet ”Dark Scrum”. Jeg er ligeglad - ud fra en business case synsvinkel, hvad man implementerer – bare man ikke gør det halvt! Vi skal have effektive implementeringsmetoder, tak! Forandringsledelse er vigtigt med alt, hvad det inkluderer.

So ein Ding

Det er nok pga. disse to problemstillinger, dette SAFe meet-up arrangement fik luft under vingerne.
Direktøren var kommet tilbage på kontoret efter at have hørt på golfbanen eller på et ERFA-møde, at naboen var blevet agil – og tænker; so ein Ding muss Ich auch haben. Det minder lidt om, når nogen implementerer ERP og vælger SAP, eller man skal have en Tesla. Alle skal have det! Selv kronprinsen fik en. Som min datter på 2½ år argumenterer for en vilkårlig ting: ”Fordi bare!”.

Men så står organisationen tilbage med 1000 spørgsmål. Alle de spørgsmål håber man at få svar på ved dette arrangement. Og det er helt tydeligt, at det arrangement må falde på et tørt sted. Igen med reference til ventelisten.
Hvad var så hovedpointerne fra arrangementet?

Det fik jeg en god snak med Tim Pedersen fra Pace om, som jeg kan forstå er et kendt ansigt indenfor SAFe verden.
Tims første pointe er at SAFe’s succes skyldes bl.a. at rammeværket giver virksomhederne en mulighed for den centrale styring – og netop det kan direktøren se sig selv i. Når direktøren – dvs. sponsor – kan se idéen i det, så bliver det automatisk en mere attraktiv metode, end andre agile rammeværktøjer, som findes derude.

Tims anden pointe er netop det, som jeg har være inden på tidligere, at dette skal implementeres ordentligt. Og det er ikke nem øvelse, og kræver mange ressourcer. Det er også en øvelse, hvor implementeringens ”succes” eller fremdrift hele tiden skal vurderes mht. at finde ud af, hvor man nu skal sætte ind for at få en endnu bedre implementering eller forankring, om man vil. Specielt dette punkt blev adresseret på SAFe meetup mødet, da alle på mødet var meget åbne omkring deres udfordringer. Alle stod så at sige med samme svære udfordring. Igen forandringsledelse er vigtigt, da SAFe fordrer en kulturforandring.

Tim og jeg var også meget enige om, at SAFe er et fint rammeværk, men det har også sine begrænsninger pga. den størrelse af programmer, som rammeværket er bygget til. I nogle tilfælde kan andre rammeværk have et bedre ”fit”. Så vi er ikke blevet helt evangelister – nok mere agnostiker ud i metoder og rammeværker. Men vi kan da se øjeblikke af skønhed i SAFe.

Uanset, så bliver SAFe Meet-up arrangementerne spændende at følge. Altså hvis jeg får lov efter at have postet denne blog :-). Man ved aldrig med de fanatikeres syn på en agnostiker som mig ;-).

Det næste møde er den 22. januar 2019 hos Ørsted. Tilmeldingen åbnes den 10. dec. kl. 10. … stay tuned. Der bliver sikkert rift om pladserne.

Kommentarer (6)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Olav M.J. Christiansen Blogger

'Safe at any speed' er titlen på en science fiction novelle af Larry Niven, og jeg tror desværre også at meget af SAFe er det rene science fiction :-)

Tak for dine beretninger fra arrangementet, Martin. Som du kommer jeg tit ind i et projekt på et tidspunkt, hvor metoderne og teknologien ligger ret fast. Så er det man bliver nødt til at trylle indenfor de muligheder, der nu er. Og Business Casen er selvfølgelig en af styringsmekanismerne (men forhåbentlig ikke den eneste).

Jeg er selv ret skeptisk mht. SAFe af flere grunde, men måske især fordi begrebet indeholder ordene 'Agile' og 'Framework' i samme sætning.

I et tidligere blog-indlæg har jeg efterlyst praktiske erfaringer med brug af SAFe, men der er ikke kommet meget endnu. Jeg kunne virkelig godt tænke mig at høre mere om hvad folks erfaringer med det er (dvs. erfaringer fra folk, som selv har prøvet det - ikke fra folk som forsøger at sælge det).

Martin J. Ernst Blogger

I et tidligere blog-indlæg har jeg efterlyst praktiske erfaringer med brug af SAFe, men der er ikke kommet meget endnu. Jeg kunne virkelig godt tænke mig at høre mere om hvad folks erfaringer med det er (dvs. erfaringer fra folk, som selv har prøvet det - ikke fra folk som forsøger at sælge det).

Så syntes jeg faktisk, at du skal forsøge at komme til det næste arrangement. Her bliver der delt ud af praktiske erfaringer med implementeringerne. Både PFA, Ørsted et al. var meget åbne om hvor langt det var kommet, og hvilke udfordringer de stod overfor.

Olav M.J. Christiansen Blogger

Kan du sætte nogen ord på hvorfor du ser det som noget specielt problematisk? Jeg kan ikke se at Agile skulle være fortaler for et fravær af strukturerede metoder og processer.

Tja, jeg kan da henvise til det agile manifest, hvor der bl.a. står:
"Individuals and interactions over processes and tools"

Jeg kan ikke se at det kæmpestore framework, der f.eks. vises på forsiden af
https://www.scaledagileframework.com/ antyder dette.

Uden at kende SAFe i de store detaljer (jeg har kun været til nogle få foredrag/seminarer om det og ikke selv benyttet det i praksis) vil jeg egentlig ikke udtale mig om hvor anvendeligt det er. Men jeg er ikke sikker på at det kan tillade sig at kalde sig 'agilt'.

Anders Frandsen

Det betyder jo ikke at man helt skal undvære processer:) Jeg tror mere der er tale om at man har sat op til at have en smule mere proces, i henblik på at få resten af organisationen omkring ens udviklingsafdeling med. Jeg sidder selv i noget Safe inspireret struktur til daglig, og min umiddelbare opfattelse er i hvert fald ikke at det er dér skoen trykker. Selvfølgelig lidt en "eye of the beholder" ting.

Martin Ørding-Thomsen

Tja, jeg kan da henvise til det agile manifest, hvor der bl.a. står:
"Individuals and interactions over processes and tools"


At et projekt kører agilt betyder først og fremmest at man kører det iterativt, dels så man kan ændre retning efterhånden som man bliver klogere og dels så man kan tage det i brug før det hele er færdigt.

Individuals and interactions over processes and tools er bare en ud af flere måder at komme derhen. At lægge et rammeværk med nogle veldefinerede processer ned over det er en anden måde, og den har vist sig at fungere rigtigt godt. Når man har et projekt med 20-30 scrum teams er der nødt til at være en fast struktur for hvordan man koordinerer afhængigheder, arbejder i samme retning osv. Taler af erfaring - har siddet hos UFST i to år og bygget på ICI (afløseren for EFI) - og der bruger vi SAFe.

Log ind eller Opret konto for at kommentere