Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Mange snakker om flow i disse dage, og det gør folk uanset hvilken type organisation de kommer fra og hvilken agil tilgang, de har valgt.
Det er selvfølgelig meget forståeligt, for flow er det, der i sidste ende udmønter sig i konkrete resultater, og jo bedre og mere uhindret flow man formår at skabe, des mere får man produceret.
Men én ting er, at man gerne vil være mere agile og optimere sit flow – det er en helt anden ting at lykkes med det.
Mange tror, at øget flow og produktivitet kommer nærmest automatisk og helt af sig selv, hvis bare man begynder at bruge Scrum eller SAFe, men så enkelt er det selvfølgelig ikke.
Det er der flere grunde til, og de er såmænd logiske nok. For hvorfor skulle en organisationsændring og det, at man indfører en række nye roller ændre noget som helst? Altså andet end at skabe forvirring?
Både Scrum og SAFe kræver høj modenhed i ens teams og faktisk hele ens organisation, hvis der skal være en chance for at få disse frameworks til at virke bare nogenlunde fornuftigt.
Resultaterne udebliver
Det betyder, at hvis en umoden organisation kaster sig ud i at arbejde agilt med Scrum eller SAFe, vil de opleve, at resultaterne udebliver.
De vil naturligvis få mere transparens, så de nu kan se, hvem, der arbejder med hvad, men det bliver man bare ikke agil af.
Effektiviteten og agiliteten kommer først, når man lykkes med at skabe et system, der gør det muligt at få mere gennem sin ”pølsemaskine”, end man plejede at få.
Hvis man ikke kan demonstrere, at man er blevet mere effektive og får mere over disken end man tidligere fik, kunne man jo lige så godt have sparet sine penge og al besværet.
Spørger man mig, er det kun resultaterne, der tæller, og de skal kunne måles.
Hvorfor er det så svært at få Scrum og SAFe til at virke ordentligt?
Det er der som sagt flere grunde til.
En af dem er, at man i virkeligheden er blevet i den samme gamle gænge og sætter begrænsninger på tid, præcis som man gjorde og gør, når man gennemfører projekter på den klassiske måde.
Nu sætter man bare tidsbegrænsningerne i kortere intervaller i form af sprints i Scrum eller Program Increments (PIer) i SAFe, i stedet for at tidsplanlægge et helt projekt fra A til Z, men tidsplanlægning er det stadig.
I bund og grund gør man altså præcis det, man hele tiden har gjort, og forsøger ligesom tidligere at planlægge det umulige.
Grunden til, at tingene stort set aldrig går som planlagt – selv i korte sprints, er at man arbejder med stor kompleksitet, når man arbejder med it
Der er mange ukendte ubekendte (unknown unknowns), og når noget er ukendt, er det selvfølgelig umuligt at planlægge det.
Alligevel bliver man ved med at prøve, og i både Scrum og SAFe er der ovenikøbet et uhyrligt overhead forbundet med det.
Tænk på, hvor mange møder, der afholdes, fordi ”det skal man i Scrum eller SAFe”, men hvor blev den sunde fornuft af?
Brug kun penge på noget, der betyder noget
Hver gang jeg er ude og holde foredrag eller facilitere workshops m.v. kan jeg ikke lade være med at stille dette spørgsmål: ”Leverer I altid jeres sprint-mål eller PI-objectives?”.
Så sidder folk og smågriner, og nogle er ærlige nok til at sige, at det gør de da aldrig.
Så topper jeg op og spørger: ”Hvor mange af jer oplever, at jeres product ownere, ledere, chefer eller andre skubber nye ting ind i et kørende sprint eller PI?”.
Herefter rejser der sig en skov af hænder. Det oplever alle, så hvad er det lige, vi leger?
En humpet omgang
Hvis man vælger et bestemt rammeværk eller en metode, så bliver det en humpet omgang, hvis man ikke allesammen følger de regler, der er sat op for at få systemet til at fungere.
En lidt fjollet sammenligning kunne være, at hvis man for eksempel. har aftalt at spille rundbold, så spiller hele flokken rundbold og ikke alt muligt andet.
Hvis man spiller Scrum eller SAFe, så er alle også nødt til at følge de regler, der gælder for disse frameworks.
Ellers får man komplet uforudsigelighed og tilfældig værdiskabelse.
Hvad kan man gøre istedet?
Når nu det er tæt på umuligt at planlægge selv i korte sprints, hvad kunne man så gøre i stedet?
Det hele begyndte med et ønske om at skabe øget flow, effektivitet og agilitet, og helst gøre det på en simpel måde.
Men hvis det er det, man vil opnå, så gør det en afgørende forskel, om man begrænser tid, som man gør i Scrum og SAFe, eller om man begrænser mængden af aktiviteter, man kan have igang på én gang, som man gør i Kanban.
Og hvorfor gør det så stor forskel?
Jo, når man sætter sine restriktioner på tiden, det vil sige laver timeboxes i form af sprints eller PIs, så bliver man nødt til at bruge en masse tid på at nedbryde og estimere sine aktiviteter for at finde ud af, hvor meget, man tror, man realistisk kan gennemføre på 1 - 4 uger i Scrum, eller i hele tre måneder i SAFe.
De fleste it-folk, jeg har arbejdet med, hader disse planlægningsaktiviteter af et godt hjerte.
De vil hellere lave rigtigt arbejde – det vil sige det, de blev ansat til, og det kan jeg sagtens forstå.
De er i øvrigt heller ikke særligt vilde med at forberede demoer/sprint reviews og at deltage i retrospectives. Alt det, som nogen kalder Scrum-ceremonier, hvilket ofte ender i rent agilt teater.
På trods af den store og tidskrævende planlægningsindsats vil man alligevel sjældent ramme det bulls-eye, som man prøver at ramme, fordi de føromtalte ukendte ubekendte rammer ens team, når man mindst venter det.
Eller fordi der dukker nye ting op, som viser sig at være vigtigere end det, man planlagde ind i sit sprint eller PI.
Disse presses så ind i det igangværende sprint eller PI, hvilket får planen til at skride og spill-over fra sprint til sprint bliver dagens orden.
Det er det, man kalder virkeligheden, og disse realiteter gør det nærmest umuligt at levere konsistent og forudsigeligt.
Man kunne jo droppe sine sprints og bruge Kanban i stedet
Vil man have konsistens og forudsigelighed, bør man kigge på Kanban.
Her sætter man i stedet restriktioner på hvor meget, der kan være i gang ad gangen, så der skabes balance mellem udbud og efterspørgsel.
Man kan alligevel ikke få mere igennem, end ens organisation har kapacitet til, så det er rent spild af tid at prøve på det.
Til gengæld giver Kanban-systemer mulighed for, at product owners, ledere og andet godtfolk løbende kan ændre i deres prioriteringer, uden det afstedkommer forstyrrelser i det igangværende arbejde, og mantraet er ”stop starting – start finishing”.
Det er vigtigt at understrege, at Kanban har været et flow-system lige fra fødslen.
Formålet med at bruge Kanban – skaleret eller ej – har altid været at optimere flow og dermed øge effektiviteten og agiliteten.
Men forestil dig nu, at du har et Kanban-team på for eksempel seks seks personer.
De vil typisk have maksimalt 10-15 opgaver i gang på en gang.
En af disse opgaver vil hurtigt blive færdig, hvorefter det team-medlem, der nu har ledige hænder, vil tage den næste opgave i køen.
Har man som product owner eller ledelse behov for at prioritere en helt ny men vigtig opgave højt, så lægges denne simpelthen øverst i køen, og på den måde går der kun kort tid, før denne nye og vigtige opgave kan sættes i gang.
Nye prioriteringer foretages i god ro og orden, uden at der sker task-switching, som er virkeligt ineffektivt, og også helt uden ”disruption”.
Kanban er ganske enkelt gearet til at kunne håndtere den uforudsigelige hverdag, som de fleste videnarbejdere befinder sig i, og bilder heller ikke nogen ind, at man kan planlægge sig ud af kompleksitet.
Det er ganske enkelt umuligt.
I stedet bygger man sit Kanban-system, så det er tilpasset til det team og den kontekst det skal fungere i, og kan rumme den uforudsigelighed, der måtte være
På den måde bliver hvert Kanban-system virkelighedsnært, og man forsøger ikke at presse sine teams eller for den sags skyld hele organisationen ned i en rigid skabelon, som de ikke kan være i.
Det gør det meget nemmere og billigere at komme i gang. Kanban er ovenikøbet datadrevet, hvilket gør de agile fremskridt målbare.
Kan man planlægge i Kanban? Ja, selvfølgelig!
Ellers kan man jo ikke styre sine initiativer både på den korte og den lange bane.
Det fører for vidt her at gå ind i detaljerne omkring Kanban-metoden, men det er en ekstrem enkel og stærk vej til at optimere flow, effektivitet og agilitet.
Det er desværre bare stadig lidt af en velbevaret hemmelighed, og det er ærgerligt.
Derfor er det endnu sværere at få de agile frameworks til at virke i det offentlige
Med basis i min tilbundsgående viden om agile systemer tør jeg godt påstå, at man oven i de besværligheder, man har med at få de agile frameworks til at virke og give resultater i den private sektor, lægger et lag at kompleksitet på, når man forsøger at bruge disse frameworks i det offentlige.
Her kommer et par eksempler:
- Der er typisk en stærkere top-down-styring, som gør ideen om selvorganiserende teams til en illusion.
- Der er mere rigide beslutningsgange og godkendelsesprocedurer, hvilket skaber flaskehalse og ventetider af stærkt varierende længde.
- Der kommer uforudsete hasteopgaver fra for eksempel det politiske niveau, hvilket betyder, at man kan glemme alt om sine sprint-planer og i stedet smide, hvad man har i hænderne.
- Der kan være alle mulige gode grunde til, at tingene fungerer, som de gør, men når nu det er sådan, så siger det næsten sig selv, at det er urealistisk at tro, at man kan planlægge noget som helst i sprints, som kommer til at holde i virkeligheden.
Jo mere uforudsigelig ens arbejdsdag er, des mere umuligt er det at planlægge selv i korte sprints. Og tre-måneders PIer i SAFe? Det kan man glemme alt om.
Få realisme ind
Virkeligheden vinder hver gang.
Dette skal ikke opfattes som en kritik af hverken de agile frameworks, eller den måde det offentlige fungerer på.
Det handler udelukkende om at få noget realisme ind i den agile ligning. En realisme, som mange steder er ganske fraværende.
Uanset hvem, der måtte stå og stampe i gulvet, kan man ikke få noget, der ikke kan lade sig gøre. Heller ikke selvom man insisterer.
Men inden, man fortvivler helt, er det værd at holde sig for øje, at der ligger en løsning lige foran fødderne, nemlig Kanban-metoden som er den alternative ved til agilitet.
Kanban kan rumme stor uforudsigelighed og omskiftelighed, og metoden kan også bruges i umodne teams og organisationer og alligevel skabe overbevisende resultater.
Så hvad er det vigtigste?
At bruge tiden på at spille agilt teater eller skabe robuste resultater og målbare forbedringer?
Havde jeg mine egne penge på spil, ville jeg til hver en tid vælge det sidste.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.