From good to great #1: Be agile, not fragile.

Del 1 - "Var agil. Inte fragil."

Låt oss inleda den här första artikeln med att prata om agila metoder. Jag är övertygad om att den agila rörelsen, eller kanske den agila revolutionen är ett bättre ord, har medfört enorma fördelar för branschen som helhet. Med det sagt anser jag däremot att agila metoder i allmänhet saknar några viktiga affärsrelaterade ingredienser. Ett av de viktigaste syftena med agila metoder har alltid varit att föra verksamhet, affär och teknik närmare varandra men min erfarenhet är att detta affärsfokus sällan eller aldrig är någonting som betonas tillräckligt. Agila metoder som Scrum, Kanban med flera är fortfarande väldigt tekniskt fokuserade och användardrivna, vilket ofta resulterar i bräckliga mjukvarulösningar som inte är tillräckligt verksamhetsanpassade. Att involvera verksamheten och affären i utvecklingsprocessen på riktigt har därför potential att lyfta mjukvaruutveckling till en ny nivå som gör att vi kan vara agila men inte fragila.

Helvetesgapet - Förväntningar vs. leverans

För några år sedan förändrade den agila rörelsen helt hur vi såg på, planerade, utvecklade och släppte mjukvara. Vi gick från att arbeta i inramade, stängda faser, där varje fas tog ganska lång tid och var tvungen att vara helt klar innan nästa fas startade. Som ni alla förmodligen vet är det vad vi idag, föga smickrande, benämner som vattenfallsprocesser. Alla krav undersöktes och analyserades innan vi började bygga själva mjukvaran och oftast var de som arbetade med krav inte samma personer som sedan utvecklade själva lösningen. När kravfasen väl var utförd överlämnades kraven till utvecklingsteamet. Denna, oftast enorma, hög med krav sågs därefter som den "enda sanningen" och mjukvaran byggdes från början till slut baserat på dessa krav, ofta utan någon särskilt omfattande kommunikation med kunden. Efter några månader, eller till och med år, levererades slutprodukten till kunden och naturligtvis missade vi ofta målet. Kunden fick en fruktansvärt dyr mjukvarulösning som gjorde mer eller mindre exakt det som stod i kraven, men trots detta var kunden missnöjd eftersom det inte alls var vad de hade förväntat sig.

Den olyckliga klyftan mellan det förväntade och det levererade berodde mestadels på två problem. Ett av problemen har till största del lösts av agila metoder medan det andra problemet fortfarande består i de flesta mjukvaruutvecklingsprojekt. Det första problemet var att både krav och förväntningar tenderar att förändras ganska mycket över tid. När mjukvarulösningen väl lanserades hade delar av kundens verksamhet förändrats i mindre eller större omfattning, vilket innebar att delar av kraven som formulerades i den tidiga kravfasen hade blivit utdaterade. Dessutom hade kundens egentliga förväntningar, vilka troligtvis aldrig ens noterats, sannolikt också förändrats. Eftersom vi lämnat kravfasen bakom oss och var fullt upptagna med att koda istället för att kommunicera med kunden gick dessa outtalade förväntningar oss troligen helt förbi.

Den agila rörelsen började ta ordentlig fart i början av 2000-talet i samband med lanseringen av det agila manifestet som författades av en grupp extremt inflytelserika personer, inklusive Kent Beck, Martin Fowler and Robert "Uncle Bob" Martin. Personer som sågs och fortfarande ses mer eller mindre som kungligheter eller rockstjärnor inom mjukvaruutvecklingsbranschen. Det agila var en motreaktion mot det faktum att statiska, fasbaserade utvecklingsprocesser resulterade i en så hög grad av misslyckade mjukvaruutvecklingsprojekt. Istället för att arbeta i låsta, linjära faser enligt vattenfallsmodellen, introducerade det agila en helt ny attityd och approach där man arbetade i korta iterationer, i nära sammarbete och dialog med kunden. I varje iteration analyserade och förfinade man en mindre mängd relaterade krav tillsammans med kunden och en isolerad och begränsad mängd funktionalitet utvecklades baserat på de nyligen utredda kraven. Den agila metodiken förde dels med sig en helt ny förmåga att reagera på och att hantera förändringar snabbt och dels en kontinuerlig kontrollmekanism där kunden hela tiden hade insyn i vad som pågick och därmed kunde försäkra sig och utvecklingsteamet om att de faktiskt var på rätt väg och byggde rätt saker.

