Agil er blevet et ord, der bruges i flæng, fordi der er en tendens til, at alt skal være agilt, og de fleste vil gerne kalde sig agile. Men mange har misforstået hvad en ægte agil udviklingsproces indebærer. Vi ser mange "agile" IT-projekter, der bliver store og tunge, har alt for meget overlevering, og bruger alt for meget tid på estimering.
Vores metode bygger på agile principper, og du kan læse mere om, hvordan vi arbejder med dem i praksis længere nede:
Det er først, når du sidder med et stykke funktionalitet i hånden, at du kan se, hvad der i virkeligheden er brug for. Når du ser det, ændrer du prioriteter, og tidligere projektplaner og estimater er ikke længere relevante.
Vi ved, at det er sådan, verden fungerer, og vi har tilrettelagt vores metode efter det: Vi viser dig med det samme, hvad vi har udviklet, og så fortæller du os, hvordan du gerne vil have, at vi videreudvikler det. Sådan skaber vi et bedre produkt.
Du skal kunne se, hvad vi laver, og hvordan det kommer til at se ud og fungerer. Derfor starter vi altid en opgave med at lave en brugerflade, hvor alle data og processer er synlige. Som opgavestiller kan du konstant se og interagere med det, vi bygger til dig. Din feedback driver hele tiden næste iteration.
Fordi vi altid bryder projekterne op og starter med en grundlæggende brugerflade, kan vi begynde at levere de første elementer og features inden for få dage. Du får hurtigt adgang til et testsite eller prototype, så vi sammen arbejder i den rigtige retning.
Vi bruger altid Continuous Delivery - i samme øjeblik en udvikler har skrevet og afleveret et stykke kode, er den tilgængelig på test-systemerne. Vi arbejder ikke med Feature Branches, men bruger i stedet metoder som Feature Switches tilgængelig i brugerfladen til konstant at levere funktionalitet.
Har du nogensinde oplevet, at estimaterne og planerne i dit softwareudviklingsprojekt endte med at holde? Det har vi heller ikke. For mens man udvikler, bliver man klogere, og nye behov opstår.
Når man undervejs i et projekt får en forbedret indsigt, vil det være logisk at skifte spor og kode det, som man nu har erkendt, er den bedste løsning. Men mange organisationer fortsætter med at levere efter den oprindelige plan, og de lægger de nye indsigter ned i en "backlog". Herfra skal de så estimeres og tages ind, "når der bliver tid".
Backloggen bliver et sted, hvor nye, gode ideer går hen for at blive forældede og dø. Og sådan skal det ikke være. Derfor har vi slået backloggen ihjel.
Hos os er det indlysende, at gamle ideer må vige for de nye, når man sammen med brugerne har identificeret en bedre funktionalitet.
Vi elsker ændringer! Og det er hemmeligheden bag det, vi kunne kalde ægte agile. Ændringer kommer, når man er blevet klogere og har fundet en bedre måde at gøre tingene på. Og det skal man kunne elske for at arbejde ægte agilt.
Derfor giver låste sprints og en backlog ikke mening for os, og metoden er grundlæggende ikke agil. Den stammer fra Scrum med sin stive cyklus og "kunde-surrogater" i form af Product Owners. Hos ITCI arbejder vi ikke efter Scrum eller SAFe, som vi betragter som en voldsom misforståelse og modsætning til "produkt over processer".
Vores arbejdsmetode har en række andre konsekvenser, fx arbejder vi i ITCI ikke i store projektgrupper, der kræver en masse koordination og overlevering mellem teams. Vores erfaring er, at jo større projekterne bliver, desto mere tid bruger man på at koordinere dem, og jo dårligere bliver evnen til at respondere på brugernes ny-erkendte behov.
Vi bruger i stedet tiden og ressourcerne på at snakke med brugerne, bryde opgaven ned, løse det mest indlysende først og hurtigt bringe resultaterne i hånden på brugerne. Vi er hurtige til at bygge, men lige så hurtige til at tilrette løsningerne efter dine tilbagemeldinger. Vi er altid fleksible og kan altid justere løsningerne – uanset hvor mange gange, du kommer i tanke om en ændring, du gerne vil have med.