Agila metoder i IT-branschen

Att det var  IT- branschen som först implementerade agila metoder är ingen slump, det är ett symptom på branschens behov av effektivisering, anpassning och nödvändigheten av snabba resultat och kortare, mindre projekt, där de gamla traditionella metoderna som RUP och vattenfall tar lång tid, ofta upp till ett år vilket gör dem både resurs och tidskrävande och därmed mycket kostsamma. Det fanns helt enkelt ett skriande behov av att korta ledtider och optimera resultaten, som är tydligt mätbara inom just IT.
Den tekniska utvecklingen var inte den primära anledningen till de agila metodernas växande tillämpning, även om den gav upphov till de behov som kom att leda dit.
Användandet av agila metoder började snarare som en missnöjesförklaring och en ‘folkrörelse’ bland de som i yrket dagligen såg nackdelar med de klassiska projektstyrningsmodellerna. Och av dem som fick börja om från början med misslyckade långa, hårt styrda och dyra projekt.

I Sverige var det redan från början ett upplägg som kom att bygga ett starkt fundament för en växande rörelse, med företag som startade upp helt baserade på att arbeta agilt, och med en livskraftig nisch inom utbildning i agila metoder. Att predika för de redan frälsta, kan man säga, i ett ramverk som låg helt rätt i tiden, i övergången från centralstyrda globala jätteföretag till självgående mindre avdelningar och team med kompetens över flera branscher, med lokal förankring. Små och medelstora företag var de som först inkorporerade agila arbetsmetoder och principer, av praktiska och organisatoriska skäl.
I Sverige fanns redan en hög IT-mognad och en förhållandevis stor spridning av persondatorer och internet, samt en kår av mjukvareutvecklare, testare och andra yrkesverksamma som engagerade sig i att starta upp och föra vidare arbetet med agila metoder. Det i kombination med en förändrad struktur inom IT-branschen i allmänhet, med mer utrymme för arbete i mindre team och med konsulter vars rörliga positioner även gör fasta, årslånga traditionella projekt riskfyllda.

Inom just IT finns det även hinder i form av affärslagstiftning, då alla börsnoterade bolag (OMX) måste följa den amerikanska SOX (Sarbanes Oxsley Act), som är ett omfattande regelverk för hur företag måste ha samma hantering av information, dokumentation och strikt följa samma IT-processer i varje lokalkontor i världen, ned till mikronivå. Något som gör det i praktiken omöjligt för till exempel  Ericsson att helt gå över till agila IT-projekt som standard.
Detta beror på att revision skall kunna genomföras enligt gällande lag, och då krävs att samtliga delar av företaget, som branch- offices, global service centers, dotterbolag, och även externa partnerbolag följer exakt samma rutiner. Vid bristande rutiner kan företaget få böta, och vid stora brister uteslutas från börsen,vilken innebär ekonomisk kollaps för ett AB.

Man skulle kunna säga att agila metoder är motsvarigheten till wellness för projektarbete, ett slags individanpassat system som uppmuntrar till rörelse och positiv förändring, med en enkel filosofi som fokuserar på framsteg, kommunikation och problemlösning.

Samtidigt finns det baksidor och nackdelar med alla metoder. Vad finns det för argument mot att ha en ram som tillåter en nystart vid varje delmoment? Vilka nackdelar kan det finnas med att kommunikationen är avgörande? På vilket sätt kommer ansvar att fördelas, om alla har olika värderingar och olika prioriteringar?

Lämna en kommentar