Agile Bloggen

Søren Larsen

om Scrum, Kanban, Backlogs og alt andet Agile

Scrum er ikke altid løsningen

Hvad gør man, hvis de arbejdsopgaver der i en backlog ikke egner sig til at lave scrum sprints, når prioriteterne skifter hurtigere end opgaverne bliver løst og planerne konstant bliver væltet af "ildebrande" der blusser op hist og her i de kørende services.

Kanban to the rescue!

Der er mange lighedspunkter mellem Scrum og Kanban, der gør det ideelt til at være en brobygger fra en ustruktureret dagligdag i et udviklingsteam til at køre Scrum. I min blogpost om "Få styr på backlog", har jeg beskrevet hvordan man kan gå direkte fra ingen struktur til at være klar til at køre scrum sprints. Men hvis man står med en backlog, som egentlig er klar til at løse og et team der ikke har ro til at eksekvere fordi der er andre opgaver der tager tiden. Her ligger styrken i at indføre Kanban som en møde at visualisere alt igangværende arbejde, både kendte og ukendte opgaver. Her er det vigtigt at pointere at det kun skal bruges til at få overblik over opgaver, for at kunne optimere på flowet af opgaver og ikke til at udpege syndere i teamet.

Hvis man bruger denne fremgangsmåde til at at få optimeret arbejdsrytmen, vil man sandsynligvis inden længe, være klar til at tage springet fra Kanban til Scrum og derved opnå mere forudsigelighed i hvornår hvilke opgaver bliver løst. Her er Kanban ikke så stærkt et værktøj, idet man som udgangspunkt ikke vil estimere opgaverne som man kan i Scrum med story points og lignende, men derimod fokusere på at få et jævnt flow af opgaver igennem. Det kan også være at man vælge at beholde Kanban som værktøj til at styre dagligdagen og aldrig gå Scrum vejen - Det vil sikkert i mange tilfælde være en lige så god løsning.

Få styr på backlog

En af de første ting, som jeg som ScrumMaster fokuserer på sammen med et nyt team er deres Product Backlog.

I en optimal verden består en backlog af en række backlog items, som en Product Owner har prioriteret og gjort klar til sprints, således at de højest prioriterede backlog items er estimeret og beskrevet så godt at man kan tage dem ind i et sprint.


Men sådan ser det sjældent ud. Typiske problemer er manglende Product Owner eller en Product Owner der ikke er i stand til at lave dette arbejde. Jeg har også været ude for situationer, hvor backlog ikke er en egentlig Product Backlog, men derimod en backlog der stammer fra flere forskellige produkter, med forskellige Stakeholders og derved også en svær prioritering og forskellige standarder for hvor grundig en backlog item er beskrevet.

I de tilfælde har jeg som ScrumMaster sammen med Teamet måttet bruge tid på at bearbejde backloggen og få hvert enkelt backlog item op på en niveau, hvor man er i stand til at tage den med i et sprint.

Er det optimalt og er det Scrum? Næ, det er det ikke, men hvis det er det, som der skal til for at komme igang med en Scrum proces, så er det vel også ok. Så længe at man samtidig med får trænet Stakeholders i at lave gode backlog items og får dem til at blive enige om en prioritering

Hvordan bearbejder man så backloggen. Det jeg synes man skal gøre er at have et eller flere korte sprints, hvor man bearbejder backlog items sammen med de enkelte stakeholders indtil man har fået lavet en backlog klar til et egenligt sprint. Her er der dog en fælde! Det er vigtigt at man kun fokuserer på mål og acceptance criteria i denne proces og ikke går i designmode, således at man istedet for en Agil proces får lavet sig nogle mini-vandfald bestående af design og udviklingssprint. Designet af løsning hører til i forbindelse med sprintet.


Fra organiseret kaos til struktureret rod

Den første gang jeg stødte på begrebet Agile er tilbage i 2007, hvor jeg skiftede arbejdsgiver.

Jeg havde arbejdet som udvikler i en mindre virksomhed, hvor det ene projekt afløste det andet og opgaverne ofte skred både tids og scope mæssigt. Men selvom der indefra kunne føles meget kaotisk, så alligevel var der en struktur på det overordnede projekt, men det var ikke særlig synligt på opgave niveau og opfølgningen var meget sporadisk.

Hos min nye arbejdsgiver, stiftede jeg for første gang kendskab med begreber som agile og vandfaldsmodeller. Når jeg kiggede tilbage, kunne jeg godt se at de projekter, som jeg havde været med til at lave tidligere, var meget baseret på vandfaldsmodellen.

Et typisk projekt startede med en længere analysefase afsluttende med en prototype eller nogle designbeskrivelser af en løsning. Herefter gik udviklingsfasen igang, som varede indtil at produktet var klar til test. Herefter var der en lang testfase, hvor der hele tiden var tilbageløb på grund af misforståelser i designfasen eller ændringer i scopet, efterhånden som testen skred frem.

Jeg kunne hurtigt se at den iterative model som Agile bygger på, kunne have forebygget mange af disse problemer. Men samtidig måtte vi i teamet erkende, at det nok ikke var så nemt at indføre en agil udviklingsmodel. Vi lavede nok alle de fejl, som man kunne gøre i den proces.

  • Ingen kontakt til Product Owner i vores iterationer
  • Ikke noget klart iterations mål
  • Ingen defineret backlog
  • og sikket meget mere

Vi var faktisk slet ikke agile, men lavede bare udvikling uden nogen form for dokumentation eller styring selvom vi holdt daglige "scrummøder", hvor vi sad i en rundkreds og snakkede om opgaveløsning, i stedet for at fokusere på fremdriften i iterationen.