Vi bygger broar

- "Ja, agilt handlar ju bara om hur IT levererar projektet. För oss som beställer projekten kommer det inte att påverka!"

Hos en av mina kunder, som precis lämnat en period av gruvligt misslyckade IT-projekt bakom sig, hörde jag dessa ord yttras i fikarummet av en person från "verksamheten" (varför skiljer folk på "verksamhet" och "IT"?) som satt och pratade med en projektledare. Projektledaren nickade och höll med.

Organisationen hade gjort sin läxa och började nu sedan en tid tillbaka försöka tillämpa olika tekniker från den "agila" verktygslådan. Vi var mitt uppe i en stor utbildningssatsning och tittade samtidigt på olika sätt att organisera arbetet i linjen för att försöka komma bort ifrån de destruktiva projekten.

Skulle jag lägga mig i samtalet? Berätta för dem att de hade fått vissa fundamentala saker om bakfoten? Nej. Tids nog kommer de att bli varse, tänkte jag. Och jag vill dessutom att de ska nå den insikten inom ramen för en utbildning där de kan få ställa alla frågor och skapa sig en förståelse för hur helheten kan tänkas se ut.

Men deras tankevurpa är väldigt vanlig. Eftersom själva systemutvecklandet ofta är flaskhalsen i förbättringen av IT-system, så är det där som problem manifesterar sig. Och vi tror ju ofta (felaktigt) att problem uppstår i närheten av sin manifestation. Agila metoder ses då som en sorts smörjolja för att få de tröga kugghjulen hos IT att börja snurra lite fortare.

- "Scrum är en projektledningsmetod för IT-projekt i genomförandefasen!" kan det få heta.

- "Jo, vår projektstyrningsmetod kan köras agilt. Efter förstudie med analys och framtagning av lösningsförslag och specifikationer, så sker implementationen agilt i iterationer tills det är dags för systemtest!"

Det här tänkandet bygger på tron att problemen inom systemutveckling handlar om att vi gör rätt saker men att vi gör dem för långsamt. Då förstår man inte varför det går långsamt. Man förstår inte att överlämningar kostar. Att analysen, hur bra genomförd den än är, ändå kan peka fullständigt fel vilket ingen kan förstå förrän man faktiskt börjar att koda. Att avbrotten i form av olika faser kostar multum, och att uppgiftsväxlingen till följd av försök att på ett okoordinerat sätt köra projekten parallellt leder till merkostnader på över 100%. Man tror att förseningar är irriterande men billiga i jämförelse med att släppa delfunktionalitet så fort som möjligt, och man tror att uteblivna valmöjligheter i mjukvaran är betydligt dyrare än utveckling och förvaltning av alla dessa valmöjligheter.

Det som lean och agila metoder framförallt gör är att skapa synlighet om var de verkliga flaskhalsarna är. Kostnaden för trög omsättningstakt på information blir synlig, och produktutvecklingens faktiska ekonomi kommer i dagen. Den nya informationen skapar genast ett förändringstryck på andra delar i kedjan. När andelen krav som förblivit oförändrade från analys till systemtest visar sig vara låg, så ifrågasätter man förstås produktiviteten i analysfasen och varför inte analyserandet också ska ingå i en agil feedbackloop. När tidplaner sätts efter mätning av faktiska hastigheter istället för på väldigt volatila estimat, så blir värdet av att prioritera hårdare bland funktionerna uppebart (och beräkningsbart).

Vi blir varse om att vi deltar i en värdeström och att vi har ett ansvar att göra hela värdeströmmen bättre.

För att lyckas med detta öppnar vi våra dörrar. Agilitet åstadkommer man med transparens. Vi på IT-sidan har tekniker för att hjälpa verksamheter att förstå nyttor och effekthemtagning. Vi kan analysera flera varianter av brukarflöden parallellt för att tillsammans se vilka som ger störst värde till lägst kostnad. Agila metoder för systemutveckling ger oss en infrastruktur där vi kan identifiera behov och ta fram lösningar i ett obrutet flöde. Användarna har behov nu och ska inte behöva vänta längre än nödvändigt. Väntan är spill.

Men när vi nu öppnar våra dörrar och erbjuder metoder att länka ihop systemutvecklingsprocessen med de andra värdeflödena, så krävs det att någon på verksamhetssidan tar emot. Att de förstår att alla beställare-utförare-modeller är dyra och skadliga. Att de förändrar finansieringen av utveckling bort ifrån stora klumpsummor för oklara mål, till jämna flöden där man ska kunna se tydlig nytta direkt. Att verksamheterna också börjar att optimera bemanningen för tillgänglighet istället för utnyttjandegrad, så att det dyrbara samarbetet inte äventyras av konstlad tidsbrist.

Vi fixar det här tillsammans!