Beware SAFe (the Scaled Agile Framework for Enterprise), an Unholy Incarnation of Darkness

… eller kanskje ikke.

Hvis du helst vil SAFe snakke for seg selv, kan du bruke lenken over. Det er hundrevis av sider med dokumentasjon, timer med videoer, 15 forskjellige kurs og mer. Hvis det høres ut som litt mye, vil jeg gjøre mitt beste for å gi en forklaring på hvordan SAFe fungerer når jeg går gjennom hvert punkt.

På det høyeste nivået, kalt «Portfolio», tar SAFe til orde for finansiering på ubestemt «Value Streams» – som vanligvis representerer et produkt, en produktlinje eller en kundetype. Lean Portfolio Management-funksjonen (LPM) som kontrollerer finansiering (sannsynligvis de samme personene som tidligere var ansvarlige for prosjektbudsjetter med fossefall), får imidlertid den eneste fullmakten til å godkjenne hvilke Portfolio Epics (store initiativer) som flytter inn i hver strøm. Epics er ikke forklaringer på et problem som må løses. De er forhåndsformede ideer om hvordan vi best kan løse disse problemene.

Med en gang kan vi se tegn på den gamle skolens tankesett om å se på team som en «leverings» -funksjon i stedet for en strategisk. nivå tenkere kommer med ideer, og lavnivå gjørere utfører disse ideene. Ignorert er muligheten for at de nærmeste arbeidet kan være best rustet til å ta avgjørelser om det. Å unnslippe fra denne villfarne tankegangen er et kjernemål for Agile å tenke at SAFe klarer ikke å oppnå eksternt.

Et lignende problem dukker opp igjen når vi ser på et litt lavere nivå.

SAFe samler små produktteam (ofte Scrum-team) til «Agile Release Trains» «- grupper av team med et ekstra lag med lederroller som spenner over hver gruppe på det som kalles» Programnivå «.

Generelt hindrer disse rollene autonomien til teamene. De legger til prosess- og kommunikasjonsomkostninger utenfor proporsjoner med verdien de gir.

Disse rollene inkluderer en Product Manager (PM), en S ystem Architect (SA), og en Release Train Engineer (RTE).

SA og PM definerer og deler opp større deler av arbeidet (ofte arvet fra porteføljeprosessen ovenfor) og deretter bringer delene inn i team.

Produkteier og team kan kanskje teoretisk være i stand til å prioritere andre, mindre arbeidsstykker mot arbeidet som pålegges dem, men denne innsatsen har begrenset synlighet og buy-in ovenfra. Det vil være et naturlig press for å behandle arbeid som kommer fra det høyeste punktet som viktigst – selv om hvert enkelt teammedlem mener andre ting ville være mer verdifulle. På grunn av dette reduseres Produkteierens rolle til å skrive historier og kontrollere akseptkriterier, i stedet for å være det eneste ansvarlige punktet for produktledelse som var den opprinnelige intensjonen for rollen.

Systemarkitekten er ikke i posisjon til å være nær det faktiske ingeniørarbeidet, så den arkitektoniske planen de videreformidler kan være koblet fra virkeligheten i arbeidet. Denne typen roller var et kjennetegn ved store design-up-front fossefallprosjekter og er godt bevart i SAFe.

Release Train Engineers definerer konsistent teamprosess og tråkkfrekvens, og håndterer mange operative oppgaver. Til syvende og sist gir dette mindre rom for individuelle team å modifisere, forbedre eller eksperimentere med sin egen praksis på noen måte som avviker fra etablerte standarder.

Noen ganger gjentas alle disse problemene igjen med tillegg av en «Stor Løsningsnivå «- grupper av grupper av lag med analoge roller som de på programnivå, men som spenner over frigjøringstog. Når dette skjer, vil sannsynligvis de samme problemene gjentas, men løsningsnivået ser ut til å være mindre vanlig på plass.

SAFe kommer ofte med Rally – Ytterligere begrenser teamets autonomi

SAFe er ofte en pakkeavtale med prosjektledelsesprogramvaren Rally. Rally er den slags programvare du forventer et selskap som bruker SAFe å lage – det er overbelastet med funksjoner, ufokusert, forvirrende, ustabilt og følgelig vanskelig å lære og bruke.

Verdiforslaget om å vedta Rally for ledelse er at de vil kunne se rapportering som gir dem et enkelt, samlet bilde av th fremdrift og problemer på tvers av hele bedriften.

Dette betyr selvfølgelig at alle i bedriften ikke bare trenger å bruke Rally, men de må bruke det på en jevn måte. Igjen, dette kan bare oppnås gjennom diktering ovenfra og ned. Rally og måten den tenker på arbeid blir tvunget til alle team uavhengig av preferanse, kontekst eller buy-in. Å faktisk ha all informasjonen samlet, krever utrolige overhead i estimering og sporing som bremser alt og kan være ekstremt forstyrrende for å faktisk få arbeidet gjort.

I tillegg er toppnivårapportering ikke engang spesielt nyttig. Den fokuserer på tingene Rally sporer – beregninger som volumet av historikkpoeng levert (bokstavelig talt sammensatt) eller mengden feil adressert (et forferdelig mål for «produktkvalitet»).Hvis ledelsen ignorerer denne statistikken, vil overhead de legger til være for ingenting. Hvis de klarer seg til beregningene, blir statistikken fudged slik at lagene ser bra ut og blir alene. Anslagene vil være overpolstret, små arbeidsstykker vil bli overdrevet, og dette kan lett føre til en sammenbrudd av tillit.

SAFe tar den verste mulige tilnærmingen til å håndtere avhengigheter

A avhengighet er et tilfelle der et team må vente på at noe skal gjøres andre steder før de kan fullføre sitt eget arbeid. SAFe er strukturert rundt en tilbakestående holdning om at avhengigheter er et uforanderlig faktum i livet som skal aksepteres og styres rundt. Det refererer til og med til dem som en strategisk fordel. I virkeligheten, når du tenker på avhengigheter som en dårlig ting – for å bli minimert ved enhver anledning – kan du oppleve at disse mulighetene er rikelig, og at å utnytte dem først og fremst resulterer i fordeler. Her er bare noen få forslag som SAFe understreker eller ignorerer helt:

1. Oppmuntre til en kultur for indre innkjøp hvor ett team kan sende inn arbeid til et annet teams kodebase uten å måtte stole på dem utover godta sammenslåingen
2. Gjør det enkelt for teammedlemmer å bytte lag midlertidig eller permanent når det er fornuftig å gjøre det
3. Fokus på å ansette, strukturere og trene team for å håndtere sine egne behov uten hjelp utenforfra

Hvordan SAFe faktisk velger å håndtere avhengigheter er ved å øke fokuset på planlegging, prosess, hierarki og standardisering. Forutsigbart resulterer dette i mange møter som forstyrrer evnen til å få arbeidet gjort. Det pålegger denne tilnærmingen gjennom en universell utrulling som påvirker hele organisasjonen på en gang. Det vurderes ikke hvilke områder som kunne ha vært selvstendige uten den ekstra belastende strukturen.

SAFe er altfor orientert rundt planlegging

Et kjernetrekk ved SAFe er ideen om ~ 10 uker Programøkninger (PIer). Du kan tenke på disse slags store sprints som inneholder alle dine vanlige sprints.

Hver PI begynner med en PI-planleggingshendelse som varer i omtrent to dager. PI-planlegging krever også forhåndsplanlegging og etterplanleggingsaktiviteter på programnivå.

Det er definitivt en viss verdi å ha folk personlig sammen for å bygge relasjoner, dele informasjon og orientere seg rundt mål. På den annen side er det mye mindre verdifullt å bruke det begrensede tidsvinduet til å lage ti ukers planer for spesifikke brukerhistorier basert på forhåndsdefinerte funksjoner, og deretter kreve forpliktelse til disse planene.

Så snart PI-planleggingen avsluttes, ble disse planene opprettet basert på begrenset forståelse og mange antagelser vil bli foreldet så snart noe nytt blir lært. Teamene vil kontinuerlig bli revet mellom å holde seg til planen de har lært ikke gir mening, og å omorientere forventningene av grunner til at de over dem kanskje ikke er i stand til å forstå.

SAFe er orientert rundt volum, ikke verdi

I alt dette fokuset på volummålinger, estimering og karringarbeid gjennom rørledningen, går konseptet med det som faktisk er verdifullt eller vellykket, tapt. Det antas ofte at mer arbeid som sendes ut døren må være «verdi», selv om opplevelsen av produktet faktisk lider og brukerne ikke drar nytte av tilleggsfunksjonene.

SAFe er klar over kritikken som det er ikke verdifokusert og har nylig lagt til «designtenking», «kundesentrisitet» og andre konsepter i dokumentasjonen for å kompensere. Så langt er jeg ikke overbevist om at det gjør noen vesentlige endringer i prosessen som faktisk gir rom for disse tingene. , og det fomler med å til og med forstå dem i utgangspunktet.

For eksempel gir SAFes definisjon av «kunder» døren åpen for å definere forretningsinteressenter eller de som finansierer verdistrømmene som «kunder». er veldig forskjellig fra å omorganisere alle (inkludert de som yter finansiering) for å fokusere på behovene til sluttbrukerne som faktisk bruker programvaren, et sentralt element i designtenking.

SAFe er unødvendig kompleks

SAFe har en naturlig fordel som beskytter det fra kritikk; Det er så komplisert at det er vanskelig å forstå det. Til tross for den ekstra tiden jeg har brukt på å undersøke rammeverket, er det sannsynlig at jeg sannsynligvis vil få noen ting galt eller savne noen viktige punkter. Imidlertid er en overflod av kompleksitet i seg selv en legitim bekymring. SAFe har så mange møter, sjekkpunkter, verdier og metoder at det i utgangspunktet er umulig å få alle på samme side.

SAFe begrenser retrospektiv og kontinuerlig forbedring

Roller på programnivå og ovenfor kan umulig delta i alle lagets tilbakeblikk.Dette betyr at tilbakeblikk ikke vil bli hørt direkte av folket som faktisk kan endre mange av de tingene som blir diskutert.

Måten SAFe prøver å kompensere for dette er ikke tilstrekkelig.

PI planlegging er den eneste gangen der alle i et frigjøringstog garantert er sammen personlig. Dessverre inneholder den en kort retrospektiv som bare er relatert til suksessen til selve planleggingshendelsen.

SAFe inkluderer en «Inspect and Adapt» -hendelse mot slutten av hver PI, men den virker nesten designet for å bli hoppet over på hvor vanskelig det er å koordinere for RTE. Når det avholdes, blir arrangementet startet ved å gjennomgå – selvfølgelig – volummålinger fra den siste PI. I tillegg tildeles bare 30 minutter av arrangementet for en faktisk retrospektiv der problemer blir dukket opp og avtalt Hvis denne tiden er fordelt jevnt mellom alle medlemmene i et 100-personers frigjøringstog, vil hver deltaker få omtrent 18 sekunder hver ~ 10. p> SAFe har også noen andre elementer som «vurderingskart» der team blir undersøkt bredere, men disse lener seg sterkt mot å bekrefte at SAFe-praksis følges, ikke om de er effektive eller ikke.

SAFe nedbryter konseptene det samler

En nøkkel en del av SAFe som jeg ennå ikke har berørt, er aggregeringen av eksisterende konsepter som Scrum, Kanban, Lean Product, Lean UX og DevOPs.

Hvis du ikke er kjent, vil jeg foreslå å utforske hvert konsept uavhengig over tid i stedet for på en gang. Mange er verdifulle selv, men SAFe gjør ikke en god jobb med å faktisk syntetisere dem og kan noen ganger legge til forvirring. Eksempel:

SAFe tilslutter seg rutinemessig hvordan dets praksis følger «Lean-Agile» -prinsippene. Trikset er at «Lean-Agile» faktisk ikke refererer til «Lean» eller «Agile» -prinsippene.

I stedet er «Lean-Agile Principles» en skapelse av SAFes eget design. Dette nye settet med «prinsipper» forvrenger konseptene det assimilerer. For eksempel subterer siden om desentralisering av beslutninger (rangert som lavest av alle prinsipper) subtilt ved å understreke viktigheten av å sentralisere beslutningstaking for mange brukssaker. Andre oppførte prinsipper har lignende problemer. For en person som blir introdusert for all denne informasjonen på en gang, kan den faktiske betydningen av de opprinnelige konseptene gå tapt.

SAFe er ikke smidig

Nå er mange av måtene SAFe er inkonsekvent med et smidig tankesett, bør være ganske klart. Det er planfokusert, byråkratisk, komplisert, inneholder mange ofte unødvendige prosesser, avmakt teamets autonomi og mer.

Men spiller det noen rolle om SAFe er smidig eller ikke når det vi virkelig bryr oss om er effektivitet ?

Ja. Det gjør det.

Agile prinsipper er bare Agile prinsipper fordi de generelt ble anerkjent og enige om å være effektive. Den tenkningen resonerte med et bredere samfunn av utøvere, og derfor startet bevegelsen opprinnelig. Hvis du tror at smidighet er en prediktor for effektivitet, (en tro antagelig bak noe av interessen for SAFe), så betyr det ganske mye om SAFe er i samsvar med smidig tenkning. Å villede folk om hva de kjøper er en dårlig ting, og det er ikke galt å ringe det ut.

Hva med alle casestudiene der det vises at SAFe har fungert?

Det er omtrent 40 casestudier om vellykket SAFe-adopsjon på scaledagileframework.com. Casestudiene for feil er påfallende fraværende. I motsetning til akronymet innebærer SAFe samtidige endringer i en enorm ny prosess på tvers av et enormt økosystem – en enorm risiko. Med mindre hver av de 40 vellykkede selskapene hver hadde 11 250 sertifiserte SAFe-utøvere, er det ganske mange selskaper vi ikke hører fra.

