Skrevet af: Development Manager Henrik Wendt
Scrum: Engang kunne IT-udviklere arbejde på en løsning i både halve og hele år, før et eneste skærmbillede blev delt med omverdenen.
Vandfaldsmodellen, som var udviklernes foretrukne projektstyring, betød lange projekttider og kæmpe risiko for at lancere systemer, der ikke var brugervenlige, eller som ganske enkelt var outdated allerede inden offentliggørelsen.
Det ændrede sig heldigvis i 90’erne og 00’erne med Scrum-metodens indtog. I dag føler langt de fleste udviklingsafdelinger sig hjemme i terminologien “Scrum master”, “Sprint”, “Project owner” og “Grooming”.
Selv har jeg brugt Scrum-metoderne i vores udviklingsafdeling i mere end 20 år, og med mere end 400 sprints i bagagen har vi lært lidt i processen.
I denne artikel får du derfor mit bud på tre af de mest hyppige årsager til, at IT-afdelinger ikke lykkes med Scrum-metoden.
1. I bliver for ambitiøse med jeres produkt
Hele grundtanken bag Scrum-metoden er, at I kan udvikle jeres produkt i korte faser og få løbende feedback på de løsninger, I laver.
For at kunne få feedback kræver det altså, at I løbende er stand til at release de udviklingstrin, I arbejder med. Selv arbejder vi med daglige releases internt i udviklingsafdelingen, så vi hver dag kan se, hvordan vores nyeste kode tager sig ud for brugeren.
Når vores sprint er forbi hver 14. dag, er vores klare mål altid at have vores arbejde klar til demonstration til styregruppen, så resten af organisationen kan følge med.
Nice-to-have eller need-to-have?
Hvis det ikke kan lade sig gøre at udgive som minimum en demoversion af det, vi arbejder på, kan det være et tegn på, at vi har været overambitiøse med funktionaliteterne af vores produkt.
Det kan være tegn på, at vores idé om de features og funktioner, vi gerne vil inkludere i vores software, ikke har bestået testen, om det er “nice-to-have” eller “need-to-have”.
For at få fuld værdi af Scrum, er det nemlig vigtigt hele tiden af evaluere vigtigheden af en feature. Tankegangen om agil udvikling beror på, at styregruppen og project-owneren er i stand til at prioritere de features, der skal udvikles, på en sådan måde at vi hele tiden udvikler systemet i små, men væsentlige inkrementer (for at blive i Scrum-sproget).
Tænk derfor hele tiden, at I ikke skal udvikle mere end I kan slippe afsted med. Det er ikke et spørgsmål om at springe over, hvor gærdet er lavest, men snarere at udvælge, hvilket gærde I vil over, på en intelligent og brugerorienteret måde.
Apropos, så har vi også skrevet en artikel om, hvordan du finder det rigtige gærde, når det kommer til at være effektiv i IT-supporten. Læs den her.
2. I falder for ugens idé
I Scrum udvælger i hele tiden nye features at arbejde på. Hele tiden skal I være parate til at skifte kurs og udvikle andre funktioner end dem, I troede for bare en måned siden.
Den agile tilgang til udviklingen er essentiel. De skiftende prioriteringer af features er det, der gør, at jeres produkt ikke er outdated allerede inden launch.
Men med muligheden for at skifte retning mellem hvert sprint opstår også risikoen for at falde for ugens gode indslag: en funktionsforespørgsel fra en kunde, et specialønske fra salgsafdelingen eller måske et hurtigt retningsskifte fra direktionen.
Når vi selv er faldet i fælden og har brugt et sprint på at udvikle en feature, som ville “lukke salget af en potentiel kunde”, er vi indimellem ramlet ind i to problemer:
- Kunden valgte alligevel en anden leverandør
- Vores øvrige kunder kunne ikke bruge den udviklede feature
Vi har med andre ord spildt et udviklingssprint på en funktion, som ingen værdi har. På den positive side er spildet begrænset til to ugers arbejde, hvor man uden Scrum-metoden let kunne have hældt langt flere mandetimer ud ad vinduet.
Sæt “geniale” idéer i karantæne
Hvis du vil undgå at falde for ”ugens idé”, kan du opsætte en karensperiode for nye idéer. Ved at sætte nye idéer i en kortere eller længere karantæne, før de tages i betragtning til jeres prioriterede backlog, giver I jer selv muligheden for at se idéen lidt på afstand.
Det handler i virkeligheden om at bevæge sig ud over idéens hvedebrødsdage, så den indledende iver og entusiasme kommer lidt på afstand, og så I er bedre i stand til at vurdere idéen ligeværdigt med de øvrige features og udviklingsidéer i jeres backlog.
Hvis den nye idé haster – altså er afgørende for at lukke et salg eller lignende – og I altså ikke har mulighed for at sætte den i midlertidig karantæne, så sørg for, at hele styregruppen køber ind på idéen, og at alle i styregruppen kan se, at idéen skaber væsentlig værdi for netop den funktion i organisationen, som de repræsenterer.
Både sælgere, projektledere, direktionen og udviklerne – ja, og brugerne – skal kunne se idéens potentiale, før det giver mening at inkludere den i et sprint.
3. Synergien i organisationen skal styrkes
Den sidste faldgrube, jeg oplever, når udviklingsafdelingen ikke lykkes med Scrum, hænger sammen med samarbejdet på tværs af afdelinger. Der er altså tale om et organisatorisk problem mere end et faktisk problem med udviklingstilgangen.
For at få succes med Scrum-metoden, kræver det nemlig enormt meget kommunikation mellem udviklingsafdelingen og de øvrige forretningsenheder i en virksomhed.
Det kræver, at udviklingen hele tiden ved, hvilke behov der er ude i afdelingerne og hos kunderne, og det kræver fx, at salgsafdelingen hele tiden er opdateret på de seneste systemopdateringer.
Hvis salgsteamet er helt opdateret på de seneste funktioner i jeres løsning, øger I jeres konkurrenceevne, fordi I giver sælgerne et bedre produkt at gå i marken med.
Omvendt er det også væsentligt at sælgerne ved præcis hvilke features, der er lanceret, og hvilke der endnu er på tegnebrættet, så sælgerne ikke pludselig har lukket en ordre med lovning på funktionaliteter, der endnu ikke er færdige.
Samarbejder med hele virksomheden
Synergien mellem salg- og udviklingsafdelingen er naturligvis nødvendig, men faktisk kan synergien med nogle af de andre forretningsenheder vise sig at være endnu mere vitale både for at undgå unødig irritation og skygge-it.
Det er eksempelvis af yderste væsentlighed, at økonomiafdelingen har indflydelse på timingen af større ERP-opgraderinger, så du som IT-chef ikke kommer til at release omfattende systemændringer, tre dage før der skal afleveres momsregnskab.
Som i så mange andre sammenhænge er det også ofte i kommunikationen mellem mennesker, at udviklingsafdelingen fejler – Scrum eller ej.
Med korte udviklingssprint og skiftende udviklingsfokus er behovet for god kommunikation og synergi mellem afdelingerne blot forstærket.
Sørg derfor for at have tjek-ind-møder med beslutningstagere og brugere fra resten af virksomheden med jævne mellemrum. Find selv en passende balance, men et orienteringsmøde én gang om måneden kan være et godt sted at starte.
Alt i alt handler den gode Scrum-proces om at være på forkant med tingene og tage bevidste valg.
I er godt på vej til en værdifuld Scrum-udvikling, hvis I sørger for at have en proaktiv tilgang til kommunikationen, en sund skepsis over for “geniale” indfald og en kynisk realisme i forhold til, hvad der er muligt, og hvad der skal til – og ikke skal til – for at lancere et værdiskabende produkt.
