Traditionellt utvecklingsarbete innebär (karikerat) att vid projektstart fråga kunden om alla krav, och att sen inleda nästa dialog först vid leverans. Likaså tenderar många stora företag att fokusera på att sysselsätta sina anställda till fullo. Det skapar främst skenbar intern effektivitet, men inte maximala fördelar för kunden.
Christian Arrhenius funderar på moderna arbetssätt ur Y-generations perspektiv. Han deltog i Forums reverse mentoring 2017, och jobbar på Elisa.
Motreaktionerna heter lean (ungefär: slimmad) och agile (lättrörlig), som allt fler företag åtminstone påstår sig utgå från inom sitt utvecklingsarbete. Det går ut på att förstå kunden på djupet, att kommunicera löpande och organisera leverans i rätt tid och med rätt kvalitet.
Jag har själv observerat att storföretag gärna kommunicerar utåt att de fokuserar på kundvärde, hög produktivitet och snabb anpassningsförmåga. Det klassiska valet mellan Michael Porters klassiska basstrategier från 1980 (låga priser, differentiering eller fokusering) är föråldrat, eftersom en modern organisation som jobbar ’lean’ och ’agilt’ både kan äta kakan och ha den kvar. Men vad betyder ’lean’ och ’agil’ egentligen i praktiken? Här några personliga infallsvinklar.
En kaotisk omgivning. Agilitet, eller agil systemutveckling som det även kallas, beskriver en filosofi som officiellt uppkommit kring millennieskiftet i samband med IT-utveckling. Grundpremissen är att vi lever i en invecklad, tidvis rentav kaotisk värld, där sambandet mellan orsak och verkan är svårt att identifiera och entydigt kvantifiera. I en sådan omgivning når man sällan bästa resultat genom att planera allting fullständigt i förväg, utan genom att prova sig fram. Därför är den iterativa modellen (upprepning genom försök och misstag) med snabb respons en central tanke inom agilitet.
Botemedlet mera planering? Själv ser jag inte ovanstående tankar som värst kontroversiella, men ändå fungerar flera så kallade ’agila’ organisationer i praktiken i skarp kontrast till idealet. Ett konkret exempel: då ett projekt misslyckas, vilket ofta betyder att utfallet är sämre än planerat, blir ofta den instinktiva reaktionen att nästa projekt måste planeras mera utförligt. Bättre experter, utförligare riskanalys och noggrannare specifikationer är botemedlet som tros rädda nästa projekt. Slutsatsen utgår från en icke-agil världsbild där framtiden är förutsägbar.
Snabb experimentering. I en agil tankevärld är svaret att man med hjälp av tidigare experimentering validerar sina antaganden och ställer sig mer öppen för förändringar i näromgivningen. Detta betyder inte att all planering vore onödig, men nog att konkreta prototyper betonas redan i ett tidigt skede. På detta sätt misslyckas man naturligtvis mer sannolikt än med utförlig planering, men däremot har man investerat mindre i själva förarbetet som riskerar bli så kallad ”sunk cost”, en tagen kostnad som inte fås tillbaka.
När lämpar agilitet sig? I likhet med flesta andra metodologier har agilitet både mer och mindre ideala förhållanden. Här är några kännetecken. För det första: grundpremissen, alltså en invecklad och snabbt föränderlig omgivning. Den andra faktorn, som mera sällan betonas, är kostnaden av omarbete. Inom mjukvaruutveckling är skrivandet av själva koden ofta en förhållandevis liten ansträngning jämfört med allt förarbete. Inom byggbranschen däremot kan jag tänka mig motsatsen. Man vill knappast prova sig fram med ett husbygge, eftersom det helt enkelt är så dyrt att bygga om.
Begreppet lean förknippas flitigt med agilitet, speciellt inom IT-utveckling. Trots att likheter finns ser jag tankesätten som sinsemellan oberoende, eftersom de enligt min tolkning har olika syften. Medan agilitet går ut på att höja förmågan att verka inom en föränderlig omgivning är idéen med lean att maximera kundnyttan inom ett specifikt produktionssystem. De centrala koncepten inom lean, såsom att minimera slöseri eller optimera värdeflöde i stället för resursanvändning, kan utnyttjas inom såväl agila som icke-agila organisationer.
Metoderna som förknippas med lean är dock ursprungligen utvecklade i japansk fabriksmiljö, med relativt konstanta och förutsägbara processer. Många av verktygen utgår från jämna och mätbara arbetsmoment samt stabila processer, som kan och är värda att dokumenteras. Inom agil IT- utveckling används ofta så kallade kanban-tavlor för att visualisera arbetsflödet, begränsa mängden pågående arbete samt hjälpa teamet fokusera. Den stora skillnaden till massproduktion är att producerade mjukvaruenheter sällan innehållsmässigt är varandra lika.
Sällan bra för kreativt jobb. Det är svårt att hitta på situationer där man inte skulle vilja minimera slöseri och maximera nytta, men kanske lean-verktygens starkaste sidor inte kommer fram i kreativt arbete. Som tankeexperiment: ta en konstnär som använder lean-principer och verktyg – vad optimerar han egentligen? Konstverk produceras med konstant och snabbare flöde, men det är inte entydigt ifall färre pågående arbeten, kortare ledtider och mindre processvariation leder till bättre slutresultat. Som sista tankeställare: ligger uppgifterna som du och ditt team arbetar med närmare konst- eller fabriksproduktion?
