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

By — Star Republic
12.29.2020

from-good-to-great_1.original

Då och då kommer det en tid för självrannsakan och för att utmana gamla sanningar. I den här serien om tre artiklar på temat ”From good to great” kommer jag att sticka ut hakan och ifrågasätta några av de saker som vi i utvecklar-communityt anser vara heliga. När allt kommer omkring blir det aldrig några framsteg utan vi ifrågasätter, eller hur?

Del 1 - "Be agile, not fragile".

Låt oss inleda den här första artikeln genom att prata om agilitet. Jag tror starkt att den agila rörelsen, eller kanske den agila revolutionen är ett bättre ord, har medfört stora fördelar för verksamheter som helhet. Med detta sagt tror jag dock att agila metoder i allmänhet saknar några viktiga affärskritiska ingredienser. En agil grundbult har alltid varit att föra affärer och teknik närmare varandra. Jag tycker att just fokus på affärer sällan betonas tillräckligt. Min erfarenhet är att agila metoder som Scrum, Kanban med flera fortfarande är mycket tekniska och användardrivna, vilket resulterar i bräckliga mjukvarulösningar som inte passar in i verksamheten. Att involvera verksamheten i utvecklingsprocessen på riktigt hjälper dig att ta mjukvaruutvecklingen till en annan och mer flexibel nivå, vilket gör att vi kan vara agila utan att för den sakens skull bräckliga.

Tänk på gapet - Förväntningar kontra 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 programvara. 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 benämner som vattenfallsprocesser. Alla krav undersöktes och analyserades innan vi började att bygga själva programvaran och oftast var de som arbetade med kravfångsten inte samma personer som sedan utvecklade programvaran. När kravfasen var klar överlämnades de väl inslagna till utvecklingsteamet. Denna enorma hög med krav sågs därefter som den "enda sanningen" och programvaran byggdes från början till slut baserat helt 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 mjukvara som gjorde mer eller mindre exakt vad kraven sa att den skulle göra, men trots detta var kunden missnöjd eftersom det inte alls var vad de hade förväntat sig.

Denna klyfta mellan förväntat och levererat resultat berodde mest på två problem. Ett som kan hanteras med agila metoder och ett som faktiskt fortfarande finns kvar i de flesta programvaruutvecklingsprojekt. Det första problemet är att krav och förväntningar tenderar att förändras ganska mycket över tid. När programvaran väl släpptes hade verksamheten hunnit att förändras, vilket gjorde att de initiala kraven som fastställdes i den tidiga kravfasen blivit föråldrade. Utöver detta hade de verkliga förväntningarna hos kunden, som antagligen aldrig ens noterats, också förändrats men eftersom vi var så upptagna av kodning istället för att kommunicera med kunden gick dessa förväntningar oss förbi.

Den agila rörelsen började få fart i början av 2000-talet med lanseringen av det agila manifestet, medförfattat av en massa extremt inflytelserika människor, inklusive Kent Beck, Martin Fowler och Robert "Uncle Bob" Martin. Dessa män betraktades, även idag, som mer eller mindre rockstjärnor inom mjukvaruutveckling. Agile blev en motreaktion mot det faktum att statiska, fasade utvecklingsprocesser ledde till en så hög grad av misslyckade programvaruprojekt. Istället för att arbeta i slutna faser enligt en vattenfallsmetodik, introducerades ett agilt tankesätt där utvecklarna jobbade i korta iterationer i nära dialog med kunden. I varje iteration analyseras och förfinas en mindre del av relaterade krav tillsammans med kunden. En isolerad och begränsad del av funktionaliteten utvecklas sedan baserat på de förfinade kraven. På så sätt uppvisade agila projekt förmågan att hantera förändringar snabbt samt en kontinuerlig inolvering från kundens sida, vilket i sin tur säkerställde att projektet höll sig på rätt köl och levererade det efterfrågade resultatet. 

Halvvägs till stordåd

Utan tvekan har agila metoder visat sig vara mycket fördelaktiga och har inneburit ett stort steg framåt för mjukvaruutvecklingen. Även om vi nu i efterhand kan luta oss tillbaka och skratta åt de idioter vi var förr om dagarna, kommer jag att hävda att agilitet i sig inte är någon quick fix och att den bara har tagit projekt kopplat till utveckling av programvaror halvvägs. Jag tror starkt på att agila, liksom de flesta andra utvecklingsmetoder som används idag, helt saknar några viktiga ingredienser, vilket resulterar i att vi fortfarande missar målet, men kanske inte lika illa som förut.

Låt oss komplettera mina tankar med några hårda fakta innan vi kör vidare. Varannan år släpper Standish Group en studie som heter "The CHAOS Report". Denna studie undersöker i vilken grad IT-projekt varit framgångsrika baserat på agila respektive vattenfallsmetoder och anses ofta vara en auktoritet när det gäller att mäta hur framgångsrika IT-projekt är. 

from-good-to-great-chart

De undersökta IT-projekten är indelade i de tre kategorierna lyckade, utmanande (dvs delvis misslyckade) och misslyckade. Vad alla CHAOS-rapporter som släpptes under det senaste decenniet (det senaste från 2019) indikerar är att agila processer har ökat mängden lyckade projekt kraftigt och också har minskat andelen misslyckade projekt. Det här är naturligtvis fantastiskt, men en riktigt intressant sak, som väcker några frågor och inte riktigt stöder mitt något kaxiga påstående om att agilt är det bästa sedan skivat bröd, är att andelen utmanade projekt fortfarande är ungefär densamma för agila respektive vattenfallsprojekt.

Fråga inte användaren

Så, låt oss ta en titt på den stora frågan. Hur kommer det sig att agila projekt fortfarande delvis misslyckas ungefär hälften av tiden!? Så borde det inte vara, eller hur!? Jag menar, kom igen, det här kan inte stämma. Vi arbetar i högkvalificerade, självorganiserande utvecklingsteam, förfinar kontinuerligt kraven och levererar programvarufunktioner regelbundet varannan vecka så att kunden kan få feedback och vi pratar fram och tillbaka med slutanvändarna om vad de vill ha och vad de behöver.

Nu sticker jag ut min dyrbara haka igen och riskerar att ifrågasättas och hånas av många programutvecklare och projektledare, för att inte tala om UX-specialister, med ett uns av självrespekt.

Till att börja med tror jag att den stora mängden utmanade agila projekt orsakas av ett olyckligt gap mellan krav, leverans och verkliga affärsbehov. Det var väl inte så kontroversiellt, eller hur? Så, låt mig ställa en ganska enkel fråga till ovan nämnda utvecklare, projektledare och UX-specialister. Hur ska vi ta reda på vad programvaran vi ska utveckla måste göra? Eftersom detta är en av de vanligast ställda frågorna inom det community som utvecklar programvaror och som lärs ut i de flesta utbildningar över hela världen som fokuserar på detta, skulle jag säga att det är ganska hög sannolikhet att ditt svar kommer att vara ”Fråga användaren ”.

Tja, "fråga användaren" låter som ett klokt och rimligt svar antar jag. När allt kommer omkring är användarna människorna som kommer att använda vår nya fantastiska, dyra programvara och vi vill göra dem nöjda, inget konstigt med det. Så här kommer det. Vad händer om jag säger att det inte är en bra idé att fråga användaren? Vad händer om jag säger att de flesta användare inte har en aning om vad verksamheten faktiskt behöver.

Låt oss ta ett steg tillbaka. Innan du får intrycket att jag tror att användare är inkompetenta idioter, säger jag att jag definitivt inte tycker så. Tvärtom är användarna de allra bästa på vad de gör och för det mesta är de mycket kompetenta och skickliga. Med detta sagt tror jag att ett bra sätt att övervinna gapet mellan krav, leverans och verkliga affärsbehov är att anamma ett koncept som kallas affärsdriven utveckling. Som namnet antyder är nyckeln att låta kundens affärsbehov, affärsmål och affärsproblem vara det som driver våra utvecklingsprocesser. Hela syftet med programvaran vi bygger är att stödja och förbättra sättet som kunden gör affärer på. Annars kommer kunden aldrig att göra investeringen överhuvudtaget. Detta kokar ner till att vi måste ha ett affärsperspektiv i allt vi gör och för varje programvarufunktion vi utvecklar måste vi ha en förståelse för varför den utvecklas och vilket värde den ger för verksamheten.

Problemet med agila metoder är att de fortfarande 

tenderar att vara väldigt användarcentrerade.

När jag går tillbaka till användarna som källa till kraven, menar jag att vi bör fråga dem om deras preferenser och behov, men vi borde inte börja där och de borde inte vara vår enda källa till krav. Användare i allmänhet vet mycket om detaljerna i deras specifika arbetsuppgifter. Problemet är dock att de i allmänhet har en begränsad förståelse för de bredare affärsfrågorna på en högre nivå. Genom att fokusera på användarna när vi formulerar krav börjar vi bygga våra mjukvarulösningar baserat på detaljkunskap om specifika arbetsuppgifter i en "nedifrån och upp-strategi" och riskerar därmed att missa hela det större sammanhanget. Låt oss ta en konstnär som Da Vinci, som arbetar med sitt mästerverk Mona Lisa, som exempel. Jag slår vad om att han inte började med att måla ögonfransarna utan snarare påbörjade sitt verk med bredare penseldrag för att sätta det övergripande perspektivet för målningen innan han fortsatte med detaljerna. Vi borde göra detsamma när vi bygger programvara och arbeta med en "uppifrån och ner-strategi". För att maximera våra chanser att bygga vad kunden verkligen behöver och förväntar sig måste vi förstå affärsbehov, mål och problem och hur varje enskild funktion eller komponent vi bygger passar in i den verksamheten. Det är först då vi kan bygga programvara som faktiskt passar företagets behov och kan utvecklas, växa och förändras tillsammans med verksamheten på lång sikt, utan att försämras till något ingen till slut vill ta i med tång.

Problemet med agila metoder är att de fortfarande tenderar att vara mycket användarcentrerade. Detta blir extra tydligt om du tänker på det mest centrala objektet i agila metoder. Allt arbete är centrerat kring användarberättelsen som, precis som namnet antyder, är helt användarfokuserad. Det betyder att varje programvara bygger på enbart användarkraven. Genom att arbeta med en användarbaserad "bottom-up"-metod som den här är det väldigt enkelt att fastna i detaljerna. För att komplicera saken ännu mer är dessa detaljer ofta motstridiga eftersom de härstammar från olika användare med olika perspektiv. Detta resulterar i att vi saknar den viktiga affärsöversikten över saker och ting som utan tvekan kommer att leda till att programvaran blir rörig och ostrukturerad och därmed svår att ändra och underhålla.

Sammanfattningsvis har det agila synsättet gjort att vi fastnat lite i att tänka enligt det gamla användarcentrerade sättet och därmed bara kommit halvvägs i vårt strävan efter perfektion. Det som är fördelaktigt med detta är att det fortfarande finns mycket utrymme för förbättringar. Mjukvaruutvecklingsföretag som vi själva inom e-handelsbranschen, och egentligen alla andra företag också, har alltså en gyllene möjlighet. Genom att anpassa agila metoder så att de blir mer affärsdrivna kan vi skilja oss från våra konkurrenter och få ett stort förtroende från våra kunder. Ännu bättre, eftersom affärsdriven utveckling fortfarande är ett ganska ovanligt angreppssätt kommer vi att kunna förbättra oss mycket med enkla medel. Tiden kommer att avgöra vilka aktörer som inte kommer att nöja sig med att bara vara bra utan jobbar mot målet att bli fantastiska. 

Den andra delen i vår bloggserie "From good to great" finns också ute nu. I den fokuserar jag på vikten av affärsdriven utveckling för att uppnå affärsnytta och lyckas bygga en hållbar programvara.

Häng med!

 

Författare

Markus Bergendahl

Lösningsarkitekt

Star Republic

 

Säg hej!