Scrum-master: Pas på agile myter

Man kan lige så godt fejle med et agilt projekt, som man kan med vandfaldsmetoden. Scrum er en stor lommelygte, der gør det synligt, hvor man har problemer. Og det er misforstået, især i ledelseslaget, mener Therese Hansen. Illustration: Mikkel Meister
Agile metoder er i dag den herskende måde at udvikle software på. Men Scrum og andre agile teknikker er ingen garanti for succes.

‘Hvis vi starter med Scrum, så bliver alting godt.’

»Det er den myte, der gør størst skade i den agile verden – for du kan lige så godt fejle med et agilt projekt, som du kan med et vandfald. Scrum er en stor lommelygte, der gør det synligt, hvor man har problemer. Det er det først skridt til, at man kan løse dem. Og det er misforstået, især i ledelseslaget.«

Sådan fortæller Therese Hansen, som er certificeret Scrum-master og omrejsende konsulent med speciale i at lede og optræne udviklerhold i de agile dyder.

Mytiske mandetimer giver ikke pote

Og hvad gemmer sig bag dette ord, agil, som høres så ofte i softwarebranchen? Det agile gennembrud tog sin begyndelse i 1999, hvor bogen ‘Extreme Programming’ udkom. Den beskrev et bud på udviklingsmetodikker, der lå meget langt fra datidens vandfaldsmodel, hvor et projekt planlægges med faser langs en tidslinje.

Og det fungerer jo meget godt, hvis man skal bygge en tunnel, så hvad er egentlig problemet? Det er, at softwareudvikling er en mærkelig størrelse, hvor flere ressourcer ikke nødvendigvis flytter holdet tættere på målet, og hvor målet slet ikke er lige så klart defineret, som en forbindelse til Femern er.

Læs også: 15 år efter det agile manifest: Vi er stadig ikke gode til agil udvikling

Disse forhold var beskrevet allerede tilbage i 1975 i bogen ‘The Mythical Man-Month’, hvor et større softwareprojekt hos IBM sejler længere og længere agterud, jo flere udviklere der sættes til at løse opgaverne.

De agile metoder, der tog softwareverden med storm i 00’erne, prøver at løse problematikken med små, planlagte faser ud fra devisen: Hvad er vigtigst i de næste to-tre uger.

Kombineret med regelmæssige møder, fleksible opgaver og åbenhed har det givet pote i en sådan grad, at agile metoder i dag dominerer inden for udvikling af software. Scrum er en af de mest anvendte varianter af ideen i dag.

Agil udvikling kan ikke ændre rådden organisation

Men nye ortodoksier kan også give nye problemer. Såsom ideen om, at Scrum kan løse alle problemer, man kan komme ud for.

»Der, hvor Scrum rigtigt kan fejle, er, hvor man kan se sine problemer, men nægter at gøre noget ved dem,« mener Therese Hansen.

Det lyder paradoksalt, men den situation kan opstå, hvis eksempelvis forskellige afdelinger i en organisation bevidst modarbejder hinanden.

»Der kan Scrum og agile metoder være direkte skadelige.«

Det skyldes, at ‘lommelygten’ kan afsløre alt for meget dårligdom, og den fastlåste situation virker demotiverende for holdet. Det kan i værste fald føre til stress og opsigelser.

»Når Scrum fejler, så er det ofte denne slags historier, jeg hører.«

Man starter med at lytte

Men der er heldigvis masser af agile projekter, der lykkes. Det er Therese Hansens opgave som omrejsende konsulent og Scrum-master at få softwarehold ind på sporet. Det kan foregå sådan her:

»Først starter jeg med at lytte. Det team, jeg har fat i lige for tiden, kørte ikke Scrum. Så det handlede om at finde ud af, hvad deres metode var – hvad er det egentlig, de gør?«

Som oftest er det den omtalte vandfaldsmodel, der benyttes, eller det, som Therese Hansen kalder for ‘Scrum-light’ – nogen der har holdt de centrale morgenmøder, men ikke rigtigt har fået fordelene ved den fulde udgave af metodikken.

Om scrum er løsningen, handler meget af opgavens karakter, siger Therese Hansen: »Jeg oplever, at driftshold med mange små opgaver, der kommer ind hele tiden, har det godt med Kanban-stil,« siger hun. Illustration: Mikkel Meister

»Jeg har oplevet at komme ind på hold, hvor der er tre forskellige backlogs og fem, der bestemmer, hvad teamet skal lave. Så skal man prøve at få teamet ind i en bedre verden, hvor prioritering er klarere.«

Det er ikke fordi, Scrum er den eneste agile løsning, der findes, og Therese Hansen har også flere bud med i lægetasken.

Læs også: DevOps-ekspert: Udviklere bliver bedre, hvis de selv skal lide under dårlig kode

»Det handler meget om typen af opgaver. Jeg oplever, at driftshold med mange små opgaver, der kommer ind hele tiden, har det godt med Kanban-stil,« der henviser til en teknik udviklet i Japan, der også bredt er kendt som ‘Toyota-metoden.’

»Det har også at gøre med krav, der kommer ind, og hvor hurtigt de skal kunne reagere på tingene. Nogle teams har brug for flere processer end andre.«

Hvis man arbejder med systemkritisk software, er det vigtigt, at der er en stram proces for at sikre et minimum af fejl. Det er en anden problemstilling, end hvis holdet udvikler software til underholdningsformål.

»Med kritiske applikationer kan man ikke prøve sig frem – så må man være mere skarp på krav og test. Man arbejder langsommere, og så skal det, man leverer, være i orden. Man har flere iterationer, før softwaren kommer i produktion.«

Det lyder næsten som vandfald?

»Hvis man har en kravspecifikation for de næste 14 dage, så er det jo ikke langt fra en hel masse små vandfald. Det er et spørgsmål om at have en ide om, hvor man skal hen. Men vi behøver ikke se to eller fem år frem i tiden. Vi starter på noget, og så viser vi noget, og så har vi krav til den næste iteration. Vi planlægger hele tiden i Scrum – bare på den korte bane.«

Denne artikel er skrevet til den trykte avis Ingeniøren.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
lars christoffersen

Følg de her råd iterativt og glem alt hype:

By Pragmatic Dave Thomas

Agility — What to Do
* Find out where you are
* Take a small step towards your goal
* Adjust your understanding based on what you learned
* Repeat

Agility — How to Do It
* When faced with two or more alternatives that deliver roughly the same result, take the path that makes future change easier

  • 0
  • 0
Philip Juhl

Er der nogen steder i artiklen der hentydes til Scrum er det samme som "Agile software development"?
Synes det er yderst fornuftigt at lytte til det enkelte teams behov og udfordringer.
Kan specielt godt genkende det med at Scrum er en god til at identificere de problemstillinger der er ift. at være agile.
Det springende punkt er så hvordan man forholder sig til de problemstillinger.

  • 1
  • 0
Log ind eller Opret konto for at kommentere