De senaste åren har jag jobbat med att hjälpa team och organisationer att förstå och använda Scrum. Jag har jobbat en hel del med produktutvecklande företag, och det är i utvecklingsarbete Scrum verkligen kommer till sin fulla rätt. Samtidigt består arbetet med att lansera mjukvaruprodukter av så mycket mer än bara själva utvecklingen. Drift, support och marknadsföring är några exempel på aktiviteter som är avgörande för framgång.
Förra hösten åt jag lunch med en branschkollega på en restaurang i Uppsala och vi pratade om hur det gick för deras utvecklingsteam, som nyligen börjat använda Scrum. Det gick utmärkt. Arbetet var fokuserat och tydligt, och man hade lyckats genomföra ett komplext projekt framgångsrikt.
Samtidigt kände man på driftssidan att man ville ha ett lika engagerande och tydligt sätt att styra och följa upp sitt arbete. Jag berättade om något jag studerade just då – visuell styrning med kanban. Så vitt jag kunde se var de bakomliggande principerna sådana vi känner igen från Scrum, även om de praktiska handgreppen ibland ser lite annorlunda ut. Vi kom överens om att försöka få till ett kort och fokuserat samarbete för att få till en kanbanlösning för deras driftsgrupp. På så vis skulle även de kunna dra nytta av tankarna bakom Scrum.
Kanban är japanska, och betyder till vardags helt enkelt skylt eller tavla. Inom tillverkningsindustrin har begreppet däremot fått en mer specifik betydelse. Där betyder kanban ett signalsystem som styr flödet i produktionen. Jag är absolut ingen expert på industriell produktion, men jag kan göra ett försök att förklara systemet som jag förstått det.
Här är ett konkret exempel. En person som arbetar med att montera en komponent för en viss maskin behöver en mängd olika delar för att kunna göra sitt jobb. Hur många av varje? Det skulle man kunna försöka styra med ett avancerat datorsystem som prognosticerar behoven framöver. Eller så använder man kanban.
I ett kanbansystem signalerar varje del i en produktionskedja sitt behov av nytt material från ett föregående steg genom att tydligt flagga upp behovet. Rent praktiskt kan signaleringen ske genom att en låda med delar tömts, och därför skickas för påfyllning tillsammans med ett litet instruktionskort – en kanban – till den som kan fylla på lådan. Lådan fylls, och skickas tillbaks till beställaren. På samma sätt fortsätter beställningarna “bakåt” i produktionsledet. Fördelen? Processen styrs efter behov istället för efter spekulativa prognoser. Kanban blir därför en nyckelteknik i Just-in-Time-processer.
Så vad har kanban att göra med till exempel drift av mjukvara? Vi kan inspireras av metoden för att styra och följa upp arbetet i till exempel en driftsgrupp på ett sätt som är både tydligt och enkelt.
Våra kanban blir helt vanliga post-it-lappar som vi flyttar på en whiteboard. Whiteboarden designar vi för att ge en helikopterbild av arbetsprocessen. Resultatet: ungefär samma som när vi sätter upp sprintbackloggen på väggen och får en visuell sprintbacklogg, men anpassat för den typ av situation som till exempel ett drifts- eller supportteam befinner sig i. En vanlig invändning mot Scrum från denna typ av grupper är att det är svårt att få till iterationer, eftersom man arbetar så reaktivt med plötsligt inkommande saker. Mot det kan man förstås invända att man då borde fokusera på att eliminera så många oväntade saker som möjligt, och det är väl rätt i teorin. I praktiken måste man förstås ända styra arbetet under tiden, och varje sätt att få mer fokus och lite lugn och ro kanske gör det lite lättare att faktiskt börja eliminera rotorsaker till problem. Kanban kan vara ett sådant verktyg.
Med kanbantavlan blir det lättare för samtliga i arbetsgruppen att se vilket arbete som väntar, vad som pågår, och vad som är på väg att göras klart. Gruppen får också lättare att ta på sig rätt mängd arbete vid varje givet tillfälle, något som är viktigt inte bara för att undvika utbrändhet, utan också av mer kortsiktigt ekonomiska skäl. Man får helt enkelt mer klart om man undviker att överbelasta sig, och kvaliteten på arbetet blir högre.
För gruppens intressenter (t.ex. mottagare av de arbetsresultat gruppen levererar) finns också fördelar, som att det blir lättare att se status på arbetet. När synligheten ökar minskar ofta stressen. Det är helt enkelt svårare att bli stressad när man känner att man har koll på läget. När stressen minskar ökar lugnet, och vi fattar som regel bättre beslut när vi är lugna än när vi är uppjagade.
I nästa bloggpost tänkte jag skriva lite om hur det kan se ut rent praktiskt.
Känner du till en arbetsgrupp som skulle vilja dra nytta av fördelarna med att jobba lättrörligt, men som inte riktigt känner att Scrum passar perfekt? Hur gör de för att få bästa möjliga delaktighet och tydlighet?