SAFe är inte tryggt

Under årens lopp har vi arbetat med flera mjukvaruföretag som använder Scrum i kombination med Parmatur Puls. Nyligen har SAFe dykt upp i en del diskussioner med potentiella kunder som ett alternativ till Parmatur Puls. Jag kan nu börja se ett mönster med samma problem i alla dessa Scrum-företag. Det här är problem som vi inte har stött på tidigare. Det har fått mig att fundera och sammanställa mina slutsatser. Vad händer i de företag som använder Scrum och varför har SAFe nu dykt upp på scenen?

”Det är inte meningen att ni ska känna er trygga. Det är ert jobb som ingenjörer att hantera osäkerhet och risker.”

I Scrum samlokaliseras olika kompetenser som behövs för att utveckla funktionalitet, såsom mjukvaru-utvecklare, testare och ingenjörer. Med tiden har Scrum-teamen blivit permanenta, eftersom Scrum-modellen rekommenderar det men kanske också av bekvämlighet. Om en grupp människor sätts samman och tillåts bli samspelta, blir det svårt att efter en tid flytta ut personer. Och människor som arbetar i permanenta och självorganiserande team tycker ofta om sin arbetssituation. Men teamen är av nödvändighet små och deras leveranser blir därmed vertikala skivor av funktionalitet, inte en integrerad produkt.

Problemen med att organisera utvecklingsarbetet i små fasta team kommer att framträda efter några år. Med vertikala skivor av funktionalitet kommer teamen helst att arbeta med inkrementell produktutveckling. De lägger till funktionalitet i sin befintliga kod. Stories kan brytas ner i tasks av en produktägare och läggas in i ett uppgiftshanteringssystem, där utvecklarna själva väljer sin nästa arbetsuppgift utan att behöva kommunicera med varandra. Då vet ju alla vad som behöver göras, eller hur? Det här låter kanske bra till att börja med, men det betyder att samma produkt kommer att uppfinnas gång på gång, dvs. teamet arbetar med inkrementella förbättringar och produktvård. Hur mycket nytt värde skapar det för företaget och dess kunder?

Självorganiserade team har stora fördelar, de skapar möjlighet att fokusera insatserna i en grupp. Men det finns en baksida. Det är svårt för någon utomstående att påverka vad teamet fokuserar på; teamet skapar lätt sin egen agenda. Det kan också finnas starkt grupptryck på människor som är avvikande, som tenderar att stötas bort. Tätt sammansvetsade team riskerar också att skapa konflikter mellan grupper, t ex mellan grupper som arbetar med hårdvara respektive programvara som kan ha svårt att förstå varandras förutsättningar. Konformationstrycket gör också att gruppen över tid förlorar sin förmåga att tänka kreativt. De kommer då inte längre kunna arbeta med något annat än inkrementell utveckling.

Med tiden har en rigid organisationsstruktur skapats genom introduktionen av Scrum-teamen, som genom sin förmåga att organisera sig har fått en mycket stark position i företaget. Samtidigt har många företag inte arbetat tillräckligt med övergripande strategier och arkitektur. Och i större organisationer uppstår det ett gap mellan ledning och utvecklare. Detta innebär att de strategier som formuleras av cheferna inte kommer att genomföras. Vi har nyligen stött på ett flertal företag som arbetar med Scrum, vilka alla vittnar om betydande problem med sin produktarkitektur.

I komplexa produkter med både mjukvara och hårdvara kommer integrationen av den kompletta produkten vara en utmaning. När du arbetar med Scrum hamnar integration och release utanför teamet, eftersom varje Scrum-team levererar en bit av funktionaliteten. Det här är liknande problem som uppstår när vattenfallsmodellen lägger arbetet med upprampning till produktion sist i flödet. Det vill säga; fel och brister upptäcks när det är för sent.

Scrum verkar t o m ha orsakat allvarliga skador på en del företag. Kanske har själva förståelsen för vad produktutveckling egentligen är gått förlorad. Ingen har längre erfarenhet av att göra prototyper för helt nya produkter. Produktutvecklingsresurserna spenderas på kontinuerliga förbättringar, inte kontinuerliga innovationer.

Det är lätt att förstå att företagsledningar nu tvingas agera. Kan SAFe vara en lösning? Mitt svar är – NEJ! SAFe är inte säkert och tryggt. Vad SAFe gör är att återuppfinna linjeorganisationen baserat på de permanenta Scrum-teamen, introducera fler mellanchefer i nya roller och utöver det lägga till en hel del byråkrati. Då är vi tillbaka där vi började i början av 90-talet, med kommunikationsproblem mellan ingenjörerna, svårigheter att ta beslut och en mycket långsam produktutveckling.

Vem kan vara nöjd med en SAFe-lösning? Kanske Scrum-teamen som inte behöver ändra sitt sätt att arbeta, åtminstone initialt innan kontrollmekanismerna i ett byråkratiskt system slår till. Men de grundläggande orsakerna till de akuta problemen i verksamheten har inte lösts.

Grundarna av Scrum inspirerades av en artikel i Harvard Business Review 1986. Nu är det dags att gå tillbaka till källorna och se vad forskarna faktiskt rekommenderade. Vi måste forma ”The NEW New New Product Development Game”, för att bryta ner de rigida strukturerna som har byggts över tiden med Scrum och som förstärks ännu mer med SAFe.

Forskarna pekade på sex kännetecken för framgångsrik produktutveckling.

Så varför får inte Parmatur Puls de problem som Scrum uppvisar?

Slutsatser – SAFe är inte tryggt

Det största problemet med Scrum är idén att permanenta team ska ansvara för sin del av en befintlig lösning. Dessa team påverkas över tiden av grupptänkande där nya idéer hämmas. Grupptänkande gör det också svårt för ledningen att fokusera utvecklingsarbetet på nya innovativa produkter.

För att hantera denna situation har SAFe utvecklats. Men SAFe är en lösning på ett symptom. Problemet finns i Scrum. Lösningen är inte att ta bort Scrum, utan att ändra hur modellen används. Det är idén med permanenta team som måste bort.

Det kontinuerliga arbetet på ledningsnivå med vidareutveckling av strategisk inriktning och strategisk design är avgörande för företagets framgång. I Parmatur Puls är allt strategiskt arbete starkt kopplat till produktutveckling. Frekventa beslut tas i ett nätverk av pulsmöten där visualiserad aktuell information skapar transparens.

Du kan använda ett Scrum-liknande tillvägagångssätt på ledningsnivå. Både Toyota och Scania började göra det redan i mitten av 1990-talet. Toyota kallade det stå-up-möten i en Obeya, Scania kallade det pulsmöten i ett pulsrum.

Parmatur Puls är en modell för agil styrning av strategi och utveckling, med få fasta roller, ett minimum av byråkrati och en enkel struktur. Parmatur Puls har inbyggd instabilitet och kontroll, allt i ett.

Det är inte meningen att ni ska känna er trygga. Ni är ingenjörer som arbetar med produktutveckling. Det är ert jobb att hantera osäkerhet och risker. Först då kan ni utveckla riktigt bra produkter som skapar mervärde för era kunder och garanterar ert företags framtid.

---

Läs mer om agilt ledarskap i boken The Principles of Agile Management.