300 % bättre ledtid – från ”scrumish” SAFe till Kanban

Som agila coacher märker vi ofta snabbt att det ramverk en organisation valt inte alls passar arbetets natur, arbetets flöde eller den organisatoriska kontexten. Särskilt tydligt blir det när ett enda ramverk har skalats brett och snabbt, med samma lösning för alla, utan att någon undersökt de systemiska orsakerna bakom prestationsproblemen.

Det här är berättelsen om ett uppdrag där Kanban visade sig passa bättre än Scrum, där SAFe skapade fler problem än det löste — och där organisationen inledningsvis var rädd för att låta teamen själva utforska vilket arbetssätt som fungerade för dem. Resultatet blev en förbättring av ledtiden med 300 %.

1. Vilket problem skulle lösas?

Uppdraget var formulerat i en enda mening: ”vi behöver höja avdelningens förutsägbarhet till minst 80 %”. Teamen arbetade med Scrum i ett SAFe-upplägg, ett beslut som fattats fem år tidigare när allt agilt centraliserades under samma tak. PI-planering användes i praktiken som en mycket stor batchöverföring var tredje månad, och resultatet blev kvartalsvisa gantt-scheman på user story-nivå över det arbete verksamheten tryckte in.

Intervjuer och värdeflödeskartor visade en välbekant bild: ett push-baserat system, features buntade i projekt till stora batchar och svag prioritering i både program och backlog. Scrum är ett pull-baserat system, men användes inte så. De första rekommendationerna handlade därför om att balansera kapacitet mot efterfrågan: bryta upp features ur projekten, arbeta i mindre batchar, hålla regelbunden backlog refinement, sätta tydliga definitioner av ready och done, och bygga T-formad kompetens så att arbetet inte stannar när någon är sjuk eller slutar.

2. Var problemet verkligen problemet?

Produktledningen och coachkollegorna höll med om analysen. Teamen gjorde det inte. De menade att praktikerna inte skulle adressera grundorsaken — och de höll inte alls med ledningen om att de hade ett förutsägbarhetsproblem. Som coach är det intressant terräng: att vara inhyrd för att driva förändring i ett team som inte tycker att förändringen behövs, och som inte känner igen sig i måtten de bedöms på.

Två saker blev tydliga när antagandena ifrågasattes. Arbetet var fyllt av oväntade förseningar, ad hoc-förfrågningar och oundvikligt supportarbete — teamen hade helt enkelt inte tillräcklig information vid PI-start för att kunna bedöma vad som skulle hinnas med. Och teamen längtade själva efter ett nytt arbetssätt.

Den mest avgörande upptäckten var att intressenterna utanför IT inte brydde sig om PI-förutsägbarhet. De brydde sig om projektens milstolpar, som låg utanför IT. Ett teams förutsägbarhet mot en internt satt tremånaderscykel hade alltså inget affärsvärde alls.

3. Hjälpte eller stjälpte arbetssättet?

Tillsammans med produktägare och scrum masters blev slutsatsen svår att komma ifrån: det var det Scrum-baserade SAFe-upplägget som var problemet. PI-planeringarna var i praktiken ett påfyllningsmöte var tredje månad, där valen byggde på chansen att det fanns nog med information och att inget skulle fastna uppströms. Hundratals timmar möten gick åt till att gissa vilka epics som skulle ”vinna”.

Med den variation arbetet hade var leveransprecision mot milstolpar (%OTD) tillsammans med cykeltid i ett Kanban-system ett långt mer rättvisande och meningsfullt mått.

Att göra affärscaset för Kanban

Visualiseringen av slutsatserna blev det affärscase som behövdes för att pilota Kanban i ett av teamen — för att visa att PI-planering i förväg inte krävs för att leverera enligt projektens milstolpar. Vi höll en tio timmar lång STATIK-workshop med Kanbanspel, och använde lärdomarna för att rita upp tavlan, teamets policyer och övriga artefakter.

Teamet träffades dagligen för påfyllning, veckovis för retrospektiv och fanns tillgängligt för beroendehantering under PI-planeringarna — men inte mer. Inom tre månader gick ledtiden från 24 dagar till 8. Det dröjde inte länge innan fler team ville göra samma resa.

Vad vi tar med oss

Att ta sig tid att fråga om teamets nuvarande arbetssätt faktiskt hjälper mot det problem ni försöker lösa kan vara det som ger genombrottet. Ibland är svaret att måttet ska bytas, inte teamet.

Experience Report av Dandy People. Kunden är anonymiserad.