Pas på SAFe (The Scaled Agile Framework for Enterprise), en uhellig inkarnation af mørke

… eller måske ikke.

Hvis du hellere vil SAFe tale for sig selv, kan du bruge linket ovenfor. Der er hundredvis af sider med dokumentation, timer med videoer, 15 forskellige kurser og mere. Hvis det lyder lidt meget, vil jeg gøre mit bedste for at give en forklaring på, hvordan SAFe fungerer, når jeg går gennem hvert punkt.

På det højeste niveau, kaldet “Portfolio”, går SAFe ind for finansiering på ubestemt tid “Value Streams” – som normalt repræsenterer et produkt, en produktlinje eller en kundetype. Lean Portfolio Management-funktionen (LPM), der kontrollerer finansiering (sandsynligvis de samme personer, der tidligere var ansvarlige for projektfald i vandfaldstil), får dog enekompetence til at godkende, hvilke Portfolio Epics (store initiativer), der flytter ind i hver strøm. Epics er ikke forklaringer på et problem, der skal løses. De er foruddannede ideer om, hvordan man bedst kan løse disse problemer.

Vi kan med det samme se tegn på old school-tankegangen om at se hold som en “leverings” -funktion i stedet for en strategisk. niveau tænkere kommer med ideer, og lavt niveau gørere udfører disse ideer. Ignoreret er muligheden for, at de tætteste på arbejdet måske er bedst rustet til at træffe beslutninger om det. At flygte fra denne vildledte tankegang er et kernemål for Agile tænkning om, at SAFe opnår ikke fjernadgang.

Et lignende problem dukker op igen, når vi ser på et lidt lavere niveau.

SAFe samler små produktteams (ofte Scrum-teams) til “Agile Release Trains” ”- grupper af hold med et ekstra lag af ledelsesroller, der spænder over hver gruppe på det, der kaldes” Programniveau “.

Generelt hindrer disse roller teamets autonomi. De tilføjer proces- og kommunikationsomkostninger ude af proportion med den værdi, de giver.

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

SA og PM definerer og opdeler større stykker arbejde (ofte arvet fra porteføljeprocessen ovenfor) og sender stykkerne derefter ind i teams.

Produktejeren og teamet kan muligvis teoretisk være i stand til at prioritere andre mindre stykker arbejde mod det arbejde, der pålægges dem, men disse bestræbelser har begrænset synlighed og buy-in ovenfra. Der vil være et naturligt pres for at behandle arbejde, der kommer fra det højeste punkt, som det vigtigste – selvom hvert enkelt teammedlem mener, at andre ting ville være mere værdifulde. På grund af dette reduceres Produktionsejerens rolle til at skrive historier og kontrollere acceptkriterier i stedet for at være det eneste ansvarlige produktlederskab, der var den oprindelige hensigt med rollen.

Systemarkitekten er ikke i stand til at være tæt på det egentlige ingeniørarbejde, så den arkitektoniske plan, de viderebringer, kan være frakoblet arbejdets virkelighed. Disse slags roller var et kendetegn for store design-up-front vandfaldsprojekter og er godt bevarede i SAFe.

Release Train Engineers definerer konsekvent tværprocesproces og kadence og håndterer mange operationelle opgaver. I sidste ende giver dette mindre plads for de enkelte hold til at ændre, forbedre eller eksperimentere med deres egen praksis på enhver måde, der afviger fra etablerede standarder.

Nogle gange gentages alle disse problemer igen med tilføjelsen af en “Stor” Løsningsniveau ”- grupper af grupper af hold med analoge roller som dem på programniveau, men som spænder over frigivelsestog. Når dette sker, vil de samme problemer sandsynligvis gentages, men løsningsniveauet ser ud til at være mindre almindeligt på plads.

SAFe (ofte) leveres sammen med Rally – YDERLIGERE begrænsning af holdets autonomi

SAFe er ofte en pakkeaftale med projektstyringssoftwaren Rally. Rally er den slags software, du forventer et firma, der bruger SAFe til at lave – det er overbelastet med funktioner, ufokuseret, forvirrende, ustabilt og følgelig vanskeligt at lære og bruge.

Værdiforslaget ved at vedtage Rally for lederskab er, at de vil være i stand til at se rapportering, der giver dem et simpelt, samlet billede af th Fremskridt og problemer på tværs af hele virksomheden.

Dette betyder selvfølgelig, at alle i virksomheden ikke kun skal bruge Rally, men de skal bruge det på en ensartet måde. Igen kan dette kun opnås gennem top-down-diktering. Rally og den måde, det tænker på arbejde på, tvinges til alle hold uanset deres præference, kontekst eller buy-in. At faktisk have alle oplysningerne samlet, kræver en utrolig overhead i estimering og sporing, der bremser alt og kan være ekstremt forstyrrende for faktisk at få arbejdet gjort.

Derudover er rapporteringen på øverste niveau ikke engang særlig nyttig. Det fokuserer på de ting, som Rally sporer – målinger som mængden af leverede historikpoint (bogstaveligt talt sammensat) eller mængden af adresserede bugs (et forfærdeligt mål for “produktkvalitet”).Hvis ledelsen ignorerer disse statistikker, vil de faste omkostninger, de tilføjer, være for ingenting. Hvis de klarer sig til målingerne, bliver statistikken fudged, så holdene ser godt ud og er alene. Skøn vil være overpolstret, små stykker arbejde vil blive overdrevet, og dette kan let føre til en sammenbrud af tillid.

SAFe tager den værst mulige tilgang til styring af afhængigheder

A afhængighed er et tilfælde, hvor et hold skal vente på, at der gøres noget andetsteds, før de kan færdiggøre deres eget arbejde. SAFe er struktureret omkring en tilbagestående holdning om, at afhængigheder er en uforanderlig kendsgerning i livet, der skal accepteres og styres omkring. Det henviser endda undertiden til dem som en strategisk fordel. I virkeligheden, når du tænker på afhængigheder som en dårlig ting – for at blive minimeret ved enhver lejlighed – kan du opleve, at disse muligheder er rigelige, og at udnyttelse af dem resulterer primært i fordele. Her er blot nogle få forslag, som SAFe understreger eller ignorerer fuldstændigt:

1. Tilskynd til en kultur inden for sourcing, hvor et hold kan indsende arbejde til et andet teams kodebase uden at skulle afhænge af dem ud over acceptere fusionen
2. Gør det let for teammedlemmer at midlertidigt eller permanent bytte hold, når det er fornuftigt at gøre det
3. Fokus på ansættelse, strukturering og træning af teams til at håndtere deres egne behov uden hjælp udefra

Hvordan SAFe faktisk vælger at styre afhængigheder er ved at øge fokus på planlægning, proces, hierarki og standardisering. Forudsigeligt resulterer dette i mange møder, der forstyrrer evnen til at få arbejdet gjort. Det pålægger denne tilgang gennem en universel udrulning, der påvirker hele organisationen på én gang. Der overvejes ikke, hvilke områder der kunne have været selvforsynende uden den ekstra belastende struktur.

SAFe er alt for orienteret omkring planlægning

Et kerneelement i SAFe er ideen om ~ 10 uger Programforøgelser (PIer). Du kan tænke på denne slags som store sprints, der indeholder alle dine normale sprints.

Hver PI begynder med en PI-planlægningshændelse, der løber i cirka to dage. PI-planlægning kræver også forudplanlægning og efterplanlægning på programniveau.

Der er bestemt en vis værdi i at have folk til at mødes personligt for at opbygge relationer, dele information og orientere sig om mål. På den anden side er det meget mindre værd at bruge det begrænsede tidsvindue til at lave 10 ugers planer for specifikke brugerhistorier baseret på foruddefinerede funktioner og derefter kræve engagement i disse planer.

Så snart PI-planlægning slutter, oprettes disse planer baseret på begrænset forståelse og mange antagelser bliver forældede, så snart noget nyt læres. Holdene vil løbende blive revet mellem at holde sig til den plan, de har lært, ikke giver mening, og at omlægge forventningerne af grunde til, at de over dem måske ikke er i stand til at forstå.

SAFe er orienteret omkring volumen, ikke værdi

I alt dette fokus på volumenmålinger, estimering og churning arbejde gennem pipelinen, går begrebet hvad der faktisk er værdifuldt eller vellykket let tabt. Det antages ofte, at mere arbejde, der sendes ud af døren, skal være “værdi”, selvom oplevelsen af produktet faktisk lider, og brugerne ikke drager fordel af de ekstra funktioner.

SAFe er opmærksom på den kritik, som det er ikke værdifokuseret og har for nylig tilføjet “design-tænkning”, “kundecentrering” og andre koncepter til dokumentationen for at kompensere. Indtil videre er jeg ikke overbevist om, at det foretager væsentlige ændringer i sin proces, der rent faktisk giver plads til disse ting , og det fumler med at forstå dem i første omgang.

F.eks. giver SAFes definition af “kunder” døren åben for at definere forretningsinteressenter eller dem, der finansierer værdistrømmene som “kunder”. adskiller sig meget fra at omdirigere alle (inklusive dem, der yder finansieringen) for at fokusere på de slutbrugers behov, der faktisk bruger softwaren, et kerneelement i designtænkning.

SAFe er unødvendigt kompleks

SAFe har en naturlig fordel, der beskytter det fra kritik; Det er så kompliceret, at det er svært at forstå det fuldt ud. På trods af den ekstra tid, jeg har brugt på at undersøge rammen, er jeg sandsynligvis stadig sandsynligt at få nogle ting forkert eller gå glip af nogle vigtige punkter. Imidlertid er en overflod af kompleksitet i sig selv en legitim bekymring. SAFe har så mange møder, kontrolpunkter, værdier og metoder, at det grundlæggende er umuligt at få alle på samme side.

SAFe begrænser retrospektiver og kontinuerlig forbedring

Roller på programniveau og ovenfor kan umuligt deltage i alle holdets retrospektiver.Dette betyder, at retrospektiver ikke direkte vil blive hørt af de mennesker, der rent faktisk kan ændre mange af de ting, der diskuteres.

Den måde, SAFe forsøger at kompensere for dette, er ikke tilstrækkelig.

PI-planlægning er den eneste gang, hvor alle i et frigivelsestog garanteret er sammen personligt. Desværre indeholder den en kort retrospektiv, der kun vedrører succesen med selve planlægningsbegivenheden.

SAFe inkluderer en “Inspect and Adapt” -begivenhed mod slutningen af hver PI, men det synes næsten designet til at blive sprunget over om hvor svært det er at koordinere til RTE. Når det afholdes, startes begivenheden ved at gennemgå – selvfølgelig – volumenmålinger fra den sidste PI. Derudover tildeles kun 30 minutter af begivenheden til en egentlig retrospektiv, hvor problemer dukker op og aftalt Hvis denne tid fordeles jævnt mellem alle medlemmerne af et frigivelsestog på 100 personer, får hver deltager ca. 18 sekunder hver ~ ti uger til at bringe spørgsmål ud i en sammenhæng, hvor de faktisk kan blive hørt.

SAFe har også nogle andre elementer som “vurderingskort”, hvor hold undersøges bredere, men disse læner sig stærkt mod at bekræfte, at SAFe-praksis følges, ikke om de er effektive eller ej.

SAFe nedbryder de begreber, det aggregerer

En nøgle en del af SAFe, som jeg endnu ikke har rørt ved, er sammenlægningen af eksisterende koncepter som Scrum, Kanban, Lean Product, Lean UX og DevOPs.

Hvis du ikke er bekendt, vil jeg foreslå at udforske hvert koncept uafhængigt over tid snarere end alt på én gang. Mange er værdifulde selv, men SAFe gør ikke et godt stykke arbejde med faktisk at syntetisere dem og kan undertiden tilføje forvirring. Eksempel:

SAFe tilslutter sig rutinemæssigt, hvordan dets praksis følger “Lean-Agile” -principperne. Tricket er, at “Lean-Agile” faktisk ikke henviser til “Lean” eller “Agile” -principper.

I stedet er “Lean-Agile Principles” en skabelse af SAFes eget design. Dette nye sæt “principper” fordrejer de begreber, det assimilerer. For eksempel subterer siden om decentralisering af beslutninger (rangeret som det laveste af alle principper) subtilt ved at understrege vigtigheden af at centralisere beslutningstagningen for mange brugssager. Andre nævnte principper har lignende problemer. For en person, der bliver introduceret til al denne information på én gang, kan den faktiske betydning af de originale begreber gå tabt.

SAFe er ikke smidig

På nuværende tidspunkt er mange af de måder, SAFe er inkonsekvent med en agil tankegang skal være ret klar. Det er planfokuseret, bureaukratisk, kompliceret, inkluderer en masse ofte unødvendige processer, gør det uafhængigt af teamets autonomi og meget mere.

Men betyder det noget, om SAFe er Agile eller ej, når det, vi virkelig holder af, er effektivitet ?

Ja. Det gør det.

Agile principper er kun Agile principper, fordi de generelt blev anerkendt og aftalt som effektive. Den tankegang genklang med et bredere samfund af udøvere, hvorfor bevægelsen oprindeligt tog fart. Hvis du mener, at smidighed er en forudsigelse for effektivitet (en tro antageligt bag noget af interessen for SAFe), betyder det meget, hvis SAFe er i overensstemmelse med Agile tænkning. At vildlede folk om, hvad de køber, er en dårlig ting, og det er ikke forkert at kalde det ud.

Hvad med alle de casestudier, hvor SAFe viser sig at have fungeret?

Der er omkring 40 casestudier om vellykket SAFe-adoption på scaledagileframework.com. Casestudierne for fiaskoer er iøjnefaldende fraværende. I modsætning til akronymet involverer SAFe samtidige ændringer i en enorm ny proces på tværs af et enormt økosystem – en massiv risiko. Medmindre hver af de 40 succesrige virksomheder hver havde 11.250 certificerede SAFe-udøvere, er der en hel del virksomheder, som vi ikke hører fra.

Jeg lægger heller ikke meget for meget i de casestudier, der gør eksisterer. Selvom de volumenmålinger, de fokuserer på, virkelig var værdifulde, er det let at kirsebærplukke et par statistikker, der får det til at virke som om tingene gik godt.

For at fokusere på et specifikt eksempel, lad os se på et uddrag fra casestudiet om SAFe-implementering på Fitbit:

I 2016 frigav forbrugerteknologivirksomheden Fitbit fire nye produkter til markedet, som blev modtaget positivt af forbrugere og afsendt over 22 millioner enheder. At levere sit højeste antal produkter på et år skyldes til dels virksomhedens engagement i og succes med at vedtage SAFe® (Scaled Agile Framework®) som en måde at skalere holdet til at opfylde måldatoer.

© Scaled Agile, Inc.

Her er Fitbits aktiekurs de sidste fem år:

Ja… 2016 ser ud som et godt år for Fitbit.

Nu kan vi ikke rigtig tilskrive Fitbits fald til SAFe vedtagelse med den mængde information, vi har.Men hvis en virksomhed kan kæmpe så meget og stadig hylde SAFe-vedtagelse som forbedret lydhørhed over deres produktbeslutninger, vil jeg indsnævre øjnene et par grader mere, når jeg tjekker resten af casestudierne.

Det er dog OK som et overgangsskridt, ikke?

Hvis du er nogen, der vil argumentere, skal du tænke, at SAFe skal overføres væk fra. På dette punkt er vi enige!

For at gennemføre denne overgang bliver vi selvfølgelig nødt til at bruge lidt tid på at pege på de dele, der ikke fungerer godt.

Er det noget, du har har brugt meget tid på?

Selvom du er, er SAFe indstillet på en måde, der forhindrer dig i at overgå. Den autoritet, den placerer i ledelsens hænder, fungerer som en legitimering af top-down-kontrolmentaliteten. Dette parrer dårligt med de manglende metoder til procesforbedring, vi allerede har dækket. Bemyndigelsen til at “tilpasse” SAFe til den relevante sammenhæng er for det meste utilgængelig for de faktiske hold, der er bedst positioneret til at genkende, hvad der ikke fungerer.

Ingen steder i SAFe-køreplanen henviser det faktisk til noget af dets kernepraksis som overgangsordning. Hvis det er en overgangsramme, gør det et ret dårligt stykke arbejde med at levere enhver form for overgangsplan.

Hyperfokus på certificeringer skader også rammens fleksibilitet . Hvis du bruger timer og timer på at blive certificeret, bliver certificeringen en del af din egen værdi. En overgang til noget, der ligner mindre SAFe, kan virke som om det truer den værdi. Jeg kan ikke bebrejde nogen for at blive certificeret i en jobmarked hvor certificeringer betyder noget. Men disse individer har et særligt ansvar for at være opmærksomme på ulemperne ved SAFe og mulige måder at forbedre eller afvige fra det.

Disse problemer opleves bredt

Jeg er ikke alene om udtrykke mange af denne kritik – selvom jeg håber, jeg er gået lidt længere i at forbinde dem til den specifikke praksis i rammen. Hvis du leder efter bekræftende vidnesbyrd, er der et par:

Ken Schwaber, co-udvikler af Scrum, udtrykte alvorlige bekymringer over SAFe allerede i 2013.

Nicholas M. Chaillan , US Air Force Chief Software Officer, fraråder ”at bruge stive, receptpligtige rammer såsom Scaled Agile Framework (SAFe).”

Forbes-bidragyder Steve Denning opfordrer SAFe til at være ”særlig bekymrende” i sin artikel om hvordan man finder falske agile.

Marty Cagan fra Silicon Valley Product Group forklarer, hvordan SAFe er antitetisk i tankerne fra virksomheder i Silicon Valley.

Bliv sikker derude (ikke SAFe)

Mens SAFe helt sikkert har modtaget en hel del kritik , min personlige mening er, at denne kritik måske ikke har nået et stort publikum ud over visse onlinekredse. Dette er især sandsynligt, når det overvejes sammen med det stigende antal virksomheder, der vedtager rammen hver dag.

For mange mennesker kan ideen om, at der er noget galt med SAFe – eller at det overhovedet er i modstrid med Agile-principper – være helt ny.

Øget diskussion rettet mod et bredere publikum kan sandsynligvis hjælpe. Jeg håber at komme nærmere ind på dette emne i fremtiden og at specificere, hvilke andre alternativer der findes.

Indtil videre, selvom du ikke arbejder i et SAFe-miljø, er det ikke en undskyldning for at blive selvtilfredse . De bekymringer, jeg har beskrevet her, bør betragtes som en bredere advarsel – selv de mest fornuftige ideer kan let koopereres, ødelægges og forvirres, hvis du ikke følger meget med.