tisdag 8 mars 2016

Det är skalan och inte ramverken

Kritik mot storskaliga agila ramverk bygger ibland på att de bryter mot några av de fyra agila värdena eller de tolv bakomliggande principerna. Och det stämmer i viss mån. Men jag vill ändå försvara de storskaliga ramverken med att brotten mot till exempel de fyra värdena snarare är en produkt av storskaligheten än en produkt av ramverken.

Individer och deras samspel framför processer och verktyg? Ja, men om vi ska synka samspelet mellan hundra individer behöver vi ha något strukturerat sätt att samspela på. Kanske är en tvådagars produktinkrementsplanering med alla i rummet ett bättre verktyg för detta än många alternativ?

Fungerande mjukvara ofta? Ja, men i vissa tekniska plattformar innebär "ofta" var tionde vecka istället för varannan. Trögheten behöver inte ha med processen att göra, utan med övriga strukturer (tekniska och organisationella).

Kundsamverkan framför avtal och friskrivningar? Ja, men där är ramverken, både lättviktiga (som Scrum) och tyngre som (SAFe), helt i händerna på säljprocesser och avtalsjuridik. Det bästa vi kan göra är att försöka övertyga kunder och säljare och ledning om behovet av andra angreppsätt, men då behöver vi presentera ekonomiska modeller och andra kringstrukturer. Lättviktighet som innebär att vi inte svarar på vissa frågor från omgivningen hjälper oss inte i den kampen.

Omplanering framför att följa planerna? Japp. Men på rätt nivå. Om vi använder de agila verktygen för löpande omplanering till att vimsa omkring så tar vi oss ingenstans.

Agilitet har inget egenvärde. Värdet ligger i om ökad agilitet gör oss bättre på att uppfylla människors behov. Vi kan använda vår agilitet för att kunna söka oss fram, men den övergripande riktningen behöver vara fastslagen så att vi vet vilka behov som är viktigare än andra. Särskilt om vi är många som ska springa mot samma mål.

Mer lättviktiga metodramverk som Scrum döljer den här problematiken.  Man antar att det finns en person, PO, som helt enkelt vet hur man värderar och prioriterar. Men den PO som läser Scrumguiden får liten eller ingen vägledning för sitt arbete. "Organisationen ska veta vad som är viktigt och ställa sig bakom PO:ns prioriteringar!" Men hur organisationen kommer fram till detta besvaras inte.

Man kan ha synpunkter på hur SAFe föreslår att en produkt- och portföljledningsstruktur ska se ut. Det finns fler bra sätt att lägga upp arbetet på än vad SAFe beskriver. Men man är farligt naiv om man påstår att en sådan struktur inte behöver finnas utan bara är ett sänke för agiliteten. Scrum implicerar att den finns där. På något sätt behöver PO:n ta reda på vad som är viktigt inför sprintplaneringen.

Däremot lider flera storskaliga agila implementationer av problem. Men dessa menar jag snarare uppstår när man frångår två viktiga leanprinciper: den om "gemba" och den om "flow". Man behöver markkontakt och flöde. Men det får bli ämnet för ett annat inlägg.

Inga kommentarer:

Skicka en kommentar