Många köer i både trafik och produktutveckling uppstår utan någon tydlig anledning. Kan man hantera dem ändå? Jag vill fortsätta jämförelsen mellan trafik och utvecklingsarbete från föregående artikel för att utforska fenomenet fantomköer och vad man kan göra åt det.
När det flyter på bra på en motorväg så upplever man sig inte som speciellt beroende av andra bilar på vägen. Man byter fil, kör om och blir omkörd utan att det behöver påverka ens resa något nämnvärt. Men ibland händer det att någons omkörning gör att du tvingas bromsa, vilket skapar en störning i ditt flöde. Om du vid tillfället har en bil nära bakom dig tvingas även denne bromsa, lite mer än du gjorde för att hålla avstånd. Och så fortsätter det tills någon behöver stanna helt eller att det finns en tillräckligt stor lucka för att nästa bil inte ska behöva bromsa. Det bildas en bilkö. Köer som uppstår på det sättet kallas ofta fantomkö eftersom orsaken till kön försvinner spårlöst.
Tänk dig nu ett arbetspaket i ett utvecklingsflöde, låt oss kalla det för Story X. Ett Team har börjat arbeta med Story X och allt flyter på bra. Men när det är dags för testning så funkar inte testservern. Teamet har inte tålamod att undersöka saken närmare utan lägger Story X i status Blocked och sätter igång en annan Story. Det Teamet inte vet om är att slutförandet av Story X skulle innebära att man lär sig saker som skulle påverka pågående och planerat arbete för flera Team. Medan Story X ligger som Blocked så fortgår nu arbete som borde gjorts annorlunda, eller inte gjorts alls, om man bara fått lärdomarna från att slutföra Story X. Det har bildats en fantomkö! Problemet med testservern arbetades på och var fixat en timme senare.
På motorvägen finns det inte något exakt antal bilar som gör att fantomköer bildas. De uppstår när förutsättningarna för en fantomkö finns - att ett antal bilar ligger nära efter varandra och att någon av dem behöver bromsa. Desto fler bilar det är på en sträcka, desto större är risken att dessa förutsättningar uppstår. Likadant är det i utvecklingsflödet. Det blir inte köer automatiskt för att man försöker göra mycket samtidigt, men det ökar risken för att förutsättningarna uppstår för att en kö ska bildas. Desto mer arbete man har igång samtidigt, desto mer sannolikt är det att ett problem uppstår, och desto mer sannolikt är det att det problemet påverkar annat pågående arbete.
Ett sätt att undvika dessa köer är alltså att undvika att det blir för många bilar eller arbetspaket samtidigt. På motorvägen har ni kanske sett LED-skyltar med hastighetsbegränsningar. De är ett sätt att försöka minska hastigheten på bilar som är på väg in till en sträcka där det redan är för mycket bilar. På så sätt kan man minska risken för fantomköer. Ibland räcker det inte till, men det är ett svårlöst problem och man får göra vad man kan. I utvecklingsflödet så är det en betydligt mer begränsad grupp människor som behöver förstå problematiken och göra något åt det, vilket gör det lättare att hantera problemet. Man kan till exempel sätta begränsningar på hur många arbetspaket ett Team eller Team-of-Team får jobba med samtidigt med så kallade WIP (Work In Progress)-limits. Förutom att minska risken för köer så bör detta leda till ökat samarbete, högre kvalitet, mer kunskapsspridning och kortare ledtider.
Känner du inte igen att fantomköer skulle vara ett problem i din organisation? Det är förståeligt eftersom att anledningen att det kallas för fantomkö är att orsaken till kön försvinner spårlöst. Men köer och väntetider kanske du upplevt även hos er? Tror du att dessa oftast kan kopplas till ett existerande och greppbart problem, eller är det ofta så att någon väntar på någon annan, som väntar på någon annan, och grundorsaken till väntandet är spårlöst försvunnen? Befinner du dig i en lite större organisation vågar jag lova att det andra alternativet stämmer bättre. Gör mindre - leverera mer!
