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.