Pas op SAFe (het Scaled Agile Framework for Enterprise), een Unholy Incarnation of Darkness
… of misschien niet.
Als je liever SAFe voor zichzelf spreekt, kun je het gebruiken de link hierboven. Er zijn honderden paginas met documentatie, uren aan videos, 15 verschillende trainingen en meer. Als dat een beetje veel klinkt, zal ik mijn best doen om wat uitleg te geven over hoe SAFe werkt terwijl ik elk punt doorloop.
Op het hoogste niveau, de “Portfolio” genaamd, pleit SAFe voor financiering van onbepaalde “waardestromen” – die gewoonlijk een product, productlijn of klanttype vertegenwoordigen. De Lean Portfolio Management-functie (LPM) die de financiering beheert (waarschijnlijk dezelfde mensen die voorheen verantwoordelijk waren voor projectbudgetten in watervalstijl), krijgen als enige de bevoegdheid om goed te keuren welke Portfolio Epics (grote initiatieven) in elke stroom terechtkomen. Epics zijn geen verklaringen over een probleem dat moet worden opgelost. Het zijn voorgevormde ideeën over hoe deze problemen het beste kunnen worden opgelost.
Meteen kunnen we tekenen zien van de ouderwetse mentaliteit om teams te zien als een “bezorg” -functie in plaats van een strategische. level-denkers komen met ideeën, en de low-level doeners voeren die ideeën uit. Genegeerd wordt de mogelijkheid dat degenen die het dichtst bij het werk staan het best uitgerust zijn om beslissingen te nemen. Ontsnappen aan deze misleide mentaliteit is een kerndoel van Agile-denken dat SAFe slaagt er niet in om op afstand te bereiken.
Een soortgelijk probleem duikt opnieuw op als we naar een iets lager niveau kijken.
SAFe verzamelt kleine productteams (vaak Scrum-teams) in “Agile Release Trains”. “- groepen teams met een extra laag managementrollen die elke groep overspannen op het zogenaamde” programmaniveau “.
Over het algemeen belemmeren deze rollen de autonomie van teams. Ze voegen buitenproportionele overhead voor processen en communicatie toe met de waarde die ze bieden.
Deze rollen omvatten een Product Manager (PM), een S ystem Architect (SA) en een Release Train Engineer (RTE).
De SA en PM definiëren en splitsen grotere stukken werk (vaak overgenomen van het bovenstaande portfolioproces) en geven de stukken vervolgens door aan de teams.
De Product Owner en het team zouden theoretisch in staat kunnen zijn om andere, kleinere stukken werk te prioriteren tegen het werk dat hen wordt opgelegd, maar deze inspanningen hebben een beperkte zichtbaarheid en buy-in van bovenaf. Er zal een natuurlijke druk zijn om werk dat van het hoogste punt komt als het belangrijkste te beschouwen, zelfs als elk teamlid denkt dat andere items waardevoller zijn. Hierdoor wordt de rol van de Product Owner beperkt tot het schrijven van verhalen en het controleren van acceptatiecriteria, in plaats van het enige aanspreekpunt te zijn voor productleiderschap, wat de oorspronkelijke bedoeling was voor de rol.
De systeemarchitect is niet in staat om dicht bij het eigenlijke technische werk te staan, dus het architectonische plan dat ze doorgeven, kan los staan van de realiteit van het werk. Dit soort rollen waren kenmerkend voor watervalprojecten met een groot ontwerp en zijn goed bewaard gebleven in SAFe.
Release Train Engineers definiëren een consistent teamoverschrijdend proces en cadans, en voeren veel operationele taken uit. Uiteindelijk laat dit minder ruimte over voor individuele teams om hun eigen praktijken aan te passen, te verbeteren of te experimenteren op een manier die afwijkt van de gevestigde normen.
Soms worden al deze problemen opnieuw herhaald met de toevoeging van een Groot Oplossingsniveau ”- groepen van groepen teams met rollen die analoog zijn aan die op programmaniveau, maar verspreid over de releasetreinen Wanneer dit zich voordoet, zullen dezelfde problemen zich waarschijnlijk herhalen, maar het oplossingsniveau lijkt minder vaak aanwezig te zijn.
SAFe wordt (vaak) gebundeld met Rally – FURTHER beperking van teamautonomie
SAFe is vaak een pakketdeal met de projectbeheersoftware Rally. Rally is het soort software dat je zou verwachten een bedrijf dat SAFe gebruikt om te maken – het is overladen met functies, ongericht, verwarrend, onstabiel en bijgevolg moeilijk te leren en te gebruiken.
Het waardevoorstel van Rally voor leiderschap is dat ze in staat zullen zijn om te zien rapportage die hen een eenvoudig, eenduidig beeld geeft van th De voortgang en problemen in de hele onderneming.
Natuurlijk betekent dit dat iedereen in de onderneming niet alleen Rally moet gebruiken, maar ook op een consistente manier. Nogmaals, dit kan alleen worden bereikt door dicteren van bovenaf. Rally en de manier waarop ze over werk denken, worden aan alle teams opgedrongen, ongeacht hun voorkeur, context of buy-in. Om werkelijk alle informatie op te rollen, is een ongelooflijke overhead nodig bij het schatten en bijhouden, wat alles vertraagt en zeer storend kan zijn om daadwerkelijk werk gedaan te krijgen.
Bovendien is de rapportage op het hoogste niveau niet eens bijzonder nuttig. Het concentreert zich op de dingen die Rally bijhoudt – statistieken zoals het aantal geleverde verhaalpunten (letterlijk verzonnen) of het aantal verholpen bugs (een vreselijke maatstaf voor “productkwaliteit”).Als het management deze statistieken negeert, is de overhead die ze toevoegen voor niets. Als het ze lukt om aan de statistieken te voldoen, worden de statistieken verzonnen, zodat teams er goed uitzien en met rust worden gelaten. Schattingen zullen te vol zijn, kleine stukjes werk zullen overdreven zijn, en dit kan gemakkelijk leiden tot een instorting van het vertrouwen.
SAFe hanteert de slechtst mogelijke benadering voor het beheren van afhankelijkheden
A afhankelijkheid is een geval waarbij een team moet wachten tot iets elders wordt gedaan voordat ze hun eigen werk kunnen voltooien. SAFe is gestructureerd rond een achterwaartse houding dat afhankelijkheden een onveranderlijk feit van het leven zijn dat moet worden geaccepteerd en beheerd. Het noemt ze soms zelfs een strategisch voordeel. In werkelijkheid, als je afhankelijkheden als iets slechts beschouwt – om bij elke gelegenheid tot een minimum te worden beperkt – zul je merken dat die kansen er in overvloed zijn en dat het benutten ervan vooral voordelen oplevert. Hier zijn slechts een paar suggesties die SAFe te weinig benadrukt of volledig negeert:
- Moedig een cultuur van innerlijke sourcing aan waar het ene team werk kan indienen bij de codebasis van een ander team zonder van hen afhankelijk te zijn. de samenvoeging accepteren
- Maak het teamleden gemakkelijk om tijdelijk of permanent van team te wisselen wanneer dat zinvol is
- Focus op het aannemen, structureren en trainen van teams om in hun eigen behoeften te voorzien zonder hulp van buitenaf
Hoe SAFe ervoor kiest om afhankelijkheden te beheren, is door meer aandacht te besteden aan planning, proces, hiërarchie en standaardisatie. Dit resulteert, zoals te voorspellen, in veel vergaderingen die het vermogen om het werk gedaan te krijgen, verstoren. Het legt deze aanpak op door een universele uitrol die de hele organisatie in één keer raakt. Er wordt geen aandacht besteed aan welke gebieden zelfredzaam zouden zijn geweest zonder de extra belastende structuur.
SAFe is overdreven gericht op planning
Een kernkenmerk van SAFe is het idee van ~ 10 weken Programma-incrementen (PIs). Je kunt dit zien als enorme sprints die al je normale sprints bevatten.
Elke PI begint met een PI-planningsevenement dat ongeveer twee dagen duurt. PI-planning vereist ook pre-planning en post-planning activiteiten op programmaniveau.
Het heeft zeker enige waarde om mensen persoonlijk samen te laten komen om relaties op te bouwen, informatie te delen en zich te oriënteren op doelen. Aan de andere kant is het veel minder waardevol om dat beperkte tijdvenster te gebruiken om 10-weekplannen te maken van specifieke gebruikersverhalen op basis van vooraf gedefinieerde functies, en vervolgens toewijding aan die plannen te eisen.
Zodra PI-planning eindigt, worden die plannen gemaakt op basis van beperkte begrip en talrijke aannames zullen achterhaald zijn zodra er iets nieuws wordt geleerd. Teams zullen voortdurend worden verscheurd tussen het vasthouden aan het plan dat ze hebben geleerd, is niet logisch en het heroriënteren van verwachtingen om redenen die degenen boven hen misschien niet in staat zijn om te begrijpen.
SAFe is gericht op volume, geen waarde
Bij al deze focus op volumestatistieken, schattingen en karnen door de pijplijn, gaat het concept van wat werkelijk waardevol of succesvol is gemakkelijk verloren. Er wordt vaak aangenomen dat meer werk dat de deur uitgaat “waarde” moet zijn, zelfs als de ervaring van het product er echt onder lijdt en gebruikers niet profiteren van de extra functies.
SAFe is zich bewust van de kritiek dat het is niet op waarde gericht en heeft onlangs design thinking, customer centricity en andere concepten toegevoegd aan de documentatie om dit te compenseren. Tot dusverre ben ik er niet van overtuigd dat het significante veranderingen in het proces aanbrengt die daadwerkelijk ruimte maken voor die dingen , en het tast ze überhaupt aan om ze zelfs te begrijpen.
De definitie van SAFe van klanten laat bijvoorbeeld de deur open voor het definiëren van zakelijke belanghebbenden of degenen die de waardestromen financieren als klanten. Dit is heel anders dan iedereen heroriënteren (inclusief degenen die de financiering verstrekken) om zich te concentreren op de behoeften van de eindgebruikers die de software daadwerkelijk gebruiken, een kernelement van ontwerpdenken.
SAFe is onnodig complex
SAFe heeft een natuurlijk voordeel dat beschermt het van kritiek; Het is zo ingewikkeld dat het moeilijk te bevatten is. Ondanks de extra tijd die ik heb besteed aan het onderzoeken van het raamwerk, zal ik waarschijnlijk nog steeds een aantal dingen fout doen of enkele belangrijke punten missen. Een overvloed aan complexiteit is op zichzelf echter een legitieme zorg. SAFe heeft zoveel meetings, checkpoints, waarden en methoden dat het in feite onmogelijk is om iedereen op dezelfde pagina te krijgen.
SAFe beperkt retrospectives en continue verbetering
Rollen op programmaniveau en hierboven kunnen onmogelijk alle team retrospectives bijwonen.Dit betekent dat retrospectieven niet direct gehoord zullen worden door de mensen die veel van de besproken zaken daadwerkelijk kunnen veranderen.
De manier waarop SAFe dit probeert te compenseren is niet voldoende.
PI-planning is de enige keer dat iedereen in een Release Train gegarandeerd persoonlijk bij elkaar is. Helaas bevat het een korte terugblik die alleen betrekking heeft op het succes van het planningsevenement zelf.
SAFe bevat wel een “Inspect and Adapt” -gebeurtenis aan het einde van elke PI, maar het lijkt bijna ontworpen om overgeslagen te worden op basis van over hoe moeilijk het is om te coördineren voor de RTE. Wanneer het evenement wordt gehouden, wordt het voorbereid door – natuurlijk – volumestatistieken van de laatste PI te bekijken. Bovendien worden slechts 30 minuten van het evenement toegewezen voor een daadwerkelijke retrospectieve waarin problemen aan de oppervlakte komen en worden overeengekomen op. Als deze tijd gelijkmatig wordt verdeeld over alle leden van een Release Train voor 100 personen, krijgt elke deelnemer elke ~ 10 weken ongeveer 18 seconden om problemen ter sprake te brengen in een context waarin ze daadwerkelijk kunnen worden gehoord.
SAFe heeft ook een aantal andere elementen, zoals “beoordelingsgrafieken” waarin teams breder worden ondervraagd, maar deze neigen er sterk naar om te bevestigen dat SAFe-praktijken worden gevolgd, niet of ze effectief zijn.
SAFe degradeert de concepten die het aggregeert
Een sleutel een onderdeel van SAFe dat ik nog niet heb aangestipt, is het samenvoegen van bestaande concepten zoals Scrum, Kanban, Lean Product, Lean UX en DevOPs.
Als je niet bekend bent, raad ik aan om elk concept te verkennen onafhankelijk in de tijd in plaats van allemaal tegelijk. Velen zijn op zichzelf waardevol, maar SAFe slaagt er niet goed in ze daadwerkelijk te synthetiseren en kan soms voor verwarring zorgen. Voorbeeld:
SAFe omarmt routinematig hoe zijn praktijken de “Lean-Agile” -principes volgen. De truc is dat “Lean-Agile” niet echt verwijst naar “Lean” of “Agile” -principes.
In plaats daarvan zijn “Lean-Agile Principles” een creatie van SAFes eigen ontwerp. Deze nieuwe set “principes” verdraait de concepten die het assimileert. Zo ondermijnt de pagina over decentralisatie van beslissingen (gerangschikt als de laagste van alle principes) zichzelf subtiel door het belang van centralisatie van de besluitvorming voor veel use-cases te benadrukken. Andere genoemde principes hebben vergelijkbare problemen. Voor een persoon die in één keer kennis maakt met al deze informatie, kan de feitelijke betekenis van de oorspronkelijke concepten verloren gaan.
SAFe is niet Agile
Inmiddels is veel van de manieren waarop SAFe inconsistent met een Agile-mentaliteit zou vrij duidelijk moeten zijn. Het is plangericht, bureaucratisch, gecompliceerd, omvat veel vaak onnodige processen, vermindert de autonomie van het team en meer.
Maar maakt het uit of SAFe al dan niet Agile is, terwijl effectiviteit echt belangrijk is. ?
Ja. Dat klopt.
Agile-principes zijn alleen Agile-principes omdat ze algemeen erkend en overeengekomen werden als effectief. Dat denken resoneerde met een bredere gemeenschap van beoefenaars en daarom is de beweging oorspronkelijk van de grond gekomen. Als je denkt dat agility een voorspeller is van effectiviteit (een overtuiging die vermoedelijk achter een deel van de interesse in SAFe zit), dan maakt het nogal uit of SAFe consistent is met Agile denken. Mensen misleiden over wat ze kopen is een slechte zaak en het is niet verkeerd om dat te noemen.
Hoe zit het met alle casestudys waarin SAFe blijkt te hebben gewerkt?
Er zijn ongeveer 40 casestudys over succesvolle acceptatie van SAFe op scaledagileframework.com. De casestudys voor mislukkingen zijn opvallend afwezig. In tegenstelling tot de afkorting, brengt SAFe gelijktijdige wijzigingen in een enorm nieuw proces in een enorm ecosysteem met zich mee – een enorm risico. Tenzij elk van die 40 succesvolle bedrijven elk 11.250 gecertificeerde SAFe-beoefenaars had, zijn er nogal wat bedrijven waar we niets van horen.
Ook stop ik niet te veel in de casestudys die dat wel doen. bestaan. Zelfs als de volumestatistieken waarop ze zich richten echt waardevol waren, is het gemakkelijk om een paar statistieken te kiezen die het lijken alsof alles goed ging.
Laten we, om ons op een specifiek voorbeeld te concentreren, een fragment bekijken uit de casestudy over de implementatie van SAFe bij Fitbit:
In 2016 bracht het consumententechnologiebedrijf Fitbit vier nieuwe producten op de markt die positief werden ontvangen door consumenten, en heeft meer dan 22 miljoen apparaten verzonden. Het leveren van het hoogste aantal producten in een jaar is gedeeltelijk te danken aan de toewijding van het bedrijf aan en het succes bij het adopteren van SAFe® (Scaled Agile Framework®) als een manier om het team op te schalen om de streefdata te halen.
© Scaled Agile, Inc.
Hier is de aandelenkoers van Fitbit over de afgelopen vijf jaar:
Ja … 2016 ziet eruit als een geweldig jaar voor Fitbit.
Nu kunnen we de ondergang van Fitbit niet echt toeschrijven aan SAFe adoptie met de hoeveelheid informatie die we hebben.Maar als een bedrijf zoveel moeite kan hebben en toch de acceptatie van SAFe kan begroeten als een verbetering van het reactievermogen van hun productbeslissingen, ga ik mijn ogen nog een paar graden vernauwen bij het bekijken van de rest van de casestudys.
Het is echter ok als een overgangsstap, toch?
Als je iemand bent die dit argument zou voeren, dan moet je denken dat SAFe moet worden overgeschakeld van. Op dit punt zijn we het eens!
Om die overgang te maken, zullen we natuurlijk enige tijd moeten besteden aan het wijzen op de onderdelen die niet goed werken.
Is dat iets dat je hebt heb je er veel tijd aan besteed?
Zelfs als dat zo is, is SAFe zo opgezet dat je niet daadwerkelijk kunt overstappen. De autoriteit die het in handen van het management legt, fungeert als een legitimatie van de mentaliteit van top-down controle. Dit past slecht bij de ontbrekende methoden voor procesverbetering die we al hebben behandeld. De bevoegdheid om SAFe “aan te passen” aan de juiste context is meestal niet beschikbaar voor de eigenlijke teams die het best gepositioneerd zijn om te herkennen wat niet werkt.
Nergens in de SAFe-roadmap verwijst het daadwerkelijk naar een van de kernpraktijken als overgangsperiode. Als het een overgangskader is, levert het vrij slecht werk om elk soort transitieplan te bieden.
De hyperfocus op certificeringen doet ook afbreuk aan de flexibiliteit van het framework . Als u uren en uren aan het werk bent om gecertificeerd te worden, wordt de certificering een onderdeel van uw eigen waarde. Een overgang naar iets dat minder op SAFe lijkt, lijkt misschien die waarde in gevaar te brengen. Ik kan niemand kwalijk nemen dat hij gecertificeerd is in een arbeidsmarkt waar certificeringen ertoe doen. Maar die personen hebben een bijzondere verantwoordelijkheid om aandacht te besteden aan de nadelen van SAFe en mogelijke manieren om deze te verbeteren of ervan af te wijken.
Deze problemen worden algemeen ervaren
Ik ben niet de enige in het uiten van veel van deze kritiek – hoewel ik hoop dat ik wat verder ben gegaan om ze in verband te brengen met de specifieke praktijken in het kader. Als u op zoek bent naar ondersteunende getuigenissen, zijn hier er een paar:
Ken Schwaber, mede-ontwikkelaar van Scrum, uitte al in 2013 ernstige zorgen over SAFe.
Nicholas M. Chaillan , Chief Software Officer van de Amerikaanse luchtmacht, ontmoedigt “het gebruik van rigide, prescriptieve frameworks zoals het Scaled Agile Framework (SAFe)”.
Forbes-medewerker Steve Denning roept SAFe op omdat hij “bijzonder zorgwekkend” is in zijn artikel over hoe u nep-Agile kunt herkennen.
Marty Cagan van de Silicon Valley Product Group legt uit hoe SAFe in strijd is met de mentaliteit van Silicon Valley-bedrijven.
Blijf daar buiten veilig (niet SAFe)
Hoewel SAFe zeker veel kritiek heeft ontvangen , mijn persoonlijke gevoel is dat deze kritiek misschien niet een groot publiek heeft bereikt buiten bepaalde online kringen. Dit is vooral waarschijnlijk als we kijken naar het toenemende aantal bedrijven dat het framework elke dag toepast.
Voor veel mensen kan het idee dat er iets mis is met SAFe – of dat het überhaupt in strijd is met de Agile-principes – zijn volledig nieuw.
Meer discussie gericht op een breder publiek kan waarschijnlijk helpen. Ik hoop in de toekomst meer op dit onderwerp te kunnen ingaan en te beschrijven welke andere alternatieven er zijn.
Voorlopig, zelfs als je niet in een SAFe-omgeving werkt, is dat geen excuus om zelfgenoegzaam te worden . De zorgen die ik hier heb uiteengezet, moeten worden opgevat als een bredere waarschuwing – zelfs de meest verstandige ideeën kunnen gemakkelijk worden gecoöpteerd, gecorrumpeerd en verward als u niet goed oplet.