Denne klumme er et debatindlæg og er alene udtryk for forfatterens synspunkter.
Jeg oplever, at flere og flere virksomheder har udfordringer med at køre agil udvikling, hvor det løbende planlægges og designes af det enkelte team, hvad der skal udvikles i to-tre ugers udviklingssprints.
Resultatet er ofte, at der mangler planlægning af og commitment til de samlede leverancer, og at der ikke er en udviklingsroadmap.
Tilbagemeldingen fra udviklingsteams bliver i stedet en status på, hvad de arbejder på lige nu, men ikke hvornår de regner med at være færdige og klar til test og efterfølgende lancering.
Derved mangler der forudsigelighed, og det er svært at forventningsafstemme både internt og overfor kunder og samarbejdspartnere.
Jeg er selv tilhænger af en pragmatisk tilgang, hvor agile udviklingssprints – der bestemt giver god mening – kombineres med en planlægning af en udviklingsroadmap.
Denne skal baseres på en samlet prioritering, og for det enkelte projekt skal de grundlæggende krav og ambitioner være klare, diskuteret og vurderet i tæt dialog mellem forretningen og it.
Konkrete krav er ikke i modstrid med at definere det detaljerede design i agile sprints
En del tilhængere af agil udvikling er imod kravspecifikationer, da løsninger og design i stedet bør ske løbende i udviklingssprints.
Argumentet for det er, at teamet kan vurdere, hvad der skal til, og hvordan det bedst løses, i stedet for at tvinges til at bruge for lang tid på at bygge, hvad der præcist er stillet krav om i en kravspecifikation.
Jeg mener imidlertid, at det er et spørgsmål om at finde den rette balance:
- Ønskes der eksempelvis en ny webshop giver det mening initielt at opstille krav.
- Kravene behøver ikke være mere detaljerede, end at der stadig er vide rammer for, at det endelige design kan fastlægges løbende i udviklingssprints (se eksempel nedenfor).
- Efter at have gjort sig indledende tanker om løsning og krav til denne, bør udviklere involveres, så scope og løsning i fællesskab kan justeres til.
- It får derved stor indflydelse på både konkrete løsninger og mulighed for at levere push-back ifht. hvad der er let at lave, og hvad der kræver mere.
- Standard er dansk og danske kroner.
- Brugeren skal kunne skifte sprog til engelsk og/eller valuta til euro.
- Præferencer skal huskes til næste besøg.
Roadmap kan planlægges med overordnede estimater og buffer
Forretningen bør foretage en samlet prioritering af projekter og sammen med it fastlægge et bud på en samlet udviklingsroadmap.
Estimater vil altid have en betydelig usikkerhed og udover at der bør lægges en betydelig buffer oveni, bør der tilsvarende være luft til forsinkelser af lanceringer.
Det sidste er ikke mindst vigtigt, hvis der skal kommunikeres tidspunkter ud til kunder og andre samarbejdspartnere.
Roadmapstyringen skal sikre at:
- Alle ved hvad der er vigtigst og hvad der skal fokuseres på.
- Alle relevante interessenter har været inde over og vurderet omfang og hvad de tror er muligt.
- Alle er med til at flagge det, hvis/når planerne skrider og det skal diskuteres, hvordan det kan løses (eksempelvis ved at justere scope, replanlægning og/eller omprioritering).
- At der er fokus på ikke kun hvad der laves lige nu (i dette udviklingssprint), men også det mere langsigtede.
- At der løbende er er mulighed for at justere planer og prioritering, og hvor konsekvenserne da er synlige.
’Fuldt agilt’ uden krav kan i nogle tilfælde give mening
Selv om jeg argumenter for at supplere en agil udviklingstankegang med en mere overordnet styring ud fra konkrete krav, er der situationer, hvor et fuldt agilt set-up kan give mening.
Med fuldt agilt refereres til, at selvstyrende teams ud fra helt overordnede målsætninger selv definerer scope, løsninger og design.
Det kan nemlig give mening, hvis eksempelvis en bank ønsker, at der løbende er fokus på at lave små forbedringer af deres netbank-app ud fra brugernes input.
Da er der ikke brug for en samlet, overordnet prioritering og planlægning, men et team, som inkluderer repræsentanter for forretningen, vil selvstændigt kunne ’køre derudaf’ og sikre optimeringer.
Gode råd
Jeg vil runde min klumme af med følgende 10 gode råd:
- Stå fast på, at der er nødt til at være en overordnet planlægning af roadmap.
- Sørg for hård prioritering af projekter for at sikre fokus.
- Vær realistisk og indsæt rigelig buffer.
- Skriv overordnede krav til projekter og involver it meget tidligt i processen.
- Juster både krav og løsninger ud fra input og push-back fra it.
- Hav stærk fokus på need to have.
- Beskriv krav som grundlæggende krav og evt. med input til konkret løsning, men hvor kravene er det afgørende.
- Lad udviklingsteams køre agile processer i udviklingssprints.
- Sørg for løbende diskussion og forventningsafstemning af, om projektet er on track og om der er udfordringer, der skal løses.
- Kommuniker at forsinkelser kan opstå, det vigtige er at alle gør hvad de kan for at følge planerne og at de reagerer proaktivt, når der er ved at opstå udfordringer.
Klummer er læsernes platform på Computerworld til at fortælle de bedste historier, og samtidig er det vores meget populære og meget læste forum for videndeling.
Har du en god historie, eller har du specialviden, som du synes trænger til at blive delt?
Læs vores klumme-guidelines og send os din tekst, så kontakter vi dig - måske bliver du en del af vores hurtigt voksende korps af klummeskribenter.
