Flödesekonomi 1A

Det var en gång ett stort börsnoterat bolag som fick sina intäkter genom att tillhandahålla en IT-baserad tjänst för konsumentmarknaden. Problemet var att man inte längre var ensamma på marknaden, utan flera nya uppstickare utmanade bolaget. Dessa nya uppstickare lyckades leverera nya efterfrågade funktioner i snabb takt, medan bolaget fick allt svårare och svårare att hänga med.

"Agilt!" sade ledningen. "De nya bolagen jobbar agilt! Då går det snabbt! Det ska vi också göra!"

Sagt och gjort: man tog in vägvisare som hjälpte dem att hyfsa till organisationen. Istället för att projekten segade sig emellan kompetensspecifika avdelningar skapades tvärfunktionella självorganiserade team. Istället för att olika projektbudgetar krävde uppmärksamhet samtidigt, så utsågs produktägare med ansvar att prioritera det viktigaste för varje team. Och eftersom arkitekturen var mycket komplex så skapades ett brett men effektivt koordineringsteam som kunde ta det övergripande prioriteringsansvaret.

Nu vände det. Man lyckades börja leverera funktioner i nästan samma takt som konkurrenterna. Flaskhalsen var nu inte längre projekten utan den gamla arkitekturen. Man började planera för refaktorering.

Men då drog ledningen öronen till sig. Refaktorering? Prioritera plattformsarbete när man kan prioritera funktioner? Det måste vi sätta stopp för! Inte bara det: när ledningen tittade närmare på hur var och en i teamen arbetade såg de att flera personer inte kunde kallas hundraprocentigt belagda. Här fanns alltså en outnyttjad kapacitet som skulle kunna användas för att äntligen komma ikapp och förbi konkurrenterna. Det blev ganska många procent när man räknade på det!

Genom att bromsa fokuset på plattformsarbetet och kommendera in lite fler parallella initiativ, samtidigt som man klubbade igenom en mer aggressivt releaseplan, så fick man upp beläggningen till hundra procent. Totalt tjänade man in femton procent, så man förväntade sig en hastighetsökning i funktionstillväxten på lika mycket.

Resultatet blev (förstås) en omedelbar sänkning av utflödet med 20 %. När trycket ökade inom organisationen fastnade arbetspaket vid olika flaskhalsar i flödet, vilket fördröjde processen så att utflödet sjönk. Mycket snart märktes också effekten av att var och en på grund av förseningarna tvingades arbeta med flera saker samtidigt vilket sänkte utflödet ytterligare.

Men den stora sänkningen av hastighet kom när man på grund av den aggressiva planen var tvungen att produktionssätta flera utlovade funktioner innan de blivit genomtestade. Detta resulterade i ett massivt inflöde av felrapporter. Alla arbetade för högtryck med en genomsnittslig övertid på sju procent, men majoriteten av tiden gick åt till att hantera fel, växla mellan olika uppdrag, skyffla information om beroenden, och förstås också skapa nya fel. Utflödet var nu 30 % av vad det varit tidigare.

Man gjorde ett kortlivat försök att återta förlorad tid genom att outsourca en del av utvecklingen, men detta resulterade i en ännu större sänkning av utflödet då alla dessutom var tvungna att förhålla sig till utvecklingsteam i olika länder, som allesammans skulle ner och gräva i samma kodbas samtidigt.

- "Jag förstår inte detta!" tänkte den i ledningsgruppen som varit mest pådrivande i ökningen av beläggningsgraden, när hen satt i bilkön på väg hem från jobbet. "Det är som om hastigheten i vår utveckling sänks ju mer vi jobbar! Hur kan det bli så?" tänkte hen, samtidigt som hastigheten på motorvägen hastigt sjönk mot noll i takt med att fler bilar och fler bilar körde där.