Arbeta agilt vs tänka agilt

Att tänka agilt

Att arbeta agilt innebär ofta att ett ramverk som Scrum eller SAFe används. Gemensamt för de flesta agila ramverk är att olika event sker på kadens. Normalt är att dessa olika event bokas in och att deltagarna börjar trevande, men förbättrar sig över tid. Naturligtvis sker ofta en hel del olika utbildningar när en transformation påbörjas.

När väl strukturen satt sig så kan man säga att man arbetar agilt. Men det utlovade resultaten kanske uteblir och frustration uppstår. Det som då ofta är problemet är att många i organisationen fortfarande tänker traditionellt men försöker arbeta agilt. Den kombinationen fungerar kortfattat inte. Att tänka agilt kräver en hel del förändring. Nedan följer ett antal exempel som jag upplevt.

Det agila manifestet (www.agilemanifesto.org) ger oss 4 värderingar och 12 principer. Redan på den första värderingen som är "Individuals and interactions over processes and tools" uppstår en hel del icke önskvärda beteenden. 

Ett sådant beteende är den utbredda e-postkultur som finns. Den innefattar bland annat att e-posta personer som sitter i samma kontorslandskap eller till och med jämte varandra istället för att prata med varandra. Detta beteende försvaras ibland av att det är "bra att ha det dokumenterat". Det må vara så men det är inte ett agilt tankesätt. Se därför till att prata med dina medarbetare istället för att skriva till dem. Nästan alla har ju dessutom en telefon om medarbetaren inte sitter i landskapet när du vill prata.

En annat beteende som inte är ovanligt är att man kommunicerar via verktyg. Det kan innebära att man skriver kommentarer i verktyg som JIRA eller Confluence istället för att prata.

Vem har ansvaret?

Ett annan frågeställning handlar om "Vem har ansvaret?". Traditionellt finns det ofta en projektledare, programledare eller kanske en linjechef som uttalat har ansvar för ett område eller leverans. I det agila är ansvaret istället delat på olika sätt där Product Owner kan sägas ha ansvaret för vad som skall utvecklas, medan ett eller kanske flera team ansvarar för hur det skall utvecklas. Därtill har Scrum Mastern ett ansvar för att utveckla teamet. Detta delade ansvar attackeras ibland med tesen att "delat ansvar är inget ansvar".

Nyckel till att få det delade ansvaret att fungera är att släppa kontrollen. Chefer behöver istället bli ledare och skapa förutsättningar för team att utvecklas och kunna ta ansvar. En start i detta är att sluta fråga "vem har ansvaret".

Ett tredje område som jag vill ta upp handlar om att skapa ett snabbt flöde (Lean Flow) och ta bort flaskhalsar. Att kunna ha "många bollar i luften" anses eller har åtminstone ansetts som en bra egenskap. Men faktum är att för att skapa ett snabbt flöde för arbetspaket att det att de påbörjas till dess att de är klara krävs att man i princip fokuserar på en eller få saker i taget.

Säg nej till stakeholders

Inom agilt såväl som inom Lean kallas detta för "Limit Work in Progress" eller bara "Limit WIP". Min upplevelse är att många förstår konceptet men har synnerligen svårt att leva upp till det. En konsekvens är nämligen att man måste säga nej till olika stakeholders. Att säga nej till stakeholders samt dessa förstår konceptet med limit WIP är en kultur som är svår att skapa. En duktig Product Owner har som en av sina viktigaste egenskaper att motivera ett nej mot stakeholders, men att tänka på det sättet är ännu ovanligt.

Detta område innefattas också av en princip som handlar om "reduce batch size". Dvs att arbetspaketen skall vara små. Detta tillsammans med principen om limit WIP gör att flödet (throughput) av arbetspaket blir stort vilket har en mängd fördelar. Det finns ett par koncept inom det agila arbetssättet kallat MVP - Minimum Viable Product samt MMF - Minimum Markateble Feature som har som syfte att reducera arbetspaketets storlek. Dessa koncept är något som är svårt för många att implementera. Det blir istället mycket stora arbetspaket som tar mycket lång tid att utveckla. När man därtill vill göra många sådana så tar det alldeles för lång tid innan slutanvändaren nås.

En agil transformation handlar både om att arbeta och tänka agilt. Att tänka agilt är klart svårare.