Kategorier
agil organisation

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.

Inbyggd instabilitet. Ledningen ger projekten stor frihet, men de ger dem också utmanande mål. Att arbetet i produktutveckling utförs i projekt tas för givet i den här artikeln. Människor samlas tillfälligt för att lösa en utmanande uppgift. Instabilitet finns inte i permanenta Scrum-team, där finns tvärtom inbyggd stabilitet.

Överlappande utvecklingsfaser. Projekten levererar kompletta lösningar och tar produkten hela vägen till kunden (och inte en liten bit funktionalitet som ska monteras senare). Projektgrupperna använder de spänningar och konflikter som uppstår mellan olika kompetenser för att komma med nya lösningar.

Självorganiserande team interagerar nära varandra. Grupperna drivs till en punkt där alla befintliga lösningar ifrågasätts. Projekten tvingas tänka om för att kunna göra stora tekniska genombrott.

Multi-lärande uppstår genom nära samarbete mellan människor som har olika färdigheter och kompetenser och som inte tidigare har arbetat tillsammans. I permanenta team uppstår inte multi-lärande.

Överför lärande. Här pekar forskarna på risken att överföra visdomsord genom standardiserade processer baserat på framgångsrika historiska exempel. Det fungera enbart i ett företag som har en stabil miljö och svag konkurrens. Att lära om är ofta viktigare för framgångsrik produktutveckling. Icke-experter bör därför i stor utsträckning användas istället för grupper med hög specialistkompetens.

Icke-experter uppmuntras att skaffa sig de kunskaper och färdigheter de behöver genom att arbeta med uppgifterna. Till skillnad från experterna som hatar misstag är nybörjare villiga att ta risker och utmana status quo.

Subtil kontroll. Projekten ska vara semi-autonoma. Ledningen undviker den fastlåsta kontrollen som finns i en byråkratisk stage-gate-modell. Kommunikationen mellan projekt och chefer hanteras genom frekventa möten.

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

För det första bemannas Puls-projekt av personer som flyttas till uppgiften. Detta skapar inbyggd instabilitet, multi-lärande och överför lärande. Projekten levererar kompletta produkter som ofta också är industrialiserade, baserat på en plan med överlappande faser.

För det andra bygger Parmatur Puls på att ledningen ständigt arbetar med strategisk inriktning och strategisk design, vilket driver på allt utvecklingsarbete i projekt och uppdrag och skapar utmanande mål. Målen tvingar projektgrupperna att arbeta nära tillsammans och omvärdera befintliga lösningar.

För det tredje hålls frekventa visualiserade pulsmöten i pulsrummet för allt arbete, både strategiskt och operativt. Det påskyndar informationsöverföring och beslutsfattande så att ledningen vid behov omedelbart kan korrigera fokus för allt arbete. Chefen har kontroll, men på ett subtilt sätt.

Och för det fjärde använder vi icke-experter i projekten. Experter används bättre som mentorer, produktchefer eller för att utveckla produktens övergripande arkitektur.

Scrum är baserat på den forskning som presenterats ovan, men konceptet med permanenta team har inte stöd i denna eller någon annan forskning.

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.