Varför skala agilitet? Vad är SAFe?

Agilitet har länge varit förknippat med startups och mindre organisationer medan de större bolagen förknippas med långa beslutsvägar och en svårighet att dra nytta av nya möjligheter som uppenbarar sig. De är helt enkelt för långsamma på bollen och har inte möjlighet att reagera tillräckligt fort för att hinna med i alla svängarna. Vi ser dock att allt fler större företag och organisationer väljer att anamma de agila arbetsmetoderna i förhoppning om att bli mer lättrörliga. Men med en stor organisation kommer ökad komplexitet; större projekt, organisatoriska hierarkier och sammanvävda arkitekturer. Att applicera agila metoder såsom Scrum i dessa typer av bolag är ofta inte tillräckligt för att nå ända fram, då det i och med detta dyker upp andra problem. Till exempel koordinering av team som i större produkter har beroenden mellan varandra. Ett sätt att tackla detta är genom att föra in det skalade agila ramverket SAFe.

Varför skala agilitet?

Organisationer som har jobbat med agila förhållningssätt en stund, upptäcker ofta att det saknas en entydig struktur för hur man får flera team att arbeta mot samma mål, produkt eller riktning. Man upptäcker också att det skulle finnas en fördel med att kunna fokusera utvecklingsriktningen med kraften från flera team samtidigt, istället för isolerat arbete från de enskilda och självstyrande team man redan har. Under årens lopp har flera sådana behov definierats och flera ramverk för så kallad skalad agilitet har dykt upp på marknaden som stöttar och försöker lösa dessa problem.

Dock: den första regeln inom skalad agilitet är ”Don´t scale agile”! Hur paradoxalt detta än låter så är denna regel till för att påminna oss om att de agila arbetssätten inte bara är ännu ett sätt att skapa komplexa strukturer. Utan tvärt om verkar för att mota bort komplexiteten, bland annat genom skapandet av självstyrande team. Den första regeln finns då till för att påminna oss om att skala på rätt sätt, alltså där det är möjligt och där det finns behov. Något vi på Onbird ofta trycker på är att man bör ha något att skala innan man skalar. Börja alltså litet och se till att du har en fungerande agilitet på teamnivå innan du börjar skala upp det hela.

Ramverk för att skala det agila arbetssättet

För att hantera den komplexitet som kommer med stora organisationer och fortfarande dra nytta av de agila metoderna har flera ramverk tagits fram som stödjer skalad agilitet. Bland dessa ramverk hittar vi SAFe; Scaled Agile Framework, som ett av de mest populära och implementerade. Bland dess ramverkssyskon finns bland annat LeSS, Nexus, Scrum@scale samt fler.

Vad är SAFe?

SAFe är ett öppet ramverk som strävar efter att ge företag och organisationer en holistisk syn på agilt arbete där hela eller valda delar av organisationen får plats under dess paraply. SAFe kombinerar värderingar och principer från både Lean och Agile med hierarkiska nivåer för att bättre passa större organisationers behov.

Här kommer en kort-kort introduktion till de tre olika nivåerna där flödet från affärsstrategiskt beslut till implementering beskrivs:

Portfolio management nivå

Låter bekant? SAFe bygger på den typiska PMO-infrastrukturen men gör det på ett sätt som stödjer dess Lean-Agila praxis. Det är i denna nivå som affärsstrategiska beslut tydliggörs genom värderade och prioriterade teman som sätter riktning för produkterna och förmågorna. Teamet på denna portfolionivå är ansvariga för att underhålla en prioriterad backlogg bestående av affärs-epics som stödjer företagets strategiska plan.

Programnivå

I programnivån plockas de affärs-epics som skapades i portfolionivån för att här bli nedbrutna till features/funktioner som kommer att utvecklas under det som SAFe kallar Program Increment (PI). Det är en iterativ större cykel som innehåller ett bestämt antal scrum-sprintar för de olika team som arbetar inom samma produkt/värdeström. Detta är även den nivå som definierar det de flesta kan om SAFe: Releasetågen (ART).

Teamnivå

Teamen inom ett releasetåg arbetar såsom det är föreskrivet i ramverket för Scrum och inför starten av ett nytt Program increment mikroplanerar respektive team sina sprintar utefter den plan som uppstod inom programnivåns planeringsarbete.

Frågor att ställa sig innan man skalar

1. Vilket problem löser vi genom att skala?

2. Vad kommer vi åstadkomma genom att skala?

Att svara på ovanstående frågeställningar ger en god grund för att ta reda på om den skalade versionen av agilitet passar ert företag/organisation.