Jeg har netop har læst en top-interessant artikel af Jan Wischweh. Den handler om “The agile crisis” og blev offentliggjort på Medium.

Artiklen af Jan W. er krydret med en række citater fra agile sværvægtere, bla. nogle af dem, der i sin tid underskrev det agile manifest. Her er to af de citater, som jeg er vildest med. De er af Robert C. “Uncle Bob” Martin:

1. “An efficient business discipline coupled to an undisciplined engineering team will very rapidly make a mess”

2. “An Agile team will be Agile no matter how the project is managed. On the other hand, a team that is not Agile will not become Agile simply by virtue of a new and fancy project management strategy”

Er det ikke bare rigtigt?

Hvor tit har man ikke set at fokus ift. IT-projekter nærmest kun har været på projektlederen og projektmetoden? F.eks. PRINCE2, PMI eller hvis vi er i den agile verden (der er jeg selv mest) så Scrum?

Tager vi Scrum, så er man tit mest optaget af, om man pænt afholder de Scrum-møder, man skal. Pænt udnævner en Scrum Master og en Product Owner, og i det hele taget kører ”mekanikken” slavisk.

Men, spørger jeg bare, hvad med de værdier og det mindset, der ligger i Scrum, og som primært ligger på IT-udviklernes skuldre? Jeg nævner i flæng:

• Technical excellence!
• Respekt
• Kundefokus – ja faktisk bare fokus
• Åbenhed
• Commitment – f.eks. til et sprintmål
• Ansvarstagen
• Transparens

Benhård prioritering baseret på værdi er også mega-vigtig. Her kommer Product Owneren og det meget elastiske begreb, ”forretningen” også ind i billedet.

Og skulle man lige i forbifarten nævne ledelsen, som jo helst skulle understøtte deres Scrum teams, og give Product Owneren mandat til at træffe bl.a. prioriteringsbeslutninger?

Alt dette handler om, hvordan værdier, mindset, kultur og alt det bløde i det hele taget spiller ind, når man skal have et framework som Scrum til at fungere.

Fik jeg sagt, at jeg er glad for Scrum og underviser i det?

Ingen metode kan redde en skidt kultur eller dårlig adfærd

Men – og nu kommer den ubehagelige sandhed – mekanikken er i bund og grund ligegyldig, hvis det er det eneste, man håndhæver. En halvfundamentalistisk øvelse bare for øvelsens skyld bringer nul agilitet. Dette synspunkt understøttes så fint af de 2 citater af ”Uncle Bob” ovenfor.

Kunne vi ikke snart få lidt mere fokus på udvikler- og ledelsesadfærd, når nu det er det allervigtigste, hvis man vil have damp under de agile kedler?

Jeg har i flere år været dybt irriteret på de Scrum-religiøse, der holder stædigt fast i, at hvis Scrum ikke virker, så er det fordi ”man gør Scrum FORKERT”. Det er noget sludder. Scrum kan bare ikke virke alle steder. Det kan SAFe forresten heller ikke.

I begge tilfælde skal der være nogle forudsætninger til stede.

Her er de vigtigste forhold, som afgør, om Scrum og/eller SAFe er en realistisk mulighed:

• Forandringsparathed
• Modenhed
• Kompetenceniveau
• Organisationsstruktur
• Kultur
• (Ledelses)adfærd
• Processer
• Typen af opgaver og diversiteten
• Vedholdenhed
• Kvalitetsbevidsthed

Jeg elsker ”agile”, jeg har absolut set det virke, men det er ikke nemt. ”Agile” er i høj grad en ”mennesketing” og det er en stor forandring at skulle bevæge sig i en mere agil retning, hvis man slet ikke er det i forvejen.

Afgør man, at organisatorisk agilitet er en realistisk mulighed, der er værd at forfølge, så skal man også grundigt undersøge hvilken agil vej, man skal vælge. Konteksten bør afgøre det. Selvom man gerne vil være mere agile, så er der, alt efter konklusionen på ovenstående punkter, mere eller mindre frit slag i den agile bolledej.

En “one-size-fits-all” metode findes ikke. Et ”easy fix” findes heller ikke, men hvis man gerne vil den letteste (og billigste) vej, så er der nogle metoder og frameworks, man skal gå i en stor bue udenom. Også selvom de er populære og det, ”de andre gør”. Det betaler sig at undgå den agile lemmingeffekt.

Det eneste, som jeg, ud fra lang, praktisk erfaring (og min faglige stolthed i behold) tør anbefale overalt, hvor man laver videnarbejde, er Kanban-metoden. Den tænker i systemer, styrer aktiviteter og optioner, og optimerer gennemløbstider (aka flow).

Man kan starte småt, og så gør man Kanban-kniven skarpere og skarpere efterhånden, som man får styr på sine processer, afhængigheder, blokereringer og andre effektivitetsdræbere, som vi kender alt for godt. Altså evolutionær, langtidsholdbar forandring.

Kanban tager udgangspunkt i jeres nuværende situation, og kræver ingen organisationsændringer. Kanban kan kombineres med alle mulige andre metoder inklusive Scrum. og skalerer op og ud.

Vil du lære Kanban på Kanban University måden, så hop på mit certificeringskursus ”Team Kanban Practitioner”. Den 25/2-20 skal vi nørde ”agile”! Midt i København. Men indtil da, så kan artiklen om ”The agile crisis” varmt anbefales! (Den fik mig til at tænke KANBAN!!)

Skriv dig også på mit nyhedsbrev, så er du den første, der får at vide, hvornår jeg holder Scrum eller Kanban-kurser. Begge dele med internationale certificeringer. Og ikke mindst hvornår jeg starter min nye agile master class op. Og så får du selvfølgelig også bare tips, tricks og nyheder om “agile”, og hvad der sker derude på den agile front. Nul spam. Det lover jeg!