Legacy Scrum - når Scrum stivner

Legacy kode, er kode man ikke har lyst til at rette i. Det er uoverskueligt, og der er ingen der rigtig kan forklare, hvad formål det tjener, og hvorfor det ser ud som det gør. Når der er for meget legacy kode i et projekt, bliver teamet demotiveret og produktiviteten daler.

Det eneste der er at gøre, hvis man vil ud af dødvandet, er at gå i gang med det lange seje træk, hvor man langsomt og systematisk lukker koden op, og gør den levende og plastisk igen.

Hvordan blev det til legacy kode? Det stivnede en dag ad gangen. Måske var der for travlt, måske var der ikke rigtig nogen der tog ejerskab og efterhånden blev alle ligeglade. Måske er teamet udskiftet, så der ikke er nogen kollektiv hukommelse.

På helt samme måde kan man opleve, at en levende og dynamisk agil proces, som f.eks Scrum kan stivne og blive til legacy Scrum. Ingen ved rigtig, hvorfor man gør som man gør, energien er lav og interessen for processen ligeså. Scrum ritualerne minder mest om en gudstjeneste på latin i en katolsk kirke.

De selvsamme ritualer, som i starten af teamets agile rejse, var genstand for passionerede diskussioner, konstant tilpasning og justering. Alle forholdt sig aktivt til MÅDEN arbejdet blev udført på.

Den helt centrale idé i Scrum er princippet om “Inspect and adapt”. Det betyder, at man konstant tilpasser sig de givne omstændigheder. Ikke bare passiv underkastelse, men hele tiden giver det bedste modsvar til de betingelser, man skal eksistere og producere under.

Dette princip skal fungere på to niveauer: Produkt og proces.

På produktniveauet er det ensbetydende med muligheden for at reagere hurtigt på indtrufne omstændigheder. Er vi i en konkurrencesituation, kan vi forholde os til en konkurrents sidste træk. Arbejder vi i relation til en enkelt kunde, kan vi tilpasse os nye krav - enten fordi kunden er blevet klogere, eller fordi hans omstændigheder har ændret sig. Nye regler, ny lovgivning eller en ny strategi.

Humlen er, at vi ikke forsøger at fastholde den aftale vi indgik, da vi vidste mindre end vi ved nu, men i stedet optimerer i forhold til det givne. Det er en af de væsentligste grunde til, at agil udvikling giver langt bedre resultater, end de fleste andre måder at arbejde på.

Det er denne indsigt, som også skal benyttes på procesniveauet. Scrum eller enhver anden agil metode, er ikke noget man overstår, så man bagefter kan beskæftige sig med noget andet. Det er en evolutionær måde at arbejde på, som de involverede hele tiden ændrer, tilpasser og forbedrer. Det betyder også, at det der startede som en variant af Scrum kan blive noget til helt andet med tiden, eller omvendt. Jeg selv startede mine agile erfaringer med eXtreme Programming, og vi indførte først Scrum på det tidspunkt, da vi i vores team havde nogle udfordringer, som specifikt Scrum kunne hjælpe os med.

Hvad gør man så, hvis man er så uheldig at være endt med legacy Scrum?

For det første, er der ikke grund til at bruge tid på at tale om, hvem der har skylden og hvad der skulle have været gjort anderledes. Processer sander til én dag af gangen, på samme måde som kode, og det er langt mere interessant at bruge energi på at komme videre og undgå at falde i hullet igen.

Her er 3 tips, som vil hjælpe til at undgå legacy Scrum og til at komme væk derfra igen. Som med legacy kode er det et langt og sejt træk, hvis man først er havnet i hullet

  1. Lav retrospektiver. "Det gør vi allerede", siger I måske? Men kommer der også noget ud af dem? Et retrospektiv uden efterfølgende handling, er nytteløst. Det er i bedste fald et sted, hvor man kan lufte sine frustrationer. Det bliver man ikke mæt af i længden.
  2. Skab et pres for forbedring. Enten indefra teamet, fra kunden eller fra ledelsen. Det skal være et erklæret mål at få forbedringer: Færre fejl, større produktivitet eller kortere gennemløbstider. Når der er dette vedholdende, og rimelige pres og der samtidig er afsat tid til, at man langsomt og stabilt kan arbejde sig henimod målet, bliver processen helt ad sig selv mere fleksibel.
  3. Alle katastrofer, store som små, skal følges op med en reflektion. En reflektion, som ikke har til formål at finde og straffe de ansvarlige, men hvor årsager findes, og noget ændres, så sandsynligheden for en tilsvarende katastrofe er mindre fremover. “Det kunne vi ikke have forudset!” er aldrig en gyldig undskyldning. Det er derimod helt i orden, at have overset noget og så bagefter gøre en indsats for, at det ikke kommer til at ske igen. Legacy Scrum eller ej. Vi er trods alt kun mennesker.

Bent Jensen