SAFe som svar på brister i Scrum

Under åren har vi arbetat med flera mjukvaruföretag som använder Scrum. Under det senaste året har också SAFe dykt upp i diskussioner med potentiella kunder.

Jag kan nu se samma problembild dyka upp hos alla dessa företag. Det här är problem som vi aldrig har sett med Puls. Det har fått mig att försöka sammanställa mina bedömningar och åsikter. Vad är det som händer i företagen som kör Scrum och varför har SAFe dykt upp på arenan?

I Scrum samlokaliseras olika kompetenser som behövs för att göra en funktionalitet, t ex sofware utvecklare, testare och ingenjörer. Över tid har Scrum teamen blivit permanenta team.  En anledning kan vara att det är besvärligt att flytta runt personal i lokalerna och självorganiseringen i teamen gör att personalen trivs. Men teamen är små och deras leverans blir därmed en vertikal skiva av funktionalitet, inte en integrerad produkt.

Problemen med Scrum

Problem med att organisera utvecklingsarbetet på det här sättet blir synliga först efter en tid. Med en vertikal skiva funktionalitet kommer teamet företrädesvis att arbeta med inkrementell utveckling eller produktvård, snarare än utveckla nya produkter. Scrum teamen lägger till funktionalitet i sin existerande kod.

Stories bryts ibland ner till tasks av en produktägare och läggs in i ett IT system där teammedlemmarna plockar nästa uppgift, istället för att teamet tillsammans planerar och delar upp sitt arbete.

Självorganiserade team har stora fördelar, det skapar möjlighet att fokusera ansträngningarna i gruppen. Men det finns en baksida. Det finns risk för att team som arbetar länge ihop, sätter sin egna agenda.

Det kan också uppstå ett hårt grupptryck som pressar ut alla personer som är avvikande eller driver infekterade konflikter mellan olika team, speciellt kanske mellan hårdvara och mjukvara som har svårt att förstå varandras förutsättningar. Det konformativa trycket gör också att gruppen över tid förlorar sin förmåga att tänka nytt. De kan inte arbeta med något annat än inkrementell utveckling.

Med tiden etableras en rigid struktur av fasta Scrum team, som genom sin förmåga att organisera sig har fått en mycket stark maktposition i företaget.

Samtidigt har många verksamheter inte uppmärksammat behovet av att utarbeta övergripande strategier och arkitektur. Det saknas helt enkelt personer på mellanchefsnivå som kan göra det arbetet. Därmed har kanske också förståelsen för vad produktutveckling egentligen är gått förlorat. Hur tar man en prototyp till en färdig produkt?

I större organisationer lyckas man inte överbrygga gapet mellan ledning och utvecklare, vilket skulle kräva system för att forma och implementera strategier som får organisationen att agera som en helhet.

I komplexa produkter med både mjukvara och hårdvara kommer integration av Scrum teamens resultat att vara problematisk. Integration och release hamnar på programnivå eftersom varje Scrum team levererar en skiva av funktionaliteten. Det uppstår motsvarande problem som när vattenfallsmodellerna la allt arbete med produktionssättning av produkten sist i flödet.

SAFe, en ny variant av vattenfallsmodellen

Det är lätt att förstå att företagsledningen nu tvingas agera. Kan SAFe vara en lösning? Min bedömning är – NEJ! Vad SAFe gör är att återuppfinna linjeorganisationen utifrån de fasta Scrum teamen och  införa mellanchefer i form av ett antal nya roller.

För att råda bot på den kommunikationsunderskott som uppstår i en stuprörsorganisation lägger SAFe på processer och byråkrati. Även den gamla vattenfallsmodellen har återuppstått i en ny skepnad. Slutligen läggs strategi som en ostskiva ovanpå programnivån utan kontinuerlig koppling till det pågående operativa arbetet.

Vem kan vara nöjd med en SAFe lösning? Möjligen Scrum teamen som inte behöver ändra sitt arbetssätt. Åtminstone inledningsvis innan kontrollmekanismerna i ett byråkratiskt system slår till och landar också på deras bord. Grundorsakerna till de akuta problemen i verksamheten har man däremot inte kommit tillrätta med.

Forskningen bakom Scrum

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 egentligen kom fram till. Vi måste kanske forma ”The New New New Product Development Game”, för att bryta ner de rigida strukturer som har satt sig över tiden med Scrum.

Forskarna pekar på sex karaktärsdrag hos framgångsrik produktutveckling.

1. Inbyggd instabilitet. Ledningen ger projekten en stor frihet men sätter utmanande mål. Att man arbetar i projekt är i artikeln självklart. Personer förs tillsammans tillfälligt för att lösa en utmanade uppgift. Detta förutsätter att ledningen kontinuerligt arbetar med strategisk inriktning och design som leder fram till utmanande projektmål.

2. Överlappande utvecklingsfaser. Projektet levererar hela lösningar, inklusive den tekniska integrationen med befintliga produkt- och produktionssystem (de arbetar inte med en skiva  funktionalitet). Gruppen utnyttjar de spänningar och konflikter som uppstår mellan vitt skilda kompetenser för att komma fram till nya lösningar.

3. Självorganiserande projektteam som interagerar tätt tillsammans. Man driver projektteamet mot en punkt där alla befintliga lösningar omprövas. Projektet tvingas tänka om för att komma med stora genombrott som kan uppfylla projektmålen.

4. Multi-lärande uppstår ur nära samarbete med andra kompetenser och nya människor. Att avlära är många gånger viktigt för att lyckas med produktutveckling. Istället för team med hög specialistkompetens används företrädesvis icke-experter. Icke-experterna uppmuntras att skaffa sig kunskap och färdigheter som de behöver genom att arbeta med uppgiften. Till skillnad från experterna som hatar misstag, kommer nybörjarna vara villiga att ta risk och utmana status quo.

5. Överföra lärande. Här pekar författarna på risken med att överföra visdomsord via standardiserade processer som baserar sig på lyckade historiska exempel. Det kommer fungera i en verksamhet som under en period har en stabil omgivning och svag konkurrens. Men det straffar sig när förändringstakten ökar.

6. Subtil kontroll. Projekten görs semi-autonoma. Ledningen undviker den rigida kontroll som finns i en byråkratisk vattenfallsmodell. Istället etableras system för frekventa avstämningar, t.ex. med pulsmöten, demonstrationer och gemensamma workshops.

Företag med Puls frågar inte efter SAFe

Varför får Puls inte de problem som Scrum dras med?

För det första arbetar vi i Puls med projekt där personal allokeras till uppgiften. Det är utomordentligt ovanligt med permanenta team. Projekten levererar hela produkter som ofta också är industrialiserade, och projektteamet ansvar för den tekniska integrationen.

För det andra bygger Puls på att ledningen utarbetar och ständigt utvecklar en strategisk inriktning och strategisk design, vilket driver allt utvecklingsarbetet i projekt och uppdrag.

För det tredje hålls frekventa visualiserade pulsmöten i pulsrummet både för strategiskt och operativt arbete, vilket flödar information och beslut som snabbt kan korrigera inriktningen på allt arbete.

För det fjärde undviker vi i Puls att använda experter i projekten. De används bättre som mentorer eller för att utarbeta arkitektur.

Kommentera