Det agila manifestet har funnits länge och är skåpmat för de flesta men många organisationer står inför, eller har precis påbörjat, att införa mer agila sätt att arbeta med utveckling av IT. Hur påverkar det slutresultatet och ökar det chansen för verksamheten att få de system och lösningar som de behöver?
Här kommer jag beskriva en del av de problem rörande krav och behov som jag upplevt i samband med att man växlar över till agila arbetssätt och vad jag anser att både verksamhet och IT-avdelning behöver tänka på för att verkligen nå de resultat man vill ha.
Agila metoder innebär ofta att man lämnar en klassisk – och kanske tungrodd – metodik och istället flyttar sitt fokus mot ett mer adaptivt och situationsanpassat sätt att samarbeta. RUP uppfattades ofta som tungt, med mängder av dokumentation som skulle genereras utifrån färdiga mallar, av specifika roller och enligt definierade arbetsflöden. Man försökte slaviskt följa alla instruktioner men misslyckades ändå ofta med att leverera lösningar som uppfattades som bra och som gav de effekter som man behövde. Dessutom kände nog många att man skapade en väldig massa dokument som ingen sedan använde. Det blev ibland viktigare att följa planen än att nå rätt mål.
Många såg det därför som befriande att istället fokusera på individer och interaktioner mellan dem, fungerande programvara framför omfattande dokumentation och anpassning framför att följa en plan. Att arbeta i team som klarar av de uppgifter de tilldelas utan att någon skriver dem på näsan hur de ska organisera sig eller exakt hur de ska utföra sitt arbete.
Tidigare lade vi dessutom ofta ned enormt mycket tid på att försöka detaljbeskriva mål, behov och krav innan vi ens skrev den första raden kod. När vi sedan levererade lösningen så visade det sig ofta att de detaljerade målen, behoven och kraven faktiskt inte riktigt stämde – antingen för att förutsättningarna ändrats eller för att vi inte riktigt förstått och därför gjort en del felaktiga antaganden.
Nu vill vi istället genom kontinuerliga förbättringar som stäms av stegvis ta fram lösningar som ger den nytta som behövs. På så vis kan vi anpassa och lära oss mer om mål och behov under resans gång, och löper inte samma risk att tidigt ta felaktiga beslut som sedan lever kvar i den slutliga leveransen.
Frihetens pris
Men lyckas vi alltid bättre bara för att vi tar till oss ett mer agilt arbetssätt?
Givetvis gör vi inte det, och det finns en mängd faktorer som påverkar hur väl vi lyckas med IT-projekt. Storlek och komplexitet på lösningen samt tillgång till kompetenta resurser påverkar fortfarande i stor grad våra möjligheter att lyckas med IT-projekt oavsett arbetssätt. Är verksamheten inte med i det agila arbetet tappar vi lätt möjligheten att stämma av det vi levererar och får därmed inte hjälp att stegvis förstå mål- och problembild, och en del av fördelarna med att arbeta agilt försvinner. Köper vi in en färdig lösning eller känner till alla krav redan från början är det långt ifrån säkert att ett agilt arbetssätt blir mer effektivt.
Jag upplever samtidigt att en del av de problem vi har beror på hur vi hanterar den frihet som det agila innebär. De agila arbetssätten är generellt friare än exempelvis RUP vilket gör att vi – på gott och ont – inte får så mycket hjälp med hur vi ska arbeta, vad vi ska skapa, eller vem som ska göra det. Många gånger innebär detta tyvärr att vi glömmer bort viktiga delar i utvecklingsarbetet.
Behovet av kompetens finns kvar
Min erfarenhet är att transformation till agila arbetssätt och organisationer ofta innebär att man kastar ut de detaljerade rollbeskrivningarna som funnits för projektarbete, de detaljerade arbetsbeskrivningarna och alla mallar som tidigare använts. Och inte sällan innebär denna frihet att man glömmer bort att vi – även om vi arbetar på ett nytt sätt – behöver utföra mer eller mindre samma arbete som vi gjorde då vi arbetade enligt klassiska utvecklingsmetoder. En backlogg uppstår inte spontant ur tomma intet, den behöver vara välgrundad även om alla detaljer inte behöver vara på plats innan vi börjar utveckla och den behöver anpassas och förbättras över tid. Teamet som utvecklar och arbetar med systemet kanske inte finns kvar under hela systemets livstid eller ens förvaltar systemet, och det kan då behövas dokumentation över hur systemet ska fungera.
Även om vi kastat ut alla rollbeskrivningar behöver vi fortfarande rätt kompetenser. En del är uppenbara – har vi ingen resurs som kan programmera så blir inget utvecklat. Andra kompetenser ter sig självklara, men glöms enligt min erfarenhet bort i olika omfattning. Har ingen person tillräcklig kompetens inom IT-arkitektur så riskerar vi att skapa en lösning som inte passar in i befintlig och framtida IT-miljö. Har ingen tillräcklig kompetens inom test riskerar vi att inte genomföra tillräckliga integrations-, prestanda- eller penetrationstester. Olika personer har ofta djupare kompetens inom en eller ett fåtal olika kompetensområden men sällan i ett flertal. Även om det tjatas om att utvecklare behöver ha kunskap om verksamheten är jag benägen att tro att utvecklare med spetskompetens och djupa kunskaper om verksamheten eller affären inte växer på träd. För att få rätt kompetens behöver vi ofta använda specialister, och vi behöver ofta ett antal olika människor med olika kompetens. Att vi inte beskriver vilka roller som har vilka ansvar ändrar inte på detta, men det verkar ibland göra att det glöms bort.
En av de roller som försvunnit med det agila arbetssättet är kravanalytikern. Det åläggs ofta produktägaren att skapa och underhålla backloggen samt att ta fram user stories som kan användas för att bygga en lösning som på ett effektivt sätt skapar nytta, samtidigt som produktägaren ska vara beslutsfähig med förståelse för hur olika beslut påverkar affären eller verksamheten. Detta fungerar utmärkt i vissa fall, men långt ifrån alltid. Ibland beror det på att det blir svårt för en person att hinna med allt, ibland för att det faktiskt krävs djup kompetens inom flera olika områden än vad en enskild person har.
Vi behöver personer med kompetens att hjälpa intressenter att beskriva sina faktiska behov, att skilja mellan önskemål och behov, att få fram en kravbild som accepteras av relevanta intressenter och som är beskriven på ett sätt som gör den förståelig för de som ska använda den. Vi behöver personer som kan analysera och förstå konsekvenserna av hur olika krav påverkar lösningen och hur man arbetar med den. Vi behöver även personer med kompetens att designa en lösning som uppfyller de behov intressenterna har både i form av systemkrav och användbarhet.
Vi blandar ihop utveckling och lösning
Fokus i det agila arbetet ligger ofta på själva utvecklingen och det arbete som ska utföras för att leverera en bra lösning. Man missar då lätt att det är en viktig skillnad mellan vad vi skapar eller ändrar och den slutliga lösningen. Vi använder Kanban-tavlor eller Jira, följer upp burn down som visar vad vi gör, skapar eller ändrar, men glömmer lätt bort att dokumentera lösningen som helhet. Detta problem har alltid funnits då projekt ofta är mer intresserade av att veta vad de ska utföra och leverera snarare än hur hela lösningen de lämnar efter sig faktiskt fungerar och har för egenskaper. Enligt mig är det senare dock ofta lika viktigt eftersom det behövs en förståelse för hur lösningen fungerar och hur den kan användas. Det är svårt att skaffa sig en uppfattning om hur ett system fungerar baserat på ett antal aktiviteter som utförts eller user stories som implementerats i olika sprintar. Vi behöver alltså förstå skillnaden mellan krav på en förändring och krav på en helhet. Krav på en förändring behövs för att vi ska förstå vilken förändring vi ska göra, och kan och generellt ses som en beskrivning av ett arbete som ska utföras. Denna beskrivning rör utvecklingen och har en livscykel som tar slut då ändringen implementerats – den är ett arbetsdokument som gäller projektet. Krav på en helhet behövs för att vi ska förstå hela lösningen och inte bara de förändringar som gjorts i ett projekt. Dess livscykel ska vara densamma som lösningens, det vill säga genomförs en ändring av lösningen ska krav på helheten uppdateras så att vi alltid har en korrekt bild av lösningen – den är en ett produkt-/lösningsdokument. Beroende på vilka behov som finns hos utvecklare, test och förvaltning kan detaljnivån mellan dessa två typer av krav behöva skilja sig. Och behövs inte den ena typen ska vi självklart inte dokumentera dem i onödan. Men vi måste förstå skillnaden mellan dessa två typer av krav.
Min erfarenhet är att krav på helheten inte alltid tas fram och att de sällan underhålls tillsammans med lösningen. Jag har själv levererat lösningar där beställaren absolut inte velat ha en helhetsbild utan bara varit intresserad av förändringar, och efter ett par releaser inte haft en aning om hur lösningen faktiskt är tänkt att fungera.
Tanken är att det är det agila teamet som ska förvalta och vidareutveckla IT-lösningen, och då behöver kanske inte lösningen dokumenteras – teamet har kunskapen som behövs. Men det är sällan som teamet består under hela lösningens liv eller ens är de som ska förvalta systemet. I dessa fall kan det vara viktigt att faktiskt dokumentera lösningen.
Slutsats – frihet under ansvar
Friheten är bra, men friheten gör att vi verkligen behöver fundera igenom vad som behövs i form av resurser och leveranser i varje enskilt fall.
Det gäller att skaffa de resurser som krävs. Vi behöver bland annat se till att vi har personer med kompetens inom verksamhets- och systemkrav. Dessa personer behöver kunna arbeta tillsammans med utvecklingsteamet såväl som med intressenter, men vi måste vara noga med att vi inte skapar en uppsättning filter mellan intressenterna och de som ska implementera lösningen. En del av detta ansvar ligger hos dessa personer i och med att inte får förvanska krav och behov eller skapa krav utan egentliga behov bakom sig, men vi behöver också se till att dessa resurser får tillgång till intressenter i den omfattning som krävs så att de får korrekt information då den behövs.
För att säkerställa att vi inte missar något borde vi snegla på mer traditionella utvecklingsmetoder för att se till att vi inte glömmer viktiga leverabler, aktiviteter eller kompetenser då vi arbetar agilt. Se till att leverera vad som behöver levereras – inte bara i form av förändring utan även vad gäller exempelvis beskrivningar av hela lösningen. Gör klart vad som behöver dokumenteras, vilken detaljnivå olika typer av dokumentation behöver hålla – till exempel förändringsbeskrivningar kontra lösningsbeskrivningar.
Vi måste se till att en agil organisation och ett agilt arbetssätt inte bara blir ett sätt att banta utvecklingskostnaderna genom att glömma eller skala bort kompetenser och aktiviteter som faktiskt behövs.
Jakob Bäckström, konsult och associated partner