Halvfullt eller halvtomt

Agila utvecklingsmetoder har utan tvekan varit till stor fördel och har inneburit ett ordentligt språng framåt för mjukvaruutvecklingsbranschen. Även om vi kan unna oss själva att luta oss tillbaka och skratta åt vilka klantskallar vi var på den gamla, inte så goda tiden så vill jag hävda att agila metoder i sig själva inte är någon universallösning till framgång och att de hittills oftast bara har tagit de flesta mjukvaruutvecklingsprojekt halvvägs mot verklig framgång. Min erfarenhet är att de agila metoder, såväl som andra utvecklingsmetoder, som tillämpas idag fullständigt saknar ett antal vitala ingredienser, vilket leder till att vi fortfarande ofta missar målet, även om inte lika grovt som tidigare.

Innan jag pladdrar vidare tänkte jag att det är på sin plats att komplettera mitt allmänna tyckande med lite hårda fakta. Vartannat år publicerar The Standish Group en studie som kallas The CHAOS Report. Studien, som betraktas som en tillförlitlig auktoritet inom området, bedriver kontinuerlig forskning kring graden av framgång i IT-projekt baserade på agil metodik i jämförelse med vattenfallsmetodik.

 

De IT-projekt som undersöks delas in i de tre kategorierna lyckade, utmanade (d.v.s. delvis misslyckade) och misslyckade. Det som alla CHAOS-studier som publicerats under det senaste decenniet (den senaste från 2019) mynnar ut i är att agila processer tydligt har påverkat och höjt andelen lyckade projekt samtidigt som andelen misslyckade projekt har minskat i motsvarande omfattning. Det är naturligtvis fantastiskt men en väldigt intressant aspekt, som leder till en del frågor och som stödjer mitt lite kaxiga påstående att agilt i sig självt kanske inte är det bästa grejen sedan skivat bröd, är att andelen utmanade (alltså delvis misslyckade) projekt fortfarande är ungefär densamma för agila projekt och vattenfallsprojekt.

Fråga inte användaren

Så låt oss ta en titt på hundratusenkronorsfrågan. Hur kommer det sig att agila projekt fortfarande delvis misslyckas i inte mindre än hälften av fallen!? Så borde det väl ändå inte vara!? Jag menar, kom igen nu, det kan bara inte stämma. Vi arbetar ju i högkompetenta, självorganiserande utvecklingsteam där vi fortlöpande utreder och förfinar våra krav och levererar ny funktionalitet var och varannan vecka som kunden kan ge feedback på. Dessutom pratar vi fram och tillbaka med slutanvändarna om vad de vill ha och vad de behöver.

Nu ska jag sticka ut hakan igen och riskera att bli idiotförklarad och hånad av varje mjukvaruutvecklare och projektledare, för att inte tala om varje UX-specialist, med ett uns av självrespekt.

Till att börja med tror jag att den höga andelen delvis misslyckade agila projekt orsakas av en olycklig klyfta mellan krav, leverans och verkliga affärsbehov. Ok, men det var väl inte så särskilt kontroversiellt? Låt mig då ställa en ganska enkel fråga till dessa utvecklare, projektledare och UX-specialister. Hur ska vi ta reda på vad den mjukvara som vi ska utveckla faktiskt förväntas göra? Eftersom det kanske är den allra heligaste sanningen i mjukvaruutvecklingskretsar, som lärs ut i varenda mjukvaruutvecklingsutbildning i hela världen, så skulle jag säga att det är ganska sannolikt att svaret blir “Fråga användarna”.

Ok, men “fråga användarna” låter väl ändå som ett klokt och rimligt svar? Användarna är trots allt de som ska använda vår nya, glänsande och dyra mjukvara och vi vill ju göra dem nöjda, inget konstigt med det. Så håll i er nu för här kommer det. Tänk om jag säger att det inte är en bra idé att fråga användarna! Tänk om jag påstår att de flesta användare inte har en aning om vad deras verksamhet egentligen behöver.

Låt oss ta ett steg tillbaka. Innan ni får intrycket att jag anser att användare är inkompetenta idioter så måste jag påpeka att jag definitivt inte tycker det. Tvärtom är användare de allra bästa på vad de gör och för det allra mesta är de kompetenta och skickliga. Med det sagt tror jag att ett väldigt lovande sätt att överbrygga klyftan mellan krav, leverans och verkliga affärsbehov är att omfamna ett koncept som kallas affärsdriven utveckling. Precis som namnet antyder är nyckeln i denna approach att låta kundens affärsbehov, affärsmål och affärsproblem vara det som driver mjukvaruutvecklingsprocessen. Hela syftet med den mjukvara vi bygger är att stödja och förbättra kundens affär. Annars skulle kunden inte investera projektet från första början. I praktiken innebär det att vi behöver ha ett affärsperspektiv i allting vi gör och för varje mjukvarufunktion vi utvecklar behöver vi ha en tydlig förståelse för varför den utvecklas och vilket värde den ger till kundens affär.

Problemet med agila metoder är att de fortfarande 

tenderar att vara väldigt användarcentrerade.

Så låt oss ta en titt på hundratusenkronorsfrågan. Hur kommer det sig att agila projekt fortfarande delvis misslyckas i inte mindre än hälften av fallen!? Så borde det väl ändå inte vara!? Jag menar, kom igen nu, det kan bara inte stämma. Vi arbetar ju i högkompetenta, självorganiserande utvecklingsteam där vi fortlöpande utreder och förfinar våra krav och levererar ny funktionalitet var och varannan vecka som kunden kan ge feedback på. Dessutom pratar vi fram och tillbaka med slutanvändarna om vad de vill ha och vad de behöver.

Nu ska jag sticka ut hakan igen och riskera att bli idiotförklarad och hånad av varje mjukvaruutvecklare och projektledare, för att inte tala om varje UX-specialist, med ett uns av självrespekt.

Till att börja med tror jag att den höga andelen delvis misslyckade agila projekt orsakas av en olycklig klyfta mellan krav, leverans och verkliga affärsbehov. Ok, men det var väl inte så särskilt kontroversiellt? Låt mig då ställa en ganska enkel fråga till dessa utvecklare, projektledare och UX-specialister. Hur ska vi ta reda på vad den mjukvara som vi ska utveckla faktiskt förväntas göra? Eftersom det kanske är den allra heligaste sanningen i mjukvaruutvecklingskretsar, som lärs ut i varenda mjukvaruutvecklingsutbildning i hela världen, så skulle jag säga att det är ganska sannolikt att svaret blir “Fråga användarna”.

Ok, men “fråga användarna” låter väl ändå som ett klokt och rimligt svar? Användarna är trots allt de som ska använda vår nya, glänsande och dyra mjukvara och vi vill ju göra dem nöjda, inget konstigt med det. Så håll i er nu för här kommer det. Tänk om jag säger att det inte är en bra idé att fråga användarna! Tänk om jag påstår att de flesta användare inte har en aning om vad deras verksamhet egentligen behöver.

Låt oss ta ett steg tillbaka. Innan ni får intrycket att jag anser att användare är inkompetenta idioter så måste jag påpeka att jag definitivt inte tycker det. Tvärtom är användare de allra bästa på vad de gör och för det allra mesta är de kompetenta och skickliga. Med det sagt tror jag att ett väldigt lovande sätt att överbrygga klyftan mellan krav, leverans och verkliga affärsbehov är att omfamna ett koncept som kallas affärsdriven utveckling. Precis som namnet antyder är nyckeln i denna approach att låta kundens affärsbehov, affärsmål och affärsproblem vara det som driver mjukvaruutvecklingsprocessen. Hela syftet med den mjukvara vi bygger är att stödja och förbättra kundens affär. Annars skulle kunden inte investera projektet från första början. I praktiken innebär det att vi behöver ha ett affärsperspektiv i allting vi gör och för varje mjukvarufunktion vi utvecklar behöver vi ha en tydlig förståelse för varför den utvecklas och vilket värde den ger till kundens affär.

I den andra delen i artikelserien gräver vi djupare i varför affärsdriven utveckling är så viktig för att möjliggöra för företag att vara agila i sin verksamhet och för att bygga långsiktigt hållbara mjukvarulösningar.

Kolla in den!

 

Författare

Markus Bergendahl

Solutions Architect

Star Republic