“The Agile Industrial Complex” och dess problem

De nya lättrörliga modellernas filosofi

I mitt förra inlägg kommenterade jag att lättrörliga modeller för innovation i kombination med hög grad av outsourcing inte är riskfria att anamma. Denna gång tänkte jag gå in i andra risker med att allt för ensidigt anamma de ”nya” lättrörliga modellernas filosofi.

Lättrörliga modeller har lycktas ta världen med storm och ingenting anses längre vara omöjligt att hantera genom dem som utveckling (självklart!), projektledning, upphandling, leverantörsstyrning, m.m.

Detta beror på tre skäl:

1. Vi är mer och mer beroende av mjukvara i allt vi tar oss för, också i den fysiska världen, vilket gör att ”utveckling” blir känt för gemene man
2. De som behärskar skapandet av mjukvara är utvecklaren, och deras tolkning blir vägledande, vilket leder till att deras arbetssätt sprider sig till andra delar
3. Vi vill vara flexibla, innovativa och lösningsorienterade och då känns ett oskrivet blad lättare att hantera än en bunt strikta regler.

 

“The Agile Industrial Complex”

Men många före oss, inklusive Dave Thomas[1], har redan uttalat att ”agile” är dött. Dött i den bemärkelsen att det tagits över av ”The Agile Industrial Complex” som med mer eller mindre proprietära ramverk (och processer), verktyg, kurser och certifieringar samt konsulter vill tjäna pengar på det ursprungliga manifestet. Med ”nytolkningen” av Agile tillkom nya ord, nya roller, processer, ceremonier, etc. som ytterligare byggde på apparaten för att styra och hantera IT-leveransen. I grunden handlar manifestet om vad deltagarna, på konferensen där det togs fram, värdesatte när det kom till att arbeta med att utveckla mjukvara. Det heter också ”Manifest för Agil systemutveckling”. Det är också viktigt att förstå är att ”Agile” är ett adjektiv men som behandlas som om det vore ett substantiv. Det är helt enkelt svårt att sälja in adjektiv men klart lättare att sälja substantiv ihop med adjektiv.

 

När lättrörliga modeller skapar problem

Ursprungligen är lättrörliga modeller till för utvecklare som arbetar med att skapa mjukvara, att lösa problem, etc. Det som ovan nämnts har skrivits om till oigenkännlighet för utvecklarna och istället iklätts en dräkt med löften om högre effektivitet för oss andra, oavsett tillämpning. För att belysa med ett exempel, så är de flesta projekt, i de flesta verksamheter, allt som oftast handlar om att installera och integrera standardapplikationer (vilket kan vara nog så svårt). Och med det följer några problem som anammandet av lättrörliga modeller som tillvägagångssätt kan föra med sig:

• De kan dölja fel och/eller brister i organisationens affärs-/leveransmodeller om man ”isolerar” projekt och initiativ till separata avdelningar genom fasade införanden
• De kan dölja fel och/eller brister i standardapplikationer då man väljer ut enstaka delar (se punkten ovan) som man sedan bygger på allt eftersom, och då sent upptäcker att delarna inte passar organisationen och dess målsättningar
• De kan bidra till ökad ”silofiering” genom att de team som upprättas inte kommunicerar med varandra – vilket man ville undvika i första läget genom att ta sig an organisationens digitala transformation

 

Risker med att kopiera andras framgång

Dessa modeller har haft svårt att tar hänsyn till och/eller hantera helheter som stora organisationer innebär och det kvittar om man bygger modeller och ramverk för att samla ingående delar (team, processer, produkter, etc.) för att efterlikna mjukvarufabriken om man inte går vidare med att sätta upp övergripande principer och regler för hela organisationens styrning och ledning som kopplar till dess digitalisering – utan denna förklaring och fortsatt tillåtelse att ”köra själv” äventyrar man organisationens övergripande digitalisering genom att försöka kopiera andras framgång (länk till inlägg 2).