Også, jeg legger ikke mye for mye i casestudiene som gjør det eksistere. Selv om volumberegningene de fokuserer på virkelig var verdifulle, er det enkelt å velge noen få statistikker som gjør at det virker som om det gikk bra.

For å fokusere på et spesifikt eksempel, la oss ta en titt på et utdrag fra casestudien om SAFe-implementering på Fitbit:

I 2016 ga forbrukerteknologiselskapet Fitbit ut fire nye produkter til markedet som ble positivt mottatt av forbrukere, og sendte over 22 millioner enheter. Å levere sitt høyeste antall produkter på ett år skyldes delvis selskapets engasjement for og suksess med å ta i bruk SAFe® (Scaled Agile Framework®) som en måte å skalere teamet for å oppfylle måldatoer.

© Scaled Agile, Inc.

Her er Fitbits aksjekurs de siste fem årene:

Ja … 2016 ser ut som et flott år for Fitbit.

Nå kan vi ikke tilskrive fallet av Fitbit til SAFe adopsjon med mengden informasjon vi har.Men hvis et selskap kan slite så mye og fremdeles hylle SAFe-adopsjonen som å forbedre responsen til produktavgjørelsene, kommer jeg til å begrense øynene noen få grader mer når jeg sjekker ut resten av casestudiene.

Det er OK som et overgangstrinn, ikke sant?

Hvis du er noen som vil komme med dette argumentet, må du tenke at SAFe må overføres bort fra. På dette punktet er vi enige!

For å gjøre denne overgangen må vi selvfølgelig bruke litt tid på å peke på delene som ikke fungerer bra.

Er det noe du har brukt mye tid på?

Selv om du er det, er SAFe satt opp på en måte som hindrer deg i å faktisk gå over. Den autoriteten den legger i ledelsens hender fungerer som en legitimering av kontroll-mentaliteten ovenfra og ned. Dette passer dårlig sammen med de manglende metodene for prosessforbedring vi allerede har dekket. Myndigheten til å «tilpasse» SAFe til riktig kontekst er stort sett utilgjengelig for de faktiske teamene som er best posisjonert for å gjenkjenne hva som ikke fungerer.

Ingen steder i SAFe-veikartet refererer det faktisk til noe av dets kjerneutøvelser som overgangsregler. Hvis det er en overgangsramme, gjør den en ganske dårlig jobb med å tilby noen form for overgangsplan.

Hyperfokus på sertifiseringer skader også rammeverket . Hvis du bruker timer og timer på å bli sertifisert, blir sertifiseringen en del av din egen verdi. En overgang til noe som ser mindre ut som SAFe kan virke som om det truer den verdien. Jeg kan ikke klandre noen for å bli sertifisert i en jobbmarked der sertifiseringer betyr noe. Men disse personene har et spesielt ansvar for å ta hensyn til ulempene ved SAFe og mulige måter å forbedre eller avvike fra det.

Disse problemene oppleves bredt

Jeg er ikke alene om uttrykke mange av denne kritikken – selv om jeg håper jeg har gått litt lenger i å koble dem til den spesifikke praksis i rammen. Hvis du leter etter bekreftende vitnesbyrd, er det noen få:

Ken Schwaber, medutvikler av Scrum, uttrykte alvorlige bekymringer for SAFe allerede i 2013.

Nicholas M. Chaillan , US Air Force Chief Software Officer, fraråder «å bruke stive, reseptbelagte rammer som Scaled Agile Framework (SAFe).»

Forbes-bidragsyter Steve Denning kaller SAFe for å være «spesielt bekymringsfull» i sin artikkel om hvordan å få øye på falske smidige.

Marty Cagan fra Silicon Valley Product Group forklarer hvordan SAFe er antitetisk mot tankesettene til Silicon Valley-selskaper.

Hold deg trygg der ute (ikke SAFe)

Mens SAFe absolutt har fått mye kritikk , min personlige sans er at denne kritikken kanskje ikke har nådd et stort publikum utover visse nettkretser. Dette er spesielt sannsynlig når det vurderes sammen med det økende antall selskaper som vedtar rammeverket hver dag.

For mange mennesker kan ideen om at det er noe galt med SAFe – eller at det i strid med Agile-prinsippene – være helt ny.

Økt diskusjon rettet mot et bredere publikum kan trolig hjelpe. Jeg håper å berøre dette emnet mer i fremtiden og å detaljere hvilke andre alternativer som er der ute.

Foreløpig, selv om du ikke jobber i et SAFe-miljø, er det ikke en unnskyldning for å bli selvtilfreds. . Bekymringene jeg har lagt fram her, bør tas som en bredere advarsel. Selv de mest fornuftige ideene kan lett bli valgt, ødelagt og forvirret hvis du ikke følger nøye med.