tisdag 8 mars 2016

De storskaliga ramverkens grundantagande

De tre mest kända ramverken för storskalig agil utveckling: SAFe, Nexus och LeSS utgår från samma grundantagande: utmaningen för storskalig agil utveckling är hur man ska koordinera flera team runt en produkt.

SAFe kallar för ett "Agile Release Train". Nexus kallar det för ett "Nexus". LeSS kallar det inte för något särskilt, bara "det här är Scrum fast för flera team". Men det handlar om en samling av team som samplanerar sin utveckling av en och samma produkt från en och samma behovslista.

I grund och botten är ramverken väldigt lika. Nexus och Less beskriver inte behovslistan på något annat sätt än Scrum (det finns färdignedbrutna saker och ofärdiga) förutsätter värdeskapande varje sprint och tillför få (Nexus) eller inga (LeSS) nya roller. SAFe går lite längre och tar höjd för att varje värdeskapande kan ta några sprintar (ett sk "produktinkrement") och arbetar därför med en tredelad behovslista med vissa specifika artefakter i samt några nya roller för att koordinera detta.

Men inget av ramverken tar höjd för den situation där ett utvecklingsteam behöver stötta flera parallella utvecklingsansatser (projekt eller produkter). Inget av ramverken kan rakt av lösa frågan om hur man koordinerar värdeskapande som sker kors och tvärs och inte sällan i konflikt med varandra. SAFe har åtminstone i och med beskrivningen av värdeströms- och portföljnivån ett förslag på hur det ska lösas, men om ingen finns som kan prioritera på portföljnivå så fungerar det inte.

Problemet är vanligt, det kan lösas och det är inte jättesvårt att lösa även om det ofta inbegriper att man behöver se över beslutsmandat, projektfinansieringsmodeller och uppföljingsmodeller. Men det måste bli mer känt att inget av de existerande ramverken i sig löser den situationen.

Skalningsramverken försöker lösa koordineringsproblemet när flera team ska samsas om en backlogg. Det är en sorts skalproblem. Organisationer vill istället alldeles för ofta använda dem för att få ett eller flera team att samsas om flera skilda backloggar. Det går inte. Det är en helt annan sorts skalproblem.

Det spelar då ingen roll att ramverket har förmågan att hantera flera team. Det man behöver är ett sätt att hantera flera olika beställare med vitt skilda prioriteringar.

(...och apropå storskalighet, som vanligt säger Jurgen Appelo som det är!)

Inga kommentarer:

Skicka en kommentar