Debattartikel om agila projekt

Framgång för agila projekt bedöms av beställarorganisationen - inte av utvecklingsteamet!

Vad är då ett framgångsrikt projekt? En leverans framtagen av ett motiverat och välmående team som därmed har levererat med optimal fart och hög kvalitet? Nej, det räcker inte. Attinnehållet också måste vara rätt är inte kontroversiellt. Arbetar vi enligt agila principer ökar vi chansen att vi kommer att levereradet som användarna behöver, inte bara vad de trodde att de behövde när projektet började.

Genom korta iterationer med möjlighet till återkoppling och omprioritering efter varje iteration skapar vi förutsättningar för att leverera rätt saker. Vi placerar också en kundrepresentant i teamet med en på papperet enkel uppgift, att bara se till att ha en lista på unikt prioriterade krav uppdaterad under hela projektet. Men det är nu det ofta blir svårt. För det talas väldigt lite idag om hur ett jobbigt och komplext arbete ska göras, både innan men framför allt parallellt med att man börjar utveckla och leverera utifrån kravlistan.

För trots att vi har skapat goda förutsättningar för projektets framgång har vi inte berört en av de viktigaste paramtrarna: att lösningen mottas positivt vid leverans. Kundrepresentanten är ofta utvald för det djupaste kunnandet hos kunden inom området. Vi hoppas därmed bygga den optimala lösningen, men projektet kan fortfarande uppfattas som misslyckat för att slutanvändarna inte känner att man lyssnat tillräckligt på dem.

Min egen erfarenhet och min tolkning av rapporter som Standish Groups The Chaos Report 2009 är att vi inte längre blir bättre på att uppnå vad som anses vara framgång med genomförda projekt. Däremot anser jag att vi blir bättre på att bygga bra lösningar genom högre teknisk mognad, bättre projektmetodik och högre fokus på motiverade individer.

Tyvärr är allt för många av dagens agila förespråkare lite för teknikfokuserade och därmed kanske lite för naiva i sin inställning till hur större agila projekt behöver genomföras. Att vi behöver ha en långsiktig planering för projektgenomförandet, hantera förväntningar hos beställaren kring vad som kommer att levereras, aktivt arbeta med risker och andra klassiska projektledaruppgifter innebär inte att vi är "oagila". Det innebär däremot att vi förstår att det agila projektet levererar sin nytta i ett större sammanhang.

Allt för sent inser många svårigheten att få beslutsfattare, områdesexperter och intressenter att aktivt delta i projektet när det väl är igång. Visst kan man i bästa fall få några av dem att besöka demonstrationerna i slutet på iterationerna. Men när mottagarorganisation och slutanvändarna är distribuerade och har komplexa hierarkier men ändå i slutänden är med och bedömer resultatet, uppstår svårigheter. Risken är att man möts av just "Bra lösning - men ni har inte pratat med oss".

Framgång når vi om vi säkerställer att vi kan hantera förväntningarna hos dem som avgör om vi lyckas eller inte! När ni tar steget över till att införa agila arbetssätt, säkerställ då att ni inte glömmer den kontinuerliga kravhanteringen under projektets genomförande. Lämna inte er produktägare ensam med ansvaret att samla in och prioritera kraven samtidigt som denne ska förankra, missionera och säkerställa projektframgången.

De agila ramverken och metoderna talar väldigt lite om hur produktägarens kravinsamlings- och förankringsarbete bör genomföras. Precis som team och Scrum Master behöver coachning, ramverk och stöd, behövs detta även för produktägaren och organisationen runt. Genom att inte underskatta produktägarens roll, vikten av kontinuerlig kravhantering och förankringsarbete under projektets genomförande ökar ni sannolikheten för att just ert projekt möts av ett "Vilken bra lösning - det här är precis vad vi behöver"!

Publicerad i Projektvärlden nummer 2 - 2010