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 af sig selv mere fleksibel.
  3. Alle katastrofer, store som små, skal følges op med en refleksion. En refleksion, 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.
Kommentarer (2)
Nikolaj Brinch Jørgensen

Vildt godt indlæg, og egentlig underligt at det først er nu jeg ser et indlæg af denne type.

Der er alt for mange organisationer der har "indført" Scrum, som den nye metode, der nu er fastlagt og mejslet i sten, og hvor man er slave af en forældet of foruddefineret proces der er blevet så tung at den bidrager negativt til udviklingen. Der er ikke længere noget agilt eller dynamisk over den - den er sandet til over alt for lang tid.
Der burde være defineret en maksimumgrænse for antallet af dele en proces kan indeholde, så hvis man vil indføre endnu en delproces i sin proces, må man tage en anden ud - så er man nødt til at prioritere sine delprocesser og vigtigheden heraf.

Bent Jensen Blogger

Tak for din kommentar.

Enig i at det kan være en god medicin at vedtage at indfører vi en ny praksis, så fjerner vi også en.

Noget andet er et praksis nogen gange stivner, selvom man godt ved at de ikke fungerer godt i den nuværende form. Folk får kvalme af Scrum, og vil bare forholde sig til arbejdet. Der er forståeligt, men når processerne ikke kører godt og de ikke bliver forbedret, så bliver det primære arbejde også påvirket negativt.

Log ind eller Opret konto for at kommentere