Agil procesforbedring

Implementering og forbedring af systemudviklingsmetoder i softwareudviklingsorganisationer er i dag ofte præget af de agile metoder. Selvom principperne bag metoderne er enkle, er implementeringen ganske kompleks og langtfra ofte succesfuld. Denne artikel beskriver hvordan vi i ”Agil Procesforbedring” ser sammenhængen mellem de agile principper og muligheden for at blive en professionel systemudviklingsorganisation

Af Henrik Sternberg

Vores navn og vores motto dækker over vores syn på en professionalisering af softwareudviklingen i Danmark.

Langt de fleste softwareudviklingsorganisationer har længe lidt under at det er ganske svært at tjene penge på at udvikle software. Jo større projekter, jo større er sandsynligheden for at resultatet bliver negativt. I store projekter grænsende til 100 %.

Fra kundens side ser det ikke meget bedre ud. For at imødegå softwareindustriens mangeårige udnyttelse af sit vidensmonopol til at bestemme hvad kunderne havde brug for og hvad prisen for deres ydelser skulle være, har kunden i dag allieret sig med advokaterne og sat dagsordenen for kontraktforhandlingerne mellem kunder og leverandør: Kontrakterne skal sikre at kunderne får den vare de bestiller, til den aftalte tid og den aftalte pris. Umiddelbart er det et forståeligt og logisk skridt, men konsekvenserne er fatale og uoverskuelige. Vi er tvunget ind i et udviklingsparadigme, der byder kunderne at bestille deres IT-løsning på baggrund af detaljerede krav, der er fastlagt uden mulighed for afprøvning, og byder udviklerne at fastsætte prisen og designe og udvikle løsningen uden at kunne afprøve validiteten og business casen. Med det resultat at kunderne ikke får en brugbar løsning OG at leverandøren taber penge på udviklingen.

Vi kalder det at skabe geniale løsninger til de forkerte problemer.

En professionalisering af softwareudviklingen betyder for os at ansvaret for udviklingen af brugbare IT-løsninger til den rigtige pris skal fordeles mellem leverandør og kunde. Kunden har ansvaret for kommunikationen om organisatoriske mål, betingelser og succeskriterier for en IT-løsning. Leverandøren har ansvaret for udvikling af design og løsninger, mens hele projektorganisationen har ansvaret for en beskrivelse og fortsat udvikling af de krav, der skal implementeres på baggrund af. Og leverandøren har bolden!

Som udviklingsorganisation må vi må med alle midler forsøge at overbevise kunderne om at vi har intentionen, midlerne og kompetencen til at indgå som en professionel partner i deres IT-udviklingsprojekter.

Intentionen til på forretningsmæssige vilkår at medvirke til at understøtte kundernes forretningsprocesser med brugbare IT-løsninger.
Midlerne til dette er ikke kun effektive udviklingsværktøjer og -miljøer. Vi har som udviklere bevist mange gange at vi kan udvikle geniale løsninger - hurtigt. Men vi mangler stadig metoder, der kan understøtte et reelt samarbejde mellem alle projektets interessenter om udviklingen – i et dynamiske miljø, der favner forandringer og anser det at lave fejl som en helt naturlig del af læreprocessen.
Kompetencen til at udnytte og udvikle de værktøjer og metoder, der anvendes og kompetencen til at udnytte og udfordre betingelserne for effektiv systemudvikling.

Agile principper

De agile principper og praktikker accepteres i stigende grad i industrien som brugbare til at forbedre udviklingsmiljøet. Principperne understøtter dialog og læring, og det er en forudsætning for at kunne indgå professionelt i et systemudviklingsprojekt, både som leverandør og som kunde.

De agile metoder der er populære i dag, særligt Scrum og XP bygger på det agile manifest, der støtter samarbejde, dialog og læring gennem fejl.

Ofte fokuseres der på implementering af enkeltstående agile metoder i de forsøg der gennemføres i udviklingsorganisationerne for at forbedre afdelingens udviklingskvalitet og –kapacitet. Erfaringerne herfra er tit positive i de enkelte, små udviklingsprojekter, men effekten er ikke altid synlig udenfor projektet, og derfor kan det være svært at fastholde ”commitment” til den type forbedringsprojekter.

Vi tolker de agile principper som evnen til manøvredygtighed. Dette er ikke begrænset til individer eller teams eller små projekter, men kan også anvendes af hele afdelinger og organisationer, ja faktisk mener vi at værdien af de agile principper øges væsentligt ved at udvide anvendelsesområdet. At forøge sin manøvredygtighed som udviklingsorganisation betyder at man skal træffe valg om metoder og praktikker der understøtter dialog og synlighed mellem ALLE organisationens interessenter, og ikke kun i udviklingsteams.

Manifestet og metoderne er relativt nye, men de grundlæggende praktikker og principper er næsten så gamle som vores industri. Siden 70’erne har metodeudviklere talt for anvendelse af iterative, samarbejdende metoder i et forsøg på et paradigmeskift fra fokus på værktøjer og hardware til fokus på systemudvikling som en læreproces.

I ”Agil Procesforbedring” anvender vi de agile principper og praktikker til professionalisering af systemudviklingsorganisationer og softwareprojektorganisationer.

Vi ønsker at implementere inddragende, samarbejdende og anerkendende metoder og teknikker baseret på aktuel viden og erfaring.

Det gør vi gennem deltagelse i debatter, konferencer og diskussioner, gennem uddannelse og træning, og gennem konkrete forbedringsprojekter udviklingsorganisationer.

Udfordringer

Når jeg underviser bliver jeg tit mødt med udbrud som: ”hvor er det ærgerligt at ledelsen ikke er med på dette kursus, de ville kunne lære meget af dette”. For mig er det et udtryk for nogen af de største udfordringer vi har for forbedringer af vores softwareprocesser og professionalisering af udviklingsorganisationer. Ledelsen har fokus på drift og udvikling af hele organisationen og skal ikke bekymre sig om detaljer som konkrete metoder til softwareudvikling. Derfor stiller de ofte bare krav om at udviklingsprojekter skal rapportere fremdrift (læs: tid og ressourceforbrug) og problemer til styregrupperne. Den enkelte styregruppe efterspørger naturligt nok derfor dette med det resultat at projektlederne bliver bedømt og belønnet for at lave projektplaner, der bygger på en rationel tese om at en IT-løsning kan forudsiges, kravene og betingelserne er kendt og relativt stabile, og at konsekvenser ved det valgte design kan forudsiges.

Udfordringen er at valget af systemudviklingsmetode er alt andet end en lokal beslutning. Det har stor indflydelse på hvorledes hele udviklingsorganisationen skal agere. Den positive effekt af indførelse af agile principper kan først høstes når alle interessenter kan deltage i det samme projekt: At udvikle brugbare IT-løsninger til den rigtige pris så hurtigt som muligt i et dynamisk, omskifteligt miljø.