Publicerad
Författare
Från tid till annan uppstår det fenomen och strömningar som lyckas etablera sig som sanningar även om det mer handlar om religion än vetenskaplig fakta. Och där den grundläggande tanken plockas upp och börjar tillämpas på fel sätt. Vi har sett det förr och vi kommer att se det igen, många gånger till. Agila projekt är just ett sådant fenomen.
Varför har agila arbetssätt och agila projekt blivit populära som modeller för utveckling? Jo, av den enkla anledningen att de i många sammanhäng är den enda och den bästa vägen för att uppnå ett långsiktigt och hållbart resultat.
Lite förenklat kan man hävda att ett agilt arbetssätt är en lyckosam mix av två modeller som i grunden egentligen är dåliga. Den ena modellen förespråkar att man planerar ”allt” in i minsta detalj innan man påbörjar sin förändring och utveckling. Och den andra modellen förespråkar att man utan någon planering direkt sätter igång och utvecklar och tacklar problemen i den takt de uppstår. Den agila modellen förespråkar att man arbetar med en successiv planering och utveckling men där planeringen begränsar sig till ”vad som är rimligt att överblicka” utan att överarbeta ned i minsta detalj. Det innebär dock också att projektet successivt kan ändra karaktär och förflytta sig i takt med att nya insikter uppstår under projektets arbete. Och där slutresultatet kan skilja sig emot vad som förväntades när projektet inleddes. Och detta kan givetvis betraktas som såväl positivt som negativt.
Grunden till att arbeta enligt en agil modell kommer ifrån systemutveckling. Historiskt har det genomförts väldigt många IT-projekt där kostnaden blivit astronomisk och där det förväntade och nödvändiga resultatet ändå aldrig uppnåtts. Att arbeta agilt är ett motdrag för att dels arbeta med kontinuerlig kontroll och styrning samt dels kunna agera och förändra när nya insikter visar att det krävs korrigeringar av plan och mål. På så sätt blir det agila projektet mer en snabb och manövrerbar motorbåt jämfört med en stor supertanker som tar lång tid att vända.
Om det nu finns så mycket positivt att säga om agila projekt varför har då denna blogg en rubrik som indikerar något annat? Jo, av den anledningen att det krävs sans och balans i synsättet kring agilitet. Alla modeller, oavsett vad de heter, har sin givna plats och sitt givna tillfälle. Och precis som för andra modeller är en agil modell inte lämpad för alla IT-projekt och i alla sammanhang. Och ett av de sammanhang där en agil modell ska användas med stor försiktighet eller inte alls är affärssystemsprojekt.
Givetvis finns det skillnader mellan affärssystemsprojekt i såväl omfattning som komplexitet men i vardagligt tal menas ett projekt där en mångfald av processer och moduler ska bytas ut från en gammal miljö till en helt ny miljö. Och en situation där merparten behöver bytas ut vid samma tillfälle (vilket dock inte ska förväxlas med det klassiska uttrycket Big Bang). Grundlogiken kring ett affärssystem är att alla delarna är så pass sammanbyggda och integrerade att det är svårt och ibland omöjligt att planera för något annat än en samlad driftsättning. Det hindrar dock inte att det kan gå att avvakta med vissa processer som inte är kritiska för driftsättningen eller att man kan planera för en driftsättning där man väljer begränsad flexibilitet i processerna innan man växlar upp.
Utmaningen med affärssystem är just att affärens grundlogik och det samlade informationsflödet måste hänga ihop och vara genomtänkt innan systemet fullt ut kan testas och där hypotesen om affärsmodellen kan prövas. Det problem som kan uppstå med en agil modell är den slaviska tron på hur modellen ska tillämpas. Av många följare ska modellen följa en ganska strikt princip med sprintar om 3-5 veckor, något som ihop med ett relativt stort och komplext affärssystem kan visa sig vara svårt och i ett sammanhang där arbete måste pågå parallellt inom många processområden, och där resultatet är svårt att bedöma innan man i ett betydligt senare kan börja köra kompletta tester igenom systemet. Det missförstånd som ofta leder till utmaningar med agila affärssystemsprojekt är inställningen att den agila modellen håller nere totalkostnaden och att slutresultatet blir bättre. Det är på inga sätt givet. Och i de allra värsta exemplen väljer parterna att inta ta fram någon karta eller ritning alls utan utgår ifrån att det som finns i standard är tillräckligt och att man hanterar problemen när de dyker upp. Och där det ganska sent kan visa sig att den totala lösningen inte alls kommer hålla ihop på det sätt man hade förväntat sig. Men där man samtidigt har gått så långt i arbetet att det av kostnadsskäl eller politiska skäl är svårt att backa eller att avbryta.
Det är viktigt att kunden förstår sin roll och sitt ansvar i ett agilt affärssystemsprojekt. Och att kunden är beredd att betala priset för resultatet. Även om slutkostnaden visar sig bli betydligt högre än vad som estimerades när projektet initierades.
Det är väldigt svårt för den traditionella kunden att fullt ut förstå konsekvenserna av de beslut som fattas i respektive sprint och kunna överblicka hur det kommer att påverka den slutliga systemlösningen. Och samtidigt kan leverantören hålla ryggen relativt fri då kunden avkrävs ett godkännande för varje enskild sprint. I den absoluta merparten av alla affärssystemsprojekt kommer det förr eller senare en formell fas där kunden ska acceptanskontrollera lösningen. Och i de situationer där kunden i denna fas ställs inför fakta att den slutliga lösningen inte kommer fungera som det var tänkt vid uppstarten är det svårt att hävda att leverantören ska stå för merkostnaden för de justeringar som krävs för att ändra uppsättningen. Det kan vara så att enskilda delar och flöden fungerar utmärkt men att systemet vid s.k. end-to-end tester inte alls ger det resultat som är planerat. Och följden blir att ansvarsfrågan blir oklar och där en rättslig bedömning blir väldigt svår.
Likväl som det finns exempel på projekt där en agil modell fungerat vid implementering av ett affärssystem finns det minst lika många exempel på projekt där resultatet blivit en katastrof. Hur man än vrider på situationen kan framgången kokas ned till de individer och den erfarenhet som inkluderas i teamet som ska genomföra projektet. En agil modell kan aldrig skapa motvikt mot bristande insikt och förståelse för affärssystemsprojekt, istället blir effekten den motsatta.
Ovanstående text ska inte tolkas som ett brandtal emot agila projekt. Det ska tolkas som att agila modeller inte automatiskt är den bästa modellen för affärssystemprojekt. Och i många fall är det till och med en modell man definitivt ska avstå ifrån – om man skapa en tydlighet i vad man vill uppnå med sitt system och där man vill skapa tydlighet i hur ansvaret ser ut mellan parterna gällande lösningens realiserande. Modellen ska tillämpas med förnuft och försiktighet.
