Akta SAFe (det skalade agila ramverket för företag), en ohelig inkarnation av mörkret
… eller kanske inte.
Om du hellre vill att SAFe talar för sig själv kan du använda länken ovan. Det finns hundratals sidor med dokumentation, timmar med videor, 15 olika utbildningskurser och mer. Om det låter lite mycket, ska jag göra mitt bästa för att ge en förklaring till hur SAFe fungerar när jag går igenom varje punkt.
På högsta nivå, kallad ”Portfolio”, förespråkar SAFe. finansierar obestämda ”Value Streams” – som vanligtvis representerar en produkt, produktlinje eller kundtyp. Lean Portfolio Management-funktionen (LPM) som styr finansiering (troligen samma personer som tidigare ansvarat för projektbudgetar för vattenfall) får dock ensamrätt att godkänna vilka Portfolio Epics (stora initiativ) som flyttar in i varje ström. Epics är inte förklaringar om ett problem som behöver lösas. De är förformade idéer om hur man bäst kan lösa dessa problem.
Med en gång kan vi se tecken på den gamla skolans tankesätt att se team som en ”leverans” -funktion istället för en strategisk. nivåtänkare kommer med idéer, och de som gör låga nivåer utövar dessa idéer. Ignoreras är möjligheten att de som är närmast arbetet kan vara bäst utrustade för att fatta beslut om det. Att fly från detta missriktade tänkesätt är ett kärnmål för Agile att tänka att SAFe misslyckas med att åstadkomma på distans.
En liknande fråga dyker upp igen när vi tittar på en något lägre nivå.
SAFe samlar in små produktgrupper (ofta Scrum-team) i ”Agile Release Trains ”- grupper av team med ett ytterligare lager av ledningsroller som spänner över varje grupp på vad som kallas” Programnivå ”.
Generellt hindrar dessa roller teamens autonomi. De lägger till process- och kommunikationsomkostnader utanför proportioner med det värde de tillhandahåller.
Dessa roller inkluderar en Product Manager (PM), en S ystem Architect (SA) och en Release Train Engineer (RTE).
SA och PM definierar och delar upp större arbeten (ofta ärvda från portföljprocessen ovan) och skickar sedan bitarna i Team.
Produktägaren och teamet kan teoretiskt sett kunna prioritera andra, mindre arbeten mot det arbete som ålagts dem, men dessa ansträngningar har begränsad synlighet och inköp ovanifrån. Det kommer att finnas ett naturligt tryck att behandla arbete som kommer från högsta punkt som det viktigaste – även om varje enskild teammedlem tror att andra saker skulle vara mer värdefulla. På grund av detta reduceras produktägarens roll till att skriva berättelser och kontrollera acceptanskriterier, istället för att vara den enda ansvariga för produktledarskap som var den ursprungliga avsikten med rollen.
Systemarkitekten är inte i stånd att vara nära det verkliga ingenjörsarbetet, så den arkitektoniska planen som de vidarebefordrar kan kopplas bort från verklighetens verk. Dessa typer av roller var ett kännetecken för stora design-up-front vattenfallsprojekt och är väl bevarade i SAFe.
Släpptågsingenjörer definierar konsekvent processövergripande och kadens över hela teamet och hanterar många operativa uppgifter. I slutändan lämnar detta mindre utrymme för enskilda team att modifiera, förbättra eller experimentera med sina egna metoder på något sätt som avviker från etablerade standarder.
Ibland upprepas alla dessa problem igen med tillägget av en ”Large” Lösningsnivå ”- grupper av grupper av lag med motsvarande roller som de på programnivå, men som spänner över frigörartåg. När detta inträffar kommer samma problem sannolikt att upprepas, men lösningsnivån verkar vara mindre vanligt på plats.
SAFe kommer (ofta) med Rally – LÄNGRE begränsning av teamets autonomi
SAFe är ofta ett paketavtal med projektledningsprogrammet Rally. Rally är den typ av programvara du kan förvänta dig ett företag som använder SAFe att göra – det är överbelastat med funktioner, ofokuserat, förvirrande, instabilt och därmed svårt att lära sig och använda.
Värdeförslaget att anta Rally för ledarskap är att de kommer att kunna se rapportering som ger dem en enkel, enhetlig bild av th framsteg och problem över hela företaget.
Det betyder naturligtvis att alla i företaget inte bara behöver använda Rally utan de måste använda det på ett konsekvent sätt. Återigen kan detta bara uppnås genom diktering uppifrån och ner. Rally och hur det tänker på arbete tvingas till alla team oavsett deras preferenser, sammanhang eller inköp. För att faktiskt få all information att samla in krävs otroliga omkostnader för att uppskatta och spåra som saktar ner allt och kan vara extremt störande för att faktiskt få jobb.
Dessutom är toppnivårapporteringen inte ens särskilt användbar. Det fokuserar på saker som Rally spårar – mätvärden som volymen av berättade poäng som levereras (bokstavligen består) eller den mängd buggar som adresseras (ett fruktansvärt mått för ”produktkvalitet”).Om ledningen ignorerar denna statistik, kommer den overhead de lägger till att vara för ingenting. Om de klarar mätvärdena kommer statistiken att bli fuskad så att lagen ser bra ut och lämnas ensamma. Uppskattningarna kommer att vara överdrivna, små bitar av arbete kommer att överdrivas, och detta kan lätt leda till en uppdelning av förtroende.
SAFe tar sämst möjliga sätt att hantera beroenden
A beroende är ett exempel där ett team måste vänta på att något ska göras någon annanstans innan de kan slutföra sitt eget arbete. SAFe är strukturerat kring en bakåtriktad attityd att beroende är ett oföränderligt faktum i livet som bör accepteras och hanteras runt. Det hänvisar till och med ibland till dem som en strategisk fördel. I verkligheten, när du tänker på beroenden som en dålig sak – att minimeras vid varje tillfälle – kan du upptäcka att dessa möjligheter är rikliga och att utnyttja dem i första hand leder till fördelar. Här är bara några förslag som SAFe underbetonar eller helt ignorerar:
- Uppmuntra en kultur av inre sourcing där ett team kan skicka arbete till ett annat lags kodbas utan att behöva vara beroende av dem utöver acceptera sammanslagningen
- Gör det enkelt för teammedlemmar att tillfälligt eller permanent byta lag när det är vettigt att göra det
- Fokusera på att anställa, strukturera och utbilda team för att hantera sina egna behov utan extern hjälp
Hur SAFe faktiskt väljer att hantera beroenden är genom att öka fokus på planering, process, hierarki och standardisering. Förutsägbart resulterar detta i massor av möten som stör förmågan att få arbete gjort. Det inför detta tillvägagångssätt genom en universell utrullning som påverkar hela organisationen på en gång. Ingen hänsyn tas till vilka områden som kunde ha varit självberoende utan den extra betungande strukturen.
SAFe är alltför orienterad kring planering
En kärnfunktion i SAFe är tanken på ~ 10 veckor Programsteg (PI). Du kan tänka på dessa som stora sprints som innehåller alla dina vanliga sprints.
Varje PI börjar med en PI-planeringshändelse som pågår i ungefär två dagar. PI-planering kräver också förplanering och efterplanering på programnivå.
Det finns definitivt något värde i att människor träffas personligen för att bygga relationer, dela information och orientera kring mål. Å andra sidan är det mycket mindre värdefullt att använda det begränsade tidsfönstret för att göra tio veckors planer för specifika användarberättelser baserat på fördefinierade funktioner, och sedan kräva engagemang för dessa planer.
Så snart PI-planeringen avslutas skapades dessa planer baserat på begränsad förståelse och många antaganden kommer att bli föråldrade så snart något nytt lärs. Lag kommer kontinuerligt att rivas mellan att hålla sig till den plan de har lärt sig inte är meningsfullt och att omorientera förväntningarna av skäl som de ovanför dem kanske inte har förmåga att förstå.
SAFe är inriktat på volym, inte värde
I allt detta fokus på volymmätvärden, uppskattning och churningarbete genom rörledningen går begreppet vad som faktiskt är värdefullt eller framgångsrikt förlorat. Det antas ofta att mer arbete som skickas ut genom dörren måste vara ”värde”, även om upplevelsen av produkten faktiskt lider och användarna inte drar nytta av de ytterligare funktionerna.
SAFe är medveten om kritiken som det är inte värdefokuserat och har nyligen lagt till ”designtänkande”, ”kundcentrering” och andra koncept i dokumentationen för att kompensera. Hittills är jag inte övertygad om att det gör några betydande förändringar i sin process som faktiskt ger plats för dessa saker , och det fumlar i att till och med förstå dem i första hand.
Till exempel, SAFes definition av ”kunder” lämnar dörren öppen för att definiera affärsintressenter eller de som finansierar värdeströmmarna som ”kunder”. skiljer sig väldigt mycket från att omorientera alla (inklusive de som tillhandahåller finansieringen) för att fokusera på de slutanvändares behov som faktiskt använder programvaran, ett kärnelement i designtänkande.
SAFe är onödigt komplicerat
SAFe har en naturlig fördel som skyddar det från kritik; Det är så komplicerat att det är svårt att helt förstå. Trots den extra tid jag har spenderat på ramverket är det troligt att jag troligen kommer att göra fel saker eller missa några viktiga punkter. Ett överflöd av komplexitet är dock i sig ett legitimt problem. SAFe har så många möten, kontrollpunkter, värden och metoder att det i princip är omöjligt att få alla på samma sida.
SAFe begränsar retrospektiv och kontinuerlig förbättring
Roller på programnivå och ovan kan omöjligt delta i alla lagens retrospektiv.Detta innebär att retrospektiv inte kommer att höras direkt av de människor som faktiskt kan ändra många av de saker som diskuteras.
Det sätt som SAFe försöker kompensera för detta är inte tillräckligt.
PI-planering är den enda gången där alla i ett släpptåg garanteras att vara tillsammans personligen. Tyvärr innehåller den en kort retrospektiv som bara relaterar till framgången för själva planeringshändelsen.
SAFe innehåller en ”Inspektera och anpassa” -händelse mot slutet av varje PI, men det verkar nästan utformat att hoppas över baserat om hur svårt det är att samordna för RTE. När det hålls grundas evenemanget genom att granska – naturligtvis – volymmätvärden från den sista PI. Dessutom tilldelas endast 30 minuter av evenemanget för en verklig retrospektiv där problem dyker upp och överenskommits Om den här tiden fördelas jämnt mellan alla medlemmar i ett 100-personers frigivningståg, kommer varje deltagare att få cirka 18 sekunder var ~ 10: e vecka för att ta upp frågor i ett sammanhang där de faktiskt kan höras.
SAFe har också några andra element som ”bedömningskartor” där team undersöks bredare, men dessa lutar kraftigt mot att bekräfta att SAFe-praxis följs, inte om de är effektiva eller inte.
SAFe nedbryter begreppen som den sammanställer
En nyckel en del av SAFe som jag ännu inte har berört är aggregeringen av befintliga koncept som Scrum, Kanban, Lean Product, Lean UX och DevOPs.
Om du inte känner föreslår jag att du utforskar varje koncept oberoende över tiden snarare än allt på en gång. Många är värdefulla själva, men SAFe gör inte ett bra jobb med att faktiskt syntetisera dem och kan ibland lägga till förvirring. Fall i punkt:
SAFe rekommenderar rutinmässigt hur dess metoder följer ”Lean-Agile” -principer. Tricket är att ”Lean-Agile” faktiskt inte hänvisar till ”Lean” eller ”Agile” -principer.
Istället är ”Lean-Agile Principles” en skapelse av SAFes egen design. Denna nya uppsättning ”principer” förvränger de begrepp som den assimilerar. Sidan om decentralisering av beslut (rankad som lägst av alla principer) subterar sig till exempel subtilt genom att betona vikten av att centralisera beslutsfattandet för många användningsfall. Andra listade principer har liknande problem. För en person som introduceras till all denna information på en gång kan den faktiska innebörden av de ursprungliga begreppen gå vilse.
SAFe är inte smidig
Nu är det många sätt SAFe är inkonsekvent med en Agile tänkesätt bör vara ganska tydlig. Den är planfokuserad, byråkratisk, komplicerad, innehåller många ofta onödiga processer, avaktiverar teamets autonomi och mer.
Men spelar det någon roll om SAFe är Agile eller inte när det vi verkligen bryr oss om är effektivitet ?
Ja. Det gör det.
Agila principer är bara agila principer eftersom de allmänt erkändes och överenskommits vara effektiva. Det tänkandet kom ihop med en bredare grupp av utövare, varför rörelsen ursprungligen tog fart. Om du tror att smidighet är en förutsägare för effektivitet, (en tro som troligen ligger bakom något av intresset för SAFe), så spelar det en hel del om SAFe överensstämmer med agilt tänkande. Att vilseleda människor om vad de köper är en dålig sak och det är inte fel att ropa ut det.
Hur är det med alla fallstudier där SAFe visat sig ha fungerat?
Det finns cirka 40 fallstudier om framgångsrik SAFe-antagande på scaledagileframework.com. Fallstudierna för misslyckanden är påfallande frånvarande. I motsats till förkortningen innebär SAFe samtidigt förändringar av en enorm ny process över ett enormt ekosystem – en enorm risk. Om inte vart och ett av de 40 framgångsrika företagen vardera hade 11 250 certifierade SAFe-utövare finns det en hel del företag vi inte hör ifrån.
Jag lägger inte mycket för mycket i de fallstudier som gör existera. Även om volymmätvärdena som de fokuserar på verkligen var värdefulla är det lätt att välja några statistik som gör att det verkar som att det gick bra.
För att fokusera på ett specifikt exempel, låt oss ta en titt på ett utdrag från fallstudien om SAFe-implementering på Fitbit:
2016 släppte konsumentteknikföretaget Fitbit fyra nya produkter till marknaden som mottogs positivt av konsumenter och skickade över 22 miljoner enheter. Att leverera sitt högsta antal produkter på ett år beror delvis på företagets engagemang för och framgång med att anta SAFe® (Scaled Agile Framework®) som ett sätt att skala teamet för att uppfylla måldatum.
© Scaled Agile, Inc.
Här är Fitbits aktiekurs under de senaste fem åren:
Ja … 2016 ser ut som ett bra år för Fitbit.
Nu kan vi inte riktigt tillskriva Fitbits fall till SAFe antagande med den mängd information vi har.Men om ett företag kan kämpa så mycket och ändå hyra SAFe-antagandet för att förbättra responsen hos sina produktbeslut, kommer jag att begränsa ögonen några grader mer när jag tittar på resten av fallstudierna.
Det är dock OK som ett övergångssteg, eller hur?
Om du är någon som skulle göra detta argument måste du tänka att SAFe måste överföras bort från. På den här punkten är vi överens!
För att göra den övergången måste vi naturligtvis spendera lite tid på att peka på de delar som inte fungerar bra.
Är det något du har har spenderat mycket tid på?
Även om du är det är SAFe inställt på ett sätt som hindrar dig från att faktiskt gå över. Den auktoritet som den lägger i ledningens händer fungerar som en legitimering av top-down-kontrollmentaliteten. Detta passar dåligt med de bristande metoder för processförbättring som vi redan har täckt. Behörigheten att ”anpassa” SAFe till lämpligt sammanhang är mestadels otillgänglig för de faktiska team som är bäst positionerade för att känna igen vad som inte fungerar.
Ingenstans i SAFe-färdplanen hänvisar det faktiskt till något av dess kärnpraxis som övergång. Om det är en övergångsram gör den ett ganska dåligt jobb med att tillhandahålla någon form av övergångsplan.
Hyperfokus på certifieringar skadar också ramens flexibilitet . Om du spenderar timmar och timmar på att bli certifierad blir certifieringen en del av ditt eget värde. En övergång till något som ser mindre ut som SAFe kan verka som att det hotar det värdet. Jag kan inte skylla på någon för att bli certifierad i en arbetsmarknaden där certifieringar betyder något. Men dessa individer har ett särskilt ansvar att vara uppmärksam på nackdelarna med SAFe och möjliga sätt att förbättra eller avvika från det.
Dessa problem upplevs i stort
Jag är inte ensam om uttrycka många av denna kritik – även om jag hoppas att jag har gått lite längre för att ansluta dem till de specifika metoderna inom ramen. Om du letar efter bekräftande vittnesmål, här är några:
Ken Schwaber, medutvecklare av Scrum, uttryckte allvarliga bekymmer över SAFe redan 2013.
Nicholas M. Chaillan , US Air Force Chief Software Officer, avskräcker ”att använda styva, föreskrivande ramar som Scaled Agile Framework (SAFe).”
Forbes-bidragsgivare Steve Denning uppmanar SAFe för att vara ”särskilt oroande” i sin artikel om hur man upptäcker falsk Agile.
Marty Cagan från Silicon Valley Product Group förklarar hur SAFe är antitetiskt mot Silicon Valley-företagens tankesätt.
Håll dig säker där ute (inte SAFe)
Medan SAFe verkligen har fått en hel del kritik , min personliga känsla är att denna kritik kanske inte har nått en stor publik utöver vissa onlinecirklar. Detta är särskilt troligt när man överväger det tillsammans med det ökande antalet företag som antar ramverket varje dag.
För många människor kan tanken att det är något fel med SAFe – eller att det överensstämmer med Agile principer – vara helt ny.
Ökad diskussion riktad till en bredare publik kan förmodligen hjälpa. Jag hoppas kunna beröra det här ämnet mer i framtiden och att ta reda på vilka andra alternativ som finns.
För närvarande, även om du inte arbetar i en SAFe-miljö, är det ingen ursäkt för att bli självbelåten . De farhågor som jag har lagt fram här bör ses som en bredare varning – även de mest förnuftiga idéerna kan lätt samordnas, korrumperas och förväxlas om du inte ägnar stor uppmärksamhet.