Dette indlæg er alene udtryk for skribentens egen holdning.

Skal De også have en SAFe? Fortidens skygger truer

31. januar 2022 kl. 08:0915
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Mange af jer kender mig, andre gør ikke. Hvis du er i den sidste gruppe, kan jeg fortælle, at jeg har blogget her siden 2008 - i de senere år sporadisk. Det er blevet til 100+ blogposts og meget er derfor allerede sagt. Men af og til er der noget der trigger mig til endnu en tur i manegen. Og så er jeg SAFe-certificeret, en information som måske bliver nyttig når du læser nedenstående.

En af mine bekendte beklagede sig for nyligt over implementeringen af udviklingsmetoden Scaled Agile Framework (SAFe) i sin organisation. Frit efter hukommelsen blev der sagt noget i retning af, at

"Ledelsen er blevet forblændet af nogle SAFe®-certificerede trunter, der aldrig har stået i de faglige dilemmaer, vi står i hver dag, og som kun kan slå op i en bog efter nogle simple svar - svar som altid handler om proces, ikke indsigt."

Bortset fra, at jeg nødigt selv bruger det misogyne udtryk trunter, så er kernen i desperationen ikke ukendt i vores fag: Følelsen af, at metoden bliver målet i sig selv og at de svære spørgsmål gives nemme svar fra folk, der selv ikke ved bedre.

I weekenden læste jeg så, at den italienske filosof og forfatter Umberto Eco i anden sammenhæng har givet os denne indsigt:

»Visse etiske problemer er begyndt at stå klarere for mig i kraft af mine overvejelser om nogle semantiske spørgsmål – og du skal ikke tage dig af, at der er nogle, der siger, at vi taler for svært. De er muligvis blevet opfordret til at tænke alt for nemt af massemediernes ’åbenbaring’, som pr. definition altid er forudsigelig. De må lære at tænke svært, for hverken det gådefulde eller det åbenlyse er nemt.«

Nu kan SAFe ikke siges at være svaret på et etisk problem, men opfordringen til at tænke svært ramte en nerve hos mig: SAFe lyder nemt og kan formidles nemt, men hvis det ikke tænkes svært, kan det gå galt. For SAFe forsøger at løse en kompleks problemstilling og dér hjælper nemme svar ikke.

Artiklen fortsætter efter annoncen

Jeg er ikke stødt på systematiske studier af effekten af at bruge SAFe, vi er nok for tidligt ude til det. Men måske kan vi - også i denne sammenhæng - lære af fortiden.

Lad os derfor skrue tiden tilbage til dengang, en metode til udvikling af systemer var blevet meget populær: Den var moderne, den var hypet for sine gode resultater og transparens, ledelserne implementerede den i stor stil og den var nem at blive certificeret i. Kan du også huske, da Prince2 var hot?

Den årligt tilbagevendende publikation "IT i Praksis" kom i 2010 med en tankevækkende observation. Hvis du ikke kender IT i Praksis, så er den baseret på ret store spørgeskemaer til ca 200 statslige myndigheder, hvor de bliver inddelt i tre grupper, baseret på hvor meget, de får ud af deres it-investeringer: En best-practise gruppe, en mellemgruppe og en worst practise-gruppe.

På det tidspunkt havde Prince2-hypen varet nogle år. De statslige myndigheder, der rapporterede at anvende Prince2 som projektledelsesmetode, var til manges overraskelse overrepræsenteret i worst-practise kategorien. Udbredelsen af Prince2 blandt best practise-myndighederne lå på 33 % mens metoden blev brugt af flere end 80 % af myndighederne i worst practise gruppen. (Kilde: IT i Praksis fra 2010)

Artiklen fortsætter efter annoncen

Det var et tankevækkende faktum. Konklusionen var selvfølgelig ikke, at brugen af Prince2 gør en statslig myndighed dårligere til at udvikle it-projekter end den ville være uden en egentlig metode. Konklusionen var snarere, at et ensidigt fokus på modellen ikke kan erstatte den nødvendige it-faglighed til vellykket at kunne gennemføre et it-projekt .

Tilbage til 2022 og SAFe - og til dig, kære læser. Kunne det være, at vi er i samme situation med SAFe som vi var med Prince2 dengang? Er SAFe blevet til mere bog end ide?

Og ikke mindst: Hvordan kan vi undgå faldgruberne og gøre det bedre, når vi skal udvikle store it-systemer?

Del dine war-stories nedefor. Hvis du ikke har lyst til at fortælle med navns nævnelse, så skriv til min private email, p.norregaard hos gmail.com Jeg vil anonymisere og samle inputtet sammen i kommentarsporet nedenfor eller i en senere blogpost.

(For at holde kommentar-feltet relevant, så lad helst være med at bruge krudt på at kritisere vandfaldsmetoden, den er der alligevel ingen, som stadigt for alvor tror på. )

15 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
15
9. marts 2022 kl. 14:47

Det er de grundlæggende paradigmer der blev glemt, da organisationerne tog agile til sig.

14
9. marts 2022 kl. 13:51

Markedet for SCRUM-certificeringer, -coaching osv. var mættet så det var nødvendigt at brygge noget nyt på så møllen kunne startes forfra

13
9. marts 2022 kl. 10:37

Men er det så SAFe eller de grundlæggende paradigmer bag Scrum der er kilden til frustration her?

Jeg har en masse erfaring med Scrum, ingen erfaring med SAFe og er mest bekymret for at SAFe tager noget godt og gør det til noget bureaukratisk rod.

12
3. februar 2022 kl. 11:34

@Peter Nørregaard, det er vel en kombination, men i min optik er det metoden SAFe som er det største problem. Vi udviklede en datawarehouseløsning og jeg oplevede det som om hvert team fik en scrummastrer og en product owner tilknyttet, dertil en rte og en product manager på tog-niveau, og forretningen fik tilsvarende deres product-owner/manager something (husker ikke helt hvad de blev kaldt). Frameworket ligger op til, at der skal bruges rigtig mange ressourcer på et "mellem-ledelse" niveau, men jeg synes ikke, at det giver tilsvarende værdi.

SAFe ligger op til at forretingen taler med udviklerne gennem PO'erne. Det stiller store krav til deres tekniske indsigt. På den positive side skærmer det udviklerne for krydspresset, når flere fra forretningen gerne vil have løst deres udviklingsønsker først, men omvendt kommer udviklerne også længere væk fra forretningen, og for nogen er det den relation, som driver dem.

Vi havde i straten lidt udfordringer med at velocity (hvor meget udvikling der kan leveres) blev opgjort på team-niveau, og at vi tog opgaver ind efter teamet's velocity, hvilket resulterede i at nogle udviklere i teamet havde for meget at se til og andre havde for lidt fordi teammedlemmerne har forskellige kompetencer. Jeg husker det sådan, at alle teams i toget skal kunne læse alle opgaver, hvilket betyder at teams'ne skal være full-stacked, men det betyder, at udviklerne i teamet ikke bare kan løse alle opgaver, som teamet tager ind. Det problem fik vi selvfølgelig løst hurtigt, og jeg er ikke sikker på om det var metode eller implementeringen som var årsag til problemet.

Det er nu flere år siden jeg arbejdede med SAFe, og alle begreber/opgaver står ikke helt skarpt i hukommelsen mere.

11
1. februar 2022 kl. 13:12

Har været på en rejse hvor udfordringerne med process ændringer springer i øjene.

SAFe udrulles over en hel virksomhed, men personer har jo forskelligt insigt og erfaring dette lukkes inde i dele af SAFe. Disse personer støder så lejlighedsvis ind i hinanden og der opstår en del nyopdagede udfordringer.

En lille bestandel af SAFe som glemmes i salgstalen er Scrum. Fokus er meget på SAFe/Lean elementerne end scrum/agil. Sjovt når det er basis for udviklingsmodellen, men måske fordi SAFe udspringer af RUP. Tror fokus på SAFe er på udrulning fra ledelsen og ned og det gør implementeringerne minder om modeller før det agile manifest...

Er der nogen der er stødt på en SAFe implementering hvor forretningsmål er alignet 100% med leverancern? Syntes modellen skaber mere afstand fra forretning til udviklingen.

10
1. februar 2022 kl. 12:20

Proces værktøjer må kun være støttehjul for en organisation.

Støttehjul er gode når man lærer, men farligt meget i vejen, når man skal til at køre stærkt.

9
31. januar 2022 kl. 17:42

Uanset hvilken overordnet metode man vælger at benytte, så er det vigtist at man vælger den rette metode i forhold til den opgave man skal løse.

En af de ting der kan ødelægge ethvert projekt er hvis der er for mange ledelseslag, og hvis den øverste ledelse absolut skal godkende hvert eneste beslutning. Ind i mellem er den bedste løsning at den øverste ledelse overgiver eller lader, de enkelte mindre hold at tage den endelige beslutning.

Og til sidste er der jo "hold det simpelt" princippet, eller på engelsk "KISS" Der er trods alt stor forskel på at bygge en bro, et højhus, en træhytte, eller en traditionel bygning i mursten.

8
31. januar 2022 kl. 15:30

Torben, er det etproblem med metoden eller med implementeringen, i din optik? Det kunne være spændende at høre om

7
31. januar 2022 kl. 14:15

...at conways lov ikke er helt ved siden af.

"Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure".

Alene det man vælger SAFe som "rammeværk" har vel allerede sagt noget om hvilken organisation man arbejder med. Ligesom hvis man valgte Prince2.

Fordi det at bygge software, er i mange virksomheder en relativ stor udfordring. Derfor kræver det, er min fattige erfaring, at man kigger på hvordan man er strukturet som organisation. Og det er det jeg mener conway siger i hans citat ovenover.

Jo flere som skal danne konsensus jo længere tid tager det, det siger sig selv. Og jo længere tid det tager, jo kortere tid har man til, at kunne tage fejl. Hvis man ikke kan organiserer sig i et enkelt team så kommer man aldrig nogensinde til, at kunne organisere sig på tværs af teams.

Det med at dele ansvaret op og give flere men mindre teams mulighed for, at tage beslutninger på baggrund af forretnings behov, er en valid og absolut gangbar løsning.

6
31. januar 2022 kl. 12:51

Claus Bobjerg siger: "Uden procesforståelse sættes der bare strøm til manuel proces uden at højne genvinsten ved digitalisering."

Dette er jeg ret enig i. Problemet er, at dette ofte er målet med digitaliserings-opgaven: Lav det vi plejer med digitale virkemidler.

Der var engang (15 år siden?) nogen, der foreslog, at man ikke skulle lave individuelt tilpassede programmer til en virksomheds informations-struktur og arbejds-processer. Man skulle istedet ændre virksomhedens vaner, så de passede med tilgængelige programmer.

Dette var naturligvis en voldsom provokation, som desværre ikke gav den revolution, den burde have skabt. Men det er da lidt sjovt, at Microsoft og Google i virkeligheden er kommet ret godt ud ad det spor - at virksomheder tilrettelægger deres interne rutiner, så det passer med de valgte værktøjer (f.eks. Office 365).

5
31. januar 2022 kl. 11:54

it-faglighed til vellykket at kunne gennemføre et it-projekt .

Hvilke it-projekter? implementering af fx IDM eller tilsvarende?

Digitalisering af (kerne)forretningsprocesser er ikke IT-projekter, men er forretningsprojekter.

Digitalisering af forretningsprocesser kræver både it-faglighed men kræver også forretningsforståelse, herunder procesforståelse.

Uden procesforståelse sættes der bare strøm til manuel proces uden at højne genvinsten ved digitalisering.

4
31. januar 2022 kl. 11:47

SAFe som kommer i centrum og ikke udvikling til gavn for forretningen.

Taler vi her it-udvikling til gavn for forretningen eller noget andet?

Optimalt set burde det være sådan, at virksomheden sætter et mål for hvor de skal hen, kerneforretningen fastsætter hvordan man skal komme til målet, herunder hvem der skal understøtte med hvad. De understøttende funktioner hjælper efter bedste evne.

Der er mange forudsætninger, fx. at kerneforretningen ved hvordan de vil have fx IT både som teknologi og som afdeling, til at understøtte, og hermed sagt at kerneforretningen er modne til opgaven. Hver enkel afdeling skal så igennem samme proces for eget område.

Et hvert værktøj, fx SAFe eller Prince2 kan være en måde at højne modenheden i virksomheden til at når ovenstående, men omvendt kan et hvert værktøj også være "forkert" hvis værktøjet ikke føre virksomheden i den retning som virksomhedsledelsen har valgt at man skal eller hvis virksomhedsledelsen ikke har fastsat en retning.

3
31. januar 2022 kl. 11:35

Hvor er jeg enig:

"Konklusionen var snarere, at et ensidigt fokus på modellen ikke kan erstatte den nødvendige it-faglighed til vellykket at kunne gennemføre et it-projekt ."

Det samme skal man overveje omkring Half Double.

2
31. januar 2022 kl. 11:02

Har arbejdet med SAFe ca 3 år og det kom ikke til at virke. Det kræver alt for mange høvdinge, og det hæmmer udviklingen og dialogen. Tanken bag SAFe virker udtroligt lokkende, men det ender med at det bliver SAFe som kommer i centrum og ikke udvikling til gavn for forretningen.

1
31. januar 2022 kl. 08:55

Problemet er nok at alle har forskellige måder at angribe problemer på.

Personen der kom med udtalelsen

"Ledelsen er blevet forblændet af nogle SAFe®-ce

Har sikkert haft stor indsigt i det faglige, men har måske ikke fat indsigt i hvilken indsigt hans/hendes kollegaere har haft og hvilket niveau af indsigt det ville kræve at nå til et højere modenhedsniveau som organisation og hvordan man som virksomhed når dette niveau.

Kort sagt for at ændre en virksomhedskultur kræver det en proces der skaber indsigt.