Så lyckas du med ett agilt webbprojekt

Det har under många år varit populärt att säga att man arbetar agilt i sina webbprojekt. Men trots detta missar många projekt målen och krånglar lika mycket som när de drevs mer traditionellt. Vi har jobbat i många olika typer av agila projekt och vi vill dela med oss om varför det inte alltid fungerar och hur man kan driva agila projekt på ett bättre sätt.

Vad innebär ett agilt arbetssätt egentligen? Vår erfarenhet är att det finns lika många olika sätt att se på det hela som det finns människor. Den lite mer officiella bilden är att man har en klar bild över vad man vill åstadkomma. Sedan prövar sig fram, för hur man ska lösa det hela. I sitt beställningsunderlag bör man beskriva vad man vill uppnå. Man kan exemplifiera och visa hur andra har gjort men man bör inte i detalj beskriva exakt hur saker ska utformas. Då finns risken att man låser man in sig och har svårt att arbeta agilt.

Att utgå från en detaljerad kravspecifikation med olika funktionslistor innebär därför ofta ett misslyckande i det agila projektet. Problem uppkommer ofta eftersom leverantörer ska upphandlas och avtal ska skrivas och då är det väldigt få kunder och leverantörer som vågar gå in i ett projekt med så löst definierade krav. Som kund vill man veta vad man får för pengarna och som leverantör vill man veta vad man kan lova. En lösning i praktiken är därför ofta att man skapar ett ramverk i kravspecifikationen så man kan estimera omfattningen men att man från början gör en överenskommelse om att arbeta agilt och att man tillåter större eller mindre avvikelse från kravspecifikationen så länge båda parter godkänner detta. Ofta kan man också behöva upprätta ett agilt avtal mellan varandra som grund för arbetet. Man måste helt enkelt enas om det är pengar, tid eller funktionaliteten som ska styra ramarna.

För att lyckas i projektet måste både kund och leverantör agera agilt och tillåta detta arbetssätt. Ett typisk problem brukar vara att leverantören inte arbetar helt enligt den modell de valt. Om de exempelvis hävdar att de arbetar enligt Scrum men hela tiden måste ta fram interaktionsdesign (UX) och design innan de kan påbörja något i backloggen är detta ett dåligt tecken. Ett väl fungerande Scrum-team ska kunna ta in ett användningsfall (en PBI) och lösa den inom teamet under en sprint. Om det krävs UX eller design så ska medlemmar i teamet kunna lösa detta under sprinten.

Ett annat exempel på potentiellt felaktigt bild på ett agilt arbetssätt är att leverantören själv äger backloggen och att utvecklarna lägger in ärenden där baserat på en kravspecifikation. Detta är sannolikt också tecken på att leverantören arbetar efter ett ganska traditionellt projekt enligt “vattenfallsmodellen”. Även om man sedan visar upp vad man gjort var tredje vecka så är detta ändå inte ett agilt arbetssätt.

Så, om man vill arbeta agilt så bör man, när man väljer leverantör, säkerställa att de verkligen arbetar agilt. Man kan be att få prata med tidigare kunder och man kan be att få vara med och se hela processen i ett pågående projekt. En titt på en backlog ger ofta en bra indikation på hur väl de arbetar agilt. Känner man sedan att man inte har kompetens att avgöra detta själv kan man alltid ta hjälp från någon som kan. Man kan ju också fundera varför man själv vill arbete agilt och ha bra på fötterna för det. Tyvärr är det lite för mycket ett modeord, som många använder, men få förstår vad det egentligen innebär.

En möjlighet som finns under att agilt projekt är att ta fram lösningar som sedan senare i projektet utökas och förbättras. Ett krav kan exempelvis vara att en besökare ska kunna hitta information genom att söka efter den. Man kan då först beställa en enkel söksida som bara löser exakt detta behov. Den går då att använda men har inte allt man tror sig vilja ha på söksidan. Senare i projektet kan man ställa högre krav på att besökaren ska se lite mer information från sidorna och kanske att det ska gå att göra urval. Man kan då bygga vidare på söksidan så att den förbättras. Arbetar man på detta sätt kan man ofta ha en fungerande webbplats redan efter halva projekttiden. Webbplatsen har då naturligtvis inte allt man vill ha men den fungerar och skulle ha ett värde om den lanserades.

Att bara göra en enklare första funktion är dock svårare än man kan tro. I många projekt vill ofta både kunden och leverantören “göra klart” varje del så de inte behöver gå tillbaka igen och komplettera. Utvecklare brukar också ofta säga att det blir dyrare om man inte gör “rätt från början”. Detta tankesätt är inte agilt. Erfarenhet säger att man ofta under projektet lär sig massor så man har mycket större möjlighet att “göra rätt” om man tar fram lösningar i mindre steg. Och ja, man kan ibland helt få kasta bort delar som byggts. Men den slutliga lösningen blir då ofta mycket bättre – och billigare.

Att ta fram en webbplats idag är inte lika banbrytande som det var för 20 år sedan. Vissa moment behöver därför inte vara så agila. Det agila tänket bör främst användas då man är osäker på exakt vad och hur man ska lösa ett visst behov. Att ta fram en meny kan därför vara något man inte lägger så mycket kraft på som produktägare. Man kan ofta peka ut en fungerande meny på en annan webbplats och be leverantören att ta fram en liknande. Om man däremot ska arbeta fram en ny självservice eller presentera information som inte har några bra exempel så bör man arbeta agilt i mindre steg.

Så, baserat på detta är exemplet ovan med att ta fram en söksida agilt kanske inte så bra. Söksidor finns det många av och stora delar av funktionerna är inte varken komplicerade eller svåra att få bra för en besökare. Det kan dock vara så att man har lite speciell information på webbplatsen eller så kan det vara så att man inte bara vill presentera information utan också funktioner i sökresultatet. Då kan det vara idé att ta fram söksidan agilt.

För att summera så är nedanstående bra att ha om man vill lyckas i ett agilt projekt:

Att arbeta agilt är en konst som kräver mycket mer än man kan tro. Det som är absolut viktigast är att man i gruppen sätter sig ner och definierar vad man menar med agilt arbetssätt. Vem har vilken roll och vad innebär rollen? Vilka förväntningar har man på de olika rollerna och personerna? Om man hoppar över det steget, finns det stor risk att man senare blir osams för att budgeten eller tidsplanen inte höll eller att slutresultatet inte alls blev enligt förväntningarna.