Scrum-master: Pas på agile myter

4. januar 2018 kl. 05:112
Scrum-master: Pas på agile myter
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.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

‘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.

Artiklen fortsætter efter annoncen

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.

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.«

Fakta om Scrum

  • Scrum består af en række aktiviteter, som holdet gennemfører sammen. De centrale begreber er:

  • Morgenmødet: Deltagerne står op og svarer på tre spørgsmål: Hvad lavede jeg i går, hvad skal jeg lave i dag, og er der noget, der holder mig tilbage?

  • Backlog: En liste af opgaver, som holdet arbejder på i prioriteret rækkefølge og mest veldefineret i toppen. Egentlig to lister – en, som handler om hele produktet, og en, som handler om, hvad der skal ske inden for de næste to uger.

  • Produktejer: Den absolut sværeste rolle i Scrum. Den person, der bestemmer, hvad produktet skal bestå af, og som foretager prioriteringen af opgaver. Kommer fra forretningsdelen af organisationen.

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.

»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.

»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.

2 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
2
4. januar 2018 kl. 15:43

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
4. januar 2018 kl. 09:23

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