6 måneders Scrum-knokleri på Borgen gav intet synligt resultat

Hvordan forklarer man lige chefen, at man arbejder hårdt og målrettet, når der ikke er noget synligt resultat af strabadserne i flere måneder?
Sådan lød den største udfordring for de 6-8 udviklere, der i løbet af 2012 har forberedt opgraderingen af Folketingets vigtigste it-system, TingDok. Et projekt til i alt 10 millioner kroner.
For op mod et halvt år af projektet, der har varet godt og vel et års tid, blev alene brugt på at konvertere funktionalitet fra det gamle system over til den nye version. Dermed var det i lang tid ikke til at se for udenforstående, hvordan arbejdet skred frem.
TingDok er baseret på ESDH-systemet Public 360° og blev opgraderet for dels at få alle Folketingets mange dokumenter - lovforslag, høringssvar, paragraf 20-spørgsmål og den slags - hurtigere ud til medlemmerne og borgerne. Men også for at gøre systemet klar til fremtiden, der blandt andet byder på åbne API'er.
Teknisk projektleder Anders Gilbro Nielsen fra Folketingets it-udviklingsafdeling fortæller her om projektet.
Hvad var målet med projektet?
»Folketinget skulle have udskiftet sin dokumentmotor, ESDH-systemet TingDok. Det var et versionshop fra forældede teknologier og til nye og mere moderne (version 3.1 til 4.1, red.),« siger Anders Gilbro Nielsen til Version2.
»Det betød, at vi skulle lave om i hele den måde, vi integrerer med andre systemer på. Det gav os lejlighed til at lave alting om i henhold til den strategi, vi har om, at folketingsmedlemmer og borgere skal have hurtig adgang til dokumenter, og samtidig kunne vi forberede systemet til åbne API'er.«
»Vores opgave har derfor været at bygge et helt nyt integrationslag, som kan få alle enderne til at mødes mellem TingDok og de forskellige andre systemer, der for eksempel bruges til at håndtere vores flow af lovgivningsdokumenter.«
»Projektet har taget godt og vel et år, og der har været omkring 90 user stories og 700 tasks, så det er temmelig mange opgaver.«
Hvad var din rolle på projektet?
»Jeg har været teknisk projektleder og Scrum Master på alle integrationerne. Min rolle har været at forsyne de administrative projektledere med viden om leverancerne og følge op på, hvordan vi løbende har overholdt tidsplanen,« fortæller Anders Gilbro Nielsen.
Hvilket teknologier/metoder har været anvendt på projektet?
»Vi har valgt Scrum-modellen for lettere at kunne følge op på projektets fremdrift. Vores sprints har typisk været på 11 arbejdsdage fordelt over tre kalenderuger.«
»Vi erkendte ret hurtigt, at vi blev nødt til at have et ekstra møde før selve planlægningsmødet (af næste sprint, red.). Man skal passe på med at tro, at alt er godt, bare fordi man holder et planlægningsmøde. Vi fandt ud af, at vi ikke var så gode til løbende at forberede os til næste sprint, og derfor indsatte vi et backlog-møde en til to dage før selve planlægningsmødet. Det har fungeret godt for os.«
»Bortset fra det har vi i det store og hele arbejdet meget inden for standard Scrum. På softwaresiden har vi brugt Microsoft Team Foundation Server sammen med Urban Turtle (add-on til TFS til planning og task boards, red.).«
Hvilke problemer/udfordringer stødte I på undervejs? Hvordan håndterede I dem?
»Fordi der er tale om en opgradering, har meget af projektet gået ud på at konvertere funktionalitet fra det gamle system til det nye,« forklarer Anders Gilbro Nielsen.
»Derfor har vi haft et fast sæt af mange obligatoriske opgaver, som ikke var til at komme uden om, men bare skulle laves. Det er ikke særlig Scrum-egnet, fordi der ikke ligger nogen prioritering i de opgaver. Efter et sprint vil man normalt gerne kunne vise, at systemet nu kan noget nyt. Men i en lang periode kunne vi bare vise, at det fungerede helt, som det plejede.«
»Vi har for eksempel skullet kode alle de rutiner om, der opdager nye lovforslag og sender dem ud til webben. Og det har gjaldt alle dokumenttyperne i Folketinget.«
»Vores succeskriterium har været, at brugerne slet ikke skulle opdage, at der er kommet et nyt system. Det har givet nogen indtryk af, at der ikke er sket noget som helst med systemet i en lang periode, selvom udviklerne havde arbejdet som heste. Sådan var det nok de første 5-6 måneder, og derfor var det en udfordring at holde produktejerne til ilden, fordi de ikke synes, at der var noget nyt at se. Først senere i projektet, hvor der kom ny funktionalitet, blev det lidt sjovere, men der har vi nok været halvvejs.«
Hvilke gode råd kan du give videre til andre?
»Selvom det umiddelbart ikke ser ud til at være oplagt at bruge Scrum, kan det alligevel være en god idé at bruge det som målevørktøj og til erfaringsopsamling. Det giver mulighed for at følge med i, hvordan det går med teamet og med fremdriften i projektet. Så der kan være masser at hente i metoden, selvom man som os har en stor mængde obligatoriske opgaver, der ikke passer så godt ind i Scrum,« siger Anders Gilbro Nielsen.
»Sørg for at tilpasse Scrum til din egen rytme. Vær ikke bange for at ændre på metoden, så den passer ind i din organisation og dit team.«
»Og så er det værd at huske på de traditionelle dyder i projektledelse som overordnet projektstyring, risikoanalyse og tid til dokumentation og fejlretning. Dem siger Scrum nemlig ikke noget om,« siger Anders Gilbro Nielsen.
Kommentarer (2)
Det er naturligvis svært at sige noget intellegent ud fra den smule der kan stå i en artikel, men min helt umiddelbare tanke er, at 90 stories til 8 mand i et år, lyder som om stories'ne måske er lidt vel store. Det er jo lige før gennemsnitstiden for en story overskrider sprint-længden.
Jeg er personlig meget 'forsigtig' med alle disse projektledelsesmodeller, udviklingsmodeller, teknikker m.m. - fordi hvis de grundlæggende processer, projekt og forudsætninger ikke er i orden, så vil ingen modeller hjælpe dig.
SCRUM er ikke en silver bullet, lige så vel som dem der var hypet før og dem der vil blive hypet bagefter.
Værktøjer skal benyttes med omtanke, og ofte vil der være værdi i at tilpasse og modificerer dem til situationen.

