Kære Povl, du kan godt være agil OG hade scrum

I et blogindlæg på akademikerbladet.dk stiller Povl Gad spørgsmålstegn ved værdien af agile arbejdsmetoder på baggrund af egne erfaringer med scrum-tyranni.

Dette er et forsøg på at overbevise Povl om, at der ikke nødvendigvis er nogen sammenhæng mellem at være agil og at gennemføre scrum ceremonier (som de fastlagte mødetyper i scrum kaldes).

Hele udgangspunktet for den agile tankegang er det agile manifest fra 2001, og det lyder sådan her:

”Individer og samarbejde frem for processer og værktøjer
Velfungerende software frem for omfattende dokumentation
Samarbejde med kunden frem for kontraktforhandling
Håndtering af forandringer frem for fastholdelse af en plan
Der er værdi i punkterne til højre, men vi værdsætter punkterne til venstre højere.”

Hvis du tror på og arbejder for at realisere de idealer, så er du agil. Ikke et ord om scrum.

Formålet med scrum er at definere en struktur, som muliggør at kreative, fleksible, selvstændige og kritisk tænkende medarbejdere kan etablere en samarbejdsform, som leverer mest mulig værdi for deres organisation.

Der er ingen, der siger, at man ikke kan ændre en sprintplan midt under et sprint – det kræver bare, man bliver enig med sin productowner om, hvad der så skal tages ud i stedet.

Det er også muligt at reservere en andel af kapaciteten i et sprint til at løse ”brandslukningsopgaver”, der ikke er planlagt på forhånd. Man kan løse problemer med eksterne afhængigheder ved at sørge for at eksterne samarbejdspartnere deltager med teamet i et sprint, så man leverer sammen.

Du spørger, om man kan drive en agil brandstation, og det vil jeg mene, at man godt kan. Til det formål vil kanban-metoden dog nok være mere velegnet end scrum. Det er en metode, som er almindelig blandt IT-support teams, hvor man heller ikke kan forudsige, hvilke opgaver der kommer ind på forhånd.

I kanban har man en backlog af opgaver i prioriteret rækkefølge, og så påbegynder teamet den næste i rækken, når en opgave er løst. Pointen er, at antallet af opgaver, som er i gang, skal være så lille som muligt, så teamet kan arbejde fokuseret og altid arbejder på, der på et givet tidspunkt er det vigtigste.

Af største vigtighed er det dog at spørge sig selv: Hvorfor i alverden vil man gerne drive en brandstation, et softwareudviklingsteam eller et centraladministrativt kontor agilt? Hvilke problemer er det, der skal løses? Det er det, der skal være rettesnoren for, hvordan teamet indretter sit samarbejde.

Personligt kan jeg bare sige, at jo mere jeg lærer om, hvad det indebærer at være agil, jo mere bliver jeg overbevist om, at den tankegang skal være retningsgivende for, hvordan jeg vælger at samarbejde med andre, og for hvordan jeg tilgår mine opgaver.