Til at varme lidt op vil jeg bruge en metafor om en container havn. Forestil dig at du er en fabrik der producerer dimser som skal sendes med container til slutbrugeren. Når dimserne er færdige og klar til at blive sendt til brugeren, så pakkes de i en container der fragtes til havnen. Det er et potentielt releasebart produkt. Fabrikken og medarbejderne behøver ikke længere bekymre sig om at producere dimser til den pågældende slutbruger. Når rette tid kommer, så skibbes containeren afsted med skib til slutbrugeren. Hvis vi leger med tanken om at det er slutbrugen der bestemmer hvornår skibet sejler, så har vi præcis den situation vi gerne vil have når vi arbejder iterativt og inkrementelt. Vi leverer et potentielt releasebart produkt, der frigives når slutbrugeren er klar til det.

Hvis vi lige skal reflektere over den måde din organisation arbejder, så kan du prøve at besvare følgende spørgsmål:

.. hvis ikke er det så iterativt og inkrementelt?

Og er det overhovedet et problem?

For at finde ud af om det er et problem, så skal vi tilbage i tiden. Kan du huske Winston Royce? Måske ikke, men Winston Royce beskrev i 1971 den metode som vi i dag kender som vandfaldsmetoden. I vandfaldsmetoden arbejder man i faser – startende med analyse og afslutningsvis i drift. Sådan et gennemløb kan vare i flere år.

Vandfaldsmetoden er en rigtig god metode. Specielt hvis man arbejder med problemer som er forholdsvis simple i den forstand at man kan analysere sig frem til en nøjagtig løsning som ikke skal fraviges. Et eksempel på sådan et projekt kan være en bro. Her laves en masse indledende boringer, analyser, tegninger og beregning inden byggearbejdet bliver igangsat. Byggearbejdet består basalt set af at hælde beton i forme og montere færdigproducerede elementer. I tilfældet med brobygning, så er alle andre metoder en vandfald fjollede.

Winston Royce beskrev vandfaldsmetoden på et tidspunkt hvor datakraft var begrænset og systemer blev programmeret ved hjælp af fysiske hulkort. Når hulkortet var klar til kørsel, blev der booket tid til kørsel af systemet. En forholdsvis tung proces sammenlignet med i dag.

På trods af de forudsætninger der var i systemerne, så beskrev Winston Royce faktisk også problemerne ved at bruge vandfaldsmetoden. Det er bare ikke alle der har læst den del af hans artikel. Han skrev altså allerede i 1971 at vandfaldsmetoden var risikabel og kunne fejle. Den primære årsag til at vandfaldsmetoden fejler er at den ikke kan håndtere læring opnået undervejs – også kendt som feedback.

Dykker man yderligere ned i Winston Royces artikel, så finder man en tegning med bagud vendte pile. Jeg skal nok undlade at gå i detaljer, men bare påpege at han allerede dengang indså at det var essentielt at indarbejde feedback loops i udviklingen.

I mere moderne tid arbejder stort set alle efter Scrum. Scrum er beskrevet af Jeff Sutherland og Ken Schwaber i den officielle Scrum guide og beskriver en iterativ og inkrementel tilgang til risikominimering og optimering af forudsigelighed.

Og hvordan gøres det? Jo, det der sker, er faktisk at man koger hele Winston Royces iterative vandfaldsmodel ned i korte iteration af 2-4 uger med fokus på at levere et færdigt produkt der potentielt kan releases.

En af guruerne inden for agil udvikling er Craig Larman. Craig beskriver agil udvikling som et redskab til at understøtte ændring af retning for hele tiden at kunne arbejde på det der skaber allermest værdi for kunden på nuværende tidspunkt. Det er i stor kontrast til den oprindelige vandfaldsmodel. Her leverer man den værdi man beskrev i analysefasen og hvem ved om det reelt er det der giver mest værdi i dag?

Kigger vi i de agile principper der følger med det agile manifest, så finder vi helt specifikt to principper der beskriver det vi ønsker at opnå med iterativ og inkrementel udvikling:

Nr 1 – vores højeste prioritet er at skabe glade kunder ved at levere værdi kontinuert

Nr 7 – Den primære indikator for succes er velfungerende software – og altså ikke antal timer der er brugt på projektet!

Nå, nok om teori og videre til det der virkelig batter noget! Hvad er det så du kan gøre i dagligdagen som leder eller medarbejder?

Du kan starte med at spørge: Giver dette sprint værdi hvis der skal arbejdes på noget nyt i næste sprint?

Altså, hvis teamet skal arbejde på et nyt projekt om 2 uger; hvilken værdi får kunden så af det arbejde der er udført?

En anden ting man kan gøre er at inspicere de backlogs der arbejdes på. Her er et eksempel – du kan selv afgøre om det er et godt eksempel:

På backloggen står der: analyse af pdf ændringer, design af pdf løsning, programmering af pdf løsning.

Forestil dig at teamet kun har kapacitet til at løfte 2 opgaver i et sprint og derefter skal arbejde på et nyt projekt. Er det så en god opdeling af opgaver?

Du kan også prøve at gå forbi teamets sprint board efter de har holdt daily standup. Jeg har flere gange set sprint boards hvor ”todo” og ”done” søjlerne er tomme mens ”doing” søjlen er proppet. Er det godt? Alle opgaver er i gang, alle i teamet er aktiverede. Det må da være godt – eller hvad?

I min optik er det et problem: Der er massiv risiko for at ingen opgaver når at blive færdige, da der slet ikke er fokus på at få lukket de enkelte opgaver. En anden ting der er risiko for, det er at der er afhængigheder til enkelte nøglepersoner. Hvad nu hvis han bliver syg? Hvad sker der så for projektet når alt er i gang og intet er afsluttet?

Sidste eksempel jeg har med kan ses ved deltage på sprint review med teamet. Her har jeg oplevet et team der ved 3 sprint reviews i træk har præsteret at berette at de stadig er i gang med “opdatering af pdf løsning”. Det er da dejlig, men hvad betyder det? Hvad har jeg som interessent reelt fået for de penge der er afsat til udvikling? Indtil videre har jeg ikke fået meget mere end et stykke kage og et flot powerpoint.

Nå, men, et spørgsmål der måske er dukket op hos dig er: Kan det virkelig passe at det en leder skal gå rundt og se på backlogs og deltage i reviews?

Det synes jeg.

Husk at man som leder netop skal skabe de bedst mulige rammer for success. Hvis det betyder at man skal være sparringspartner omkring backlogs og deltage på reviews – ja, så er det ledelse.