Agila beslutsnivåer

Självorganisering eller ledarskap? Anarki eller demokrati? Ordning eller kaos? 

Att agila arbetssätt bygger på samarbete över gränserna är välkänt idag. Att överbrygga klyftor i såväl kompetens som förväntningar, erfarenhet, t.o.m. geografi är dagliga inslag för oss som arbetar agilt.

Att det ibland kan vara nog så svårt att göra detta framgångsrikt i en liten verksamhet med ett eller ett par team och deras interaktion med produktägare är bekant för de flesta, och när vi skalar arbetssättet stöter vi nästan alltid på de mest oväntade problem med kommunikation. Utmaningen att skala upp agila arbetssätt är ett av de hetaste samtalsämnena i den agila sfären idag, och även om de flesta är överens om att det är fullt möjligt (flera goda exempel och förebilder finns) råder oenighet om tillvägagångssättet.

För en utomstående kan det te sig som en strid mellan självorganisering och hierarki, ordning och kaos, anarki och demokrati. Men det är förstås inte sant.

För att ta ett relaterat exempel: Kanban och Scrum inte är ”bättre” eller ”sämre” ramverk än varandra. Faktum är att de fungerar olika bra för olika miljöer och olika typer av arbete, och det är mycket vanligt idag att de kombineras för att angripa t.ex. en mix av nyutveckling och förvaltning på ett effektivt sätt. På samma sätt kan man betrakta de olika ramverk som finns idag för att skala de agila principerna för arbete till en större verksamhet som fungerande angreppssätt som kan och bör kombineras och vidareutvecklas för att passa verksamheten de används i.

Tre nivåer av musikinstrument - i LEGO

Tre nivåer av musikinstrument

Låt oss idag titta lite på tekniker som förespråkar att skapa en struktur för att leda arbetet där många team är involverade, och som lägger till nya roller till befintliga ramverk. Det ramverk jag själv arbetat med på senare år, Scaled Agile Framework (SAFe), skapar tre beslutsnivåer i verksamheten, och förutsätter en produkt som av olika skäl inte är kostnadseffektiv att driftsätta varje sprint. Därför planeras arbetet i så kallade agila leveranståg som består av ett antal sprintar följd av en driftsättning. Tågen och deras innehåll planeras upp av alla inblandade team under två dagar i starten av varje tåg, en övning som brukar vara väldigt krävande men också tillfredsställande för alla inblandade.

En kritik som anförs mot SAFe med jämna mellanrum är att den introducerar onödig hierarki i verksamheten, något som påstås strida mot agila värderingar. Jag anser att det beror på en missuppfattning, men låt mig bekänna färg först.

Jag förespråkar ledarskap i agila verksamheter. Jag anser att ledare behövs för att göra det möjligt för individer och team att utvecklas, lära sig hantera konflikter och motsättningar, och för att helt enkelt hjälpa agila team med beslut de helst vill slippa ta så de kan fokusera på arbetet framåt. Jag har själv arbetat med flera organisationer som oavsiktligt introducerat mobbning och kamratuppfostran som en del av en idealistisk förhoppning om att skapa agila team som ska ”hantera beslut och konflikter själva”. Att agera på det sättet är förstås att ignorera decennier av forskning inom arbetspsykologi och gruppdynamik, ett område vi lär komma tillbaks till vid ett senare tillfälle. Därmed inte sagt att jag avfärdar de mer organiska agila arbetssätten, de är högintressanta för team och verksamheter som har en hög grad av samhörighet mellan kollegorna. Men det är i många fall en lång väg dit, som i mina ögon kräver ledarskap.

Med det sagt, anser jag att många som kritiserar beslutsnivåerna i SAFe tittar på dem med fel ögon. För mig fungerar beslutsnivåerna som ett sätt att skilja på strategiska, taktiska och operativa beslut. Dessa beslut tas i olika forum, och ibland – men långt ifrån alltid – av olika roller i verksamheten. Huvudsyftet med beslutsnivåerna är i mina ögon att bygga en miljö för agila team som låter dem vara agila. På högsta nivån arbetar de som är ansvariga för strategiska produkt- och verksamhetsbeslut med att se till att de prioriteringar  och önskemål som ligger på kö uppfyller de långsiktiga krav och önskemål som finns för verksamheten. Ska vi satsa lokalt eller globalt? Vilka är våra målgrupper? Hur ser livscykeln för vår nuvarande teknikplattform ut? Vilka möjligheter ger den oss? Osv.

Genom att kontinuerligt arbeta med dessa frågor på ett strukturerat sätt och bereda ärenden så att nyttan och syftet blir tydligt, gör man det möjligt för agila team att ta tag i dem. En del går att dela upp i mindre delar tämligen omgående, medan andra kräver utredning eller att vi prövar några alternativ för att hitta en väg framåt. Den taktiska nivån, eller programnivån i SAFe utgör spelplanen, där de agila teamen uttrycker flera saker, bland annat:

  • Sin kapacitet, dvs. hur mycket som rimligtvis kan komma med i nästa leveranståg
  • Sin kunskap om området, t.ex. förhållandet mellan utredning/prövning och genomförande i kommande sprintar
  • En vettig sekvens, ur deras perspektiv, att göra arbetet i

När man arbetar strukturerat med den här typen av beslutsnivåer – egentligen ett sätt att skapa olika forum för olika tidshorisonter för beslut – händer flera intressanta saker.

Kopplingen mellan alla nivåer, det vill säga, strategisk riktning, livscykel, prognos för arbetet på medellång sikt, sprintåtagande och min todo-lista för dagen blir tydlig. Det ökar i min erfarenhet tilliten mellan de som arbetar med olika typer av frågor och hjälper de agila teamen att arbeta fokuserat istället för att svara på återkommande ”hur går det?”-frågor.

En stor fördel jag också upplevt är att det är ett sätt att hjälpa agila team att komma ur den trånga ”planeringshorisont” om en sprint många sitter fast i, och som gör det svårt att ta sunda designbeslut.

Ytterligare en fördel är att frågor och beslut som rör olika tidshorisont oftare hamnar i rätt forum, vilket ger mer fokuserade möten. Team tar egna designbeslut i sprint, som är i linje med riktlinjer lagda för leveranståget, som i sin tur har satts i samförstånd med den övergripande tekniska riktningen och livscykeln för ingående komponenter och teknologi.


 

I kommande delar ska vi titta närmare på hur arkitektur och förvaltning hanteras i SAFe, och så småningom ska vi lyfta blicken och titta på fler ramverk som t.ex. bygger på samförståndsmöten istället för beslutsnivåer. Och om det finns en motsättning mellan agilt och projekt?