Utveckling är bara en liten del

Tjänsteperspektivet handlar om tjänsters (till exempel IT-tjänsters) hela livscykel. Alltså från att man designar tjänsten till att man driftsätter den, har den i bruk, förändrar den under resans gång, och slutligen avvecklar den. Det här helhetsperspektivet är något som ibland glöms bort, vilket kostar enorma summor och orsakar många sura miner.

Agila metoder uppkom bland systemutvecklare och används ofta i systemutveckling, vilket har gjort att ramverken har en slagsida åt just utvecklings- och förbättringsdelen i livscykeln. Men förbättring utgör kanske bara en tiondel av tjänstens hela livscykel. Att skapa agilitet i själva utvecklingssteget (som Scrum, LeSS, SAFe med flera ramverk försöker göra) är en bra början, men om man inte ser till hela livscykeln blir det suboptimering.

Det har troligen att göra med att tjänstedesign (som ju systemutveckling i grund och botten är) är så osäkert och komplext. Tidigt försökte man hantera komplexiteten och osäkerheten med projektmodeller, och det innebar att man började se på utveckling som en aktivitet avskiljd från andra aktiviteter. Utvecklingen sågs som det svåra problemet, och även om agila metoder (=iterativ utveckling i små steg med ständig omplanering) börjat ersätta projektmetoderna (=sekventiell utveckling i stora steg utifrån låsta planer) så har man ofta behållit avgränsningen att problemet gäller systemutveckling och inget annat.

Men att utveckling är svårt beror till stor del på att det är svårt eller omöjligt att förutse hur en viss lösning kommer att bete sig i verkligheten, när den väl är driftsatt. Kunskapen om hur de olika aktörerna påverkas av den framtida lösningen är som sämst när man behöver den som bäst, i början av en utvecklingscykel.

Det är alltså i drift som vi får reda på vad som krävs av lösningen. Det är i drift som lösningen kostar och skapar värde, hindrar och möjliggör. Den process i livscykeln vi bör optimera på är alltså den process som i drift snabbt och smidigt identifierar en förbättringsmöjlighet, designar en förändring som antas förverkliga möjligheten, driftsätter den, och utvärderar om antagandet var rätt.

Designsteget är viktigt, men bör inte vara så komplicerat. Så länge som vi i projektmodellerna vill hantera stora sjok av förbättringar som driftsätts sällan, så sker hypotesprövningen ute i verkligheten alldeles för sällan. De agila metoderna är mer anpassade för korta cykler med små och täta uppdateringar, men så länge som vi använder de agila metoderna enbart som en komponent inom projektcentriska styrmodeller kommer vi ändå inte att få ett agilare samspel och bättre lösningar snabbare.

Förvaltningsmodeller som PM3 och ITIL har ett livscykelperspektiv (till den grad att de ofta får en slagsida åt drift och produktion). De agila teknikerna har stor potential att passa inom förvaltningsmodeller. Tyvärr tenderar dagens förvaltningsmodeller ha stora element av projekttänkande i sin syn på utveckling/design, och dessutom tillämpas de ofta på ett alldeles för byråkratiskt sätt.

Jag tror att det som behövs är en ny formulering av förvaltningsmodellerna, där man behåller och förfinar det som fungerar smidigt, medan man låter bli det trögrörliga. Jag tror att vi behöver formulera agil tjänsteförvaltning.