Planview-bloggen

Din väg till smidighet i affärsverksamheten

Work Management för team

Myten om multitasking: Varför IT-verksamhet behöver WIP-gränser

Publicerad Av Dominica Degrandis

It may sound hard to believe, but multitasking is an effective way to get less done. Juggling multiple tasks at once interrupts your focus, which can cause you to spend more time on each task than if you had completed them one at a time.

Även om forskning bevisar de skadliga effekterna av multitasking på produktiviteten är det fortfarande många av oss som närmar oss vårt arbete med inställningen "gör allting, och gör det nu". Det gäller särskilt för IT-driftsteam som är överbelastade med att hantera nya förfrågningar och hålla produktionen stabil. Enligt vår erfarenhet beskriver detta alla IT-driftsteam som vi någonsin har arbetat med.

Kanban syftar till att minimera multitasking genom att använda begränsningar för pågående arbete (WIP) vid strategiska punkter i teamets process eller arbetsflöde. En WIP-gräns är ett verktyg för att begränsa hur mycket arbete som kan vara i gång samtidigt, vilket bidrar till att avslöja flaskhalsar och förbättra arbetsflödet. Här är vad IT-driftsteam kan lära sig om hur man använder WIP-gränser för att få mer av rätt arbete utfört i rätt tid.

Flaskhalseffekten: En fallstudie

Ett IT-driftsteam på ett företag som vi arbetade med hade ett arbetsflöde där det sista steget i processen (före Done) var Validate. Det fanns ingen process vid den tidpunkten som möjliggjorde snabb återkoppling, så efter att de hade levererats förblev arbetsmomenten i Validate. Normen var att allting var okej, så länge ingen klagade.

Medan arbetet låg still i Validate, tog folk mer arbete från backloggen till Implement. Validate-kön växte och växte tills den hade nästan 100 arbetsobjekt. Kanban-tavlan nedan visar hur detta såg ut, med flaskhalsen i kön Validate.

Ovan: En fysisk Kanban-tavla som visar en flaskhals i valideringskön.

Många av de levererade produkterna var faktiskt tillfredsställande, men vissa var det inte, vilket gjorde kunderna i efterföljande led missnöjda. När de nämnde att arbetet inte hade levererats som de hade förväntat sig tog det lång tid för IT-driftsteamet att svara eftersom de redan var i färd med nästa uppgift.

När det gick allt längre tid mellan kundernas återkoppling och IT-driftens svar blev de missnöjda kunderna mycket missnöjda och gav till slut upp försöken att kommunicera. De klagade sinsemellan och till andra avdelningar: "Ops svarar aldrig", "De är som ett stort svart hål" och "Vilket värdelöst team".

Så småningom började IT-driftsteamets rykte att sjunka. De försökte göra så många saker samtidigt att de inte kunde göra någonting bra. Som Steve Uzzell säger i Gary Kellers bok The ONE Thing: The Surprisingly Simple Truth Behind Extraordinary Results: "Multitasking är bara möjligheten att sabba mer än en sak åt gången."

Hur mycket WIP har ditt team?

Här är en övning som du kan prova: Fråga i ditt ärendehanteringssystem (ITSM-verktyg eller liknande) för att se vilka arbetsuppgifter som inte har behandlats under en viss tid (t.ex. 60 dagar). Jämför det resultatet med det arbete som håller på att slutföras. Är resultatet nedslående? Om ja, ha ett bra, gammaldags samtal med teamet om att avsluta arbetet innan du påbörjar ett nytt arbete. Försök att göra det per biljettyp så att du kan se vilka biljetter som går smidigt och vilka som fastnar på vägen.

Ovan: En Planview AgilePlace-tavla som visar WIP-gränser i Plan, Develop:Done och Deploy.

I ett effektivt pull-system underlättar WIP-gränserna samtal som kan förändra organisationen från en auktoritetsfokuserad strategi där man måste göra allt till en dialog om vad som är bäst att göra just nu, baserat på en kollektiv överenskommelse om de verkliga affärsmässiga och ekonomiska målen och lagets kapacitet att utföra arbetet.

Problem som orsakas av för mycket WIP

Förutom att skapa förseningar i leveransen av affärsnytta, skapar för mycket pågående arbete två andra stora problem:

  • Upptagenhet förväxlas med produktivitet.
  • Snabb återkoppling hindras.

När man förväxlar busyness med produktivitet ser det ut som om alla är upptagna, men det saknas konkreta resultat för att leverera värde till kunderna. Det är ingen bra plats att vara på om du menar allvar med att vara framgångsrik. För mycket pågående arbete innebär att man säger ja till för många saker. När du har en tendens att ta på dig mer arbete än du har kapacitet att göra, är det ett sätt att sätta och hålla dig till WIP-gränserna för att stoppa det här kaoset och ge dig själv (och dina medarbetare) tillåtelse att säga: "Tyvärr, inte i dag".

När människor måste vänta för länge innan de får feedback minskar värdet av feedbacken. De går vidare till nästa sak och har inte längre tid att ta till sig feedback. De förlorar därmed möjligheten att förbättra sitt arbete. Lean-filosofin är mycket inriktad på att ta bort slöseri, men det är svårt att se slöseri om man inte har levererat något och fått feedback på det. I Kanban-världen är värde viktigare än att minska slöseriet, och snabb feedback är ett utmärkt sätt att skapa värde.

Slutsats

Det är lätt att kasta bort en gammal begäran när en ny begäran kommer in i backloggen. Men kostnaden för att påbörja nya arbetsuppgifter innan de gamla arbetsuppgifterna är avslutade kan vara hög. När för mycket arbete pågår uppstår negativa problem: multitasking ökar, flaskhalsar uppstår, beroenden ökar, möjligheter glöms bort och semestrar kommer. Och eftersom framstegen fördröjs, lägger folk mer arbete på hög. Detta leder till att arbetet tar längre tid än vad det borde och försenar leveransen av värde för verksamheten. Genom att använda WIP-gränser kan du hjälpa ditt team att minska multitasking och fokusera på att slutföra det arbete som är viktigast.

WIP-gränser: Hur man reser säkert in i det okända

Är du intresserad av att lära dig hur du kan börja använda WIP-gränser med ditt team? Den här bloggserien i tre delar och det här webbseminariet kommer att fungera som en guide och förklara inte bara de vanligaste hindren du kommer att stöta på, utan också hur du kan övervinna dem. Starta nu.

Relaterade inlägg

Skrivet av Dominica Degrandis

Dominica lär ut Kanban till DevOps-entusiaster. Som Executive Consultant på LeanKit kombinerar Dominica erfarenhet, praktik och teori för att hjälpa organisationer att öka sin kapacitet. Hon vill gärna ge synlighet och transparens i olika team för att avslöja kritisk information för båda parter. Följ henne på Twitter på @dominicad.