I en agil organisation hvor Scrum er det bærende element for teamene kan det være svært at håndtere store opgaver som f.eks. lovkrav vedtaget af Folketinget, EU eller andre instanser. En rygmarvsreaktion kan være at sætte den iterative og inkrementelle udvikling på pause og begive sig ud i en længerevarende analyse som udmønter sig i en detaljeret nedbrydning af opgaven. Det er ikke ønskværdigt – hverken for den agile organisation eller for det enkelte teammedlem som ender med at bygge til lager frem for til produktion.

Udfordringen kan naturligvis løses. Gitte Kaalund, afdelingsleder i Bankdata, udtalte:

Det vigtigste når man løser et lovkrav er at se det som et forløb hvor man løbende tilfører funktionalitet til systemerne samtidig med værdi til brugerne og ikke som én stor samlet leverance ved udløb af deadline

Én måde at håndtere lovkrav med Scrum er at opdele lovkravene i spiselige bidder. Det kan gøres på mange måder. Nedenfor er Én måde at gøre det på:

1. Skab overblik
2. Definer formål, benefit og mål
3. Rangér tema, epics og enabler
4. Behandl epics og enabler epics
5. Ranger feature og enablers
6. Nedbryd features og enablers i stories

Skab overblik

Tidligt i processen skabes et overblik over hvilke temaer, epics og enabler der berøres i lovgivningen. Dette er første bud på hvilket omfang opgaven har.

Et tema er en overordnet gruppering i lovkravet og kan f.eks. være “Retningslinjer for aflønningspolitik og -praksis i forbindelse med salg og levering af detailbankprodukter og -tjenester.” fra boligkreditdirektivet. Temaet driver den ændring der skal skabes i system og produkt for at indfri lovkravet.

En epic er en ligeledes en gruppering, dog på mere løsningsnært niveau, men abstrakt nok til at kunne arbejde inkrementelt med MVP iterationer. Eksempler på epics er “Adgang til at udøve virksomhed som kreditinstitut og om tilsyn med kreditinstitutter og investeringsselskaber”, “Forbrugerkreditaftaler i forbindelse med fast ejendom til beboelse”, “Betalingstjenester i det indre marked” og “Adgang til at optage og udøve virksomhed som udsteder af elektroniske penge og tilsyn med en sådan virksomhed.”.

En enabler er en understøttende gruppering der primært bruges til at udbygge og forberede systemarkitekturen så de identificerede epics kan leveres.

Definer formål, benefit og mål

De identificerede temaer, epics og enablers beskrives alle med formål, benefit og mål der både er med til at afgrænse opgaven men samtidig også med til at kommunikere opgaven til de involverede.

Formålet beskriver hvilke kunder der er i målgruppen og hvilket behov de ønsker at få dækket. Benefit angiver hvilke kvantitative og kvalitative forbedringer målgruppen kan forvente hvis formålet bliver indfriet. Mål angiver hvilke løbende målinger der kan foretages på “outcome” for at verificere at løsningen er på rette spor.

Ranger temaer, epics og enabler

Uafhængige temaer rangereres over for hinanden ligesom epics og enablers rangeres indbyrdes overfor hinanden. Fælles for de forskellige typer er at de alle rangeres efter forventede omkostning ved en eventuel forsinkelse. Det er essentielt at fokusere på at minimere risiko i forbindelse med udvikling af lovkrav. Ikke alle lovkrav skal indfries samtidig; visse har en mindre omkostning forbundet med forsinkelse end andre. Det kan være svært at kvantificere omkostninger forbundet med forsinkelse præcist, hvorfor det ofte anbefales at gøre det relativt f.eks. med business value poker kort eller tilsvarende.

Behandl epics og enabler epics

De involverede teams og deres Product Owners har nu en indikator for hvilken rækkefølge de bør behandle lovkravene. Én efter én nedbrydes de i features og enablers der kan løses på maksimum 2-3 måneders sigt og har beskrevet med formål, benefit og formål. Det kan være værdifuldt at identificere fremtidige features og enablers, men undlad at gå for meget i detalje med epics og enablers der ligger ude i fremtiden.

Ranger feature og enablers

På samme vis som temaer, epics og enabler rangeres de nedbrudte features og enablers efter omkostning ved forsinkelse. Det er typisk lettere at kvantificere omkostningen på de nedbrudte elementer, da denne kan beregnes som en fraktion af det overordnede tal.

Nedbryd features og enablers i stories

Teamet kan nu planlægge og nedbryde features og enablers i rangeret orden så de individuelt kan være i et sprint og samlet udgør første iterative inkrement på featuren eller enableren.

Ja, lovkrav og Scrum kan godt lade sig gøre!

At arbejde iterativt og inkrementelt med lovkrav indebærer en naturlig risiko, da man ofte er nødt til at udvikle software i parallel med at lovteksten bliver godkendt. Det gør at man antager at første iteration af en feature også kan anvendes når den endelige lovtekst bliver godkendt. Det er naturligvis en risiko som kan håndteres – f.eks. ved inddragelse af eksperter og brugere.

Det kræver et stærkt setup med et stabilt udviklingsteam, erfaren Product Owner og erfaren Scrum Master. Til sammen skal de sikre at relevante interessenter giver input og at processen i forhold til at arbejde inkrementelt og iterativt bliver efterlevet. Opnår man det, så får man et helt team der kommer tættere på hinanden fagligt og socialt samtidig med at føler at deres erfaring og kompetencer kommer i spil på rette vis!

Indlægget er også udgivet på Ugilic’s blog.