Dejte si pozor na SAFe (Scaled Agile Framework for Enterprise), Unholy Incarnation of Darkness
… nebo možná ne.
Pokud chcete, aby SAFe mluvilo samo za sebe, můžete použít výše uvedený odkaz. K dispozici jsou stovky stránek dokumentace, hodiny videí, 15 různých školení a další. Pokud to zní trochu moc, udělám vše, co bude v mých silách, abych vysvětlil, jak SAFe funguje, když procházím každým bodem.
Na nejvyšší úrovni, která se nazývá „Portfolio“, SAFe obhajuje financování na dobu neurčitou „Hodnotové toky“ – které obvykle představují produkt, produktovou řadu nebo typ zákazníka. Funkce Lean Portfolio Management (LPM), která řídí financování (pravděpodobně stejní lidé, kteří dříve odpovídali za rozpočty projektů ve stylu vodopádů), však mají výhradní oprávnění schvalovat, které Portfolio Epics (velké iniciativy) se přesunou do každého proudu. Eposy nejsou vysvětlení problému, který je třeba vyřešit. Jsou to předem vytvořené představy o tom, jak tyto problémy nejlépe vyřešit.
Hned můžeme vidět známky oldschoolového přístupu k prohlížení týmů jako „doručovací“ funkce místo strategické. myslitelé na úrovni přicházejí s nápady a lidé na nízké úrovni tyto myšlenky provádějí. Ignoruje se možnost, že ti, kteří jsou k práci nejblíže, mohou být nejlépe připraveni rozhodovat o ní. Útěk z tohoto zavádějícího myšlení je základním cílem agilního myšlení, které SAFe nedokáže vzdáleně dosáhnout.
Podobný problém se znovu objeví, když se podíváme na mírně nižší úroveň.
SAFe shromažďuje malé produktové týmy (často Scrum týmy) do „Agile Release Trains“ „- skupiny týmů s další vrstvou rolí správy, která zahrnuje každou skupinu na tzv.„ Úrovni programu “.
Obecně tyto role brání autonomii týmů. Nepřiměřeně přidávají režii procesu a komunikace s hodnotou, kterou poskytují.
Mezi tyto role patří produktový manažer (PM), S. ystem Architect (SA) a Release Train Engineer (RTE).
SA a PM definují a rozdělí větší části práce (často zděděné z výše uvedeného procesu portfolia) a poté je předají do týmy.
Vlastník produktu a tým by teoreticky mohli být schopni upřednostnit jiné, menší práce oproti práci, která jim byla uložena, ale tyto snahy mají omezenou viditelnost a buy-in shora. Bude existovat přirozený tlak na to, aby práce pocházející z nejvyššího bodu byla považována za nejdůležitější – i když každý člen týmu věří, že jiné položky by byly cennější. Z tohoto důvodu se role vlastníka produktu omezuje na psaní příběhů a kontrolu kritérií přijetí, místo aby byla jediným bodem odpovědnosti za vedení produktu, který byl původním záměrem role.
Systémový architekt není v pozici, která by byla blízká skutečnému inženýrskému dílu, takže architektonický plán, který předávají, může být odpojen od reality díla. Tyto druhy rolí byly charakteristickým znakem velkých vodopádových projektů a jsou v SAFe dobře zachovány.
Inženýři Release Train definují konzistentní mezioborový proces a kadenci a zvládají mnoho provozních úkolů. Nakonec to ponechává menší prostor pro jednotlivé týmy, aby mohly upravovat, vylepšovat nebo experimentovat se svými vlastními postupy jakýmkoli způsobem, který se odchyluje od zavedených standardů.
Někdy se všechny tyto problémy znovu opakují s přidáním „Velké Úroveň řešení “- skupiny skupin týmů, které mají obdobné role jako na úrovni programu, ale pokrývají Release Trains. Pokud k tomu dojde, je pravděpodobné, že se stejné problémy budou opakovat, ale úroveň řešení se zdá být zavedena méně často.
SAFe (často) je dodáván s Rally – DALŠÍ omezuje autonomii týmu
SAFe je často balíkovou dohodou se softwarem pro správu projektů Rally. Rally je druh softwaru, který byste očekávali společnost, která vyrábí SAFe – je přetížená funkcemi, nezaostřená, matoucí, nestabilní a následně obtížně se učí a používá.
Hodnotový návrh přijetí Rally pro vedení je ten, že budou moci vidět hlášení, které jim poskytuje jednoduchý, jednotný obraz o Pokrok a problémy v celém podniku.
To samozřejmě znamená, že každý v podniku nejen potřebuje používat Rally, ale musí ji používat konzistentně. Toho lze opět dosáhnout pouze diktátem shora dolů. Rally a způsob, jakým přemýšlí o práci, jsou vynuceny všem týmům bez ohledu na jejich preference, kontext nebo buy-in. Chcete-li mít skutečně k dispozici všechny informace, vyžaduje to neuvěřitelnou režii při odhadování a sledování, která vše zpomaluje a může být extrémně rušivá pro skutečnou práci.
Kromě toho nejsou přehledy na nejvyšší úrovni ani nijak zvlášť užitečné. Zaměřuje se na věci, které Rally sleduje – metriky, jako je objem dodaných bodů příběhu (doslova vytvořených) nebo množství řešených chyb (hrozné měřítko pro „kvalitu produktu“).Pokud vedení tyto statistiky ignoruje, režie, kterou přidají, bude k ničemu. Pokud zvládnou metriky, statistiky budou fušovány, aby týmy vypadaly dobře a zůstaly samy. Odhady budou přeplněné, malé práce budou přehnané, což může snadno vést ke zhroucení důvěry.
SAFe používá nejhorší možný přístup ke správě závislostí
A závislost je případ, kdy tým musí čekat, až se něco udělá jinde, než dokončí svou vlastní práci. SAFe je strukturován na základě zpětného postoje, že závislosti jsou neměnnou skutečností života, kterou je třeba přijímat a spravovat. Dokonce je někdy označuje jako strategickou výhodu. Ve skutečnosti, když si myslíte, že závislosti jsou špatná věc – je třeba je minimalizovat při každé příležitosti -, možná zjistíte, že těchto příležitostí je spousta a že jejich využívání vede především k výhodám. Zde je jen několik návrhů, které SAFe nedostatečně zdůrazňuje nebo zcela ignoruje:
- Podporujte kulturu vnitřního získávání zdrojů, kde jeden tým může odesílat práci do kódové základny jiného týmu, aniž by na ně musel spoléhat přijetí sloučení
- Usnadněte členům týmu dočasnou nebo trvalou výměnu týmů, když to má smysl
- Zaměřte se na najímání, strukturování a tréninkové týmy, aby zvládly své vlastní potřeby bez vnější pomoci
Jak se SAFe ve skutečnosti rozhoduje pro správu závislostí, je větší důraz na plánování, proces, hierarchii a standardizaci. Předvídatelně to vede k mnoha schůzkám, které narušují schopnost vykonávat práci. Ukládá tento přístup prostřednictvím univerzálního zavedení, které ovlivňuje celou organizaci najednou. Není uvažováno o tom, které oblasti by mohly být soběstačné bez další zatěžující struktury.
SAFe se příliš orientuje na plánování
Základní vlastností SAFe je myšlenka ~ 10 týdnů Přírůstky programu (PI). Můžete si představit takové obrovské sprinty, které obsahují všechny vaše běžné sprinty.
Každý PI začíná událostí plánování PI, která trvá přibližně dva dny. Plánování PI také vyžaduje předplánovací a post-plánovací aktivity na úrovni programu.
Určitě má určitou hodnotu, když se lidé setkávají osobně, aby budovali vztahy, sdíleli informace a orientovali se na cíle. Na druhou stranu je použití tohoto omezeného časového okna k vytvoření 10týdenních plánů konkrétních uživatelských příběhů založených na předem definovaných funkcích a následné vyžadování závazku k těmto plánům mnohem méně cenné.
Jakmile plánování PI skončí, tyto plány byly vytvořeny na základě omezeného porozumění a četné předpoklady zastarají, jakmile se dozvíte něco nového. Týmy budou neustále rozpolceny mezi dodržováním plánu, který se naučili, nedává smysl, a přeorientováním očekávání z důvodů, kterým ty nad nimi nemusí rozumět.
SAFe je orientován na objem, nemá hodnotu
Ve všech těchto fokusech na metriky objemu, odhady a churning přes potrubí se koncept toho, co je skutečně hodnotné nebo úspěšné, snadno ztratí. Často se předpokládá, že více práce dodávané ze dveří musí být „hodnotné“, i když zkušenost s produktem ve skutečnosti trpí a uživatelé nevyužívají výhody dalších funkcí.
SAFe si je vědoma kritiky, že není zaměřen na hodnotu a do své dokumentace nedávno přidal „design thinking“, „customer centricity“ a další koncepty, které by to kompenzovaly. Zatím nejsem přesvědčen, že ve svém procesu provádí nějaké významné změny, které ve skutečnosti vytvářejí prostor pro tyto věci a na prvním místě jim to vůbec nerozumí.
Například definice SAFe „zákazníci“ ponechává dveře otevřené definování zúčastněných stran v podnikání nebo těch, kteří financují hodnotové toky jako „zákazníci“. je velmi odlišné od přeorientování všech (včetně těch, kteří poskytují financování), aby se zaměřili na potřeby koncových uživatelů, kteří software skutečně používají, což je základní prvek designového myšlení.
SAFe je zbytečně složitý
SAFe má přirozenou výhodu, která chrání to z kritiky; Je to tak komplikované, že je těžké to úplně pochopit. I přes další čas, který jsem strávil zkoumáním rámce, je pravděpodobné, že některé věci pokazím nebo že mi uniknou některé důležité body. Hojnost složitosti je však sama o sobě oprávněnou obavou. SAFe má tolik schůzek, kontrolních bodů, hodnot a metod, že je v zásadě nemožné dostat každého na stejnou stránku.
SAFe omezuje retrospektivy a neustálé zlepšování
Role na úrovni programu a výše se nemůže zúčastnit všech retrospektiv týmu.To znamená, že retrospektivy nebudou přímo slyšet lidé, kteří mohou skutečně změnit mnoho diskutovaných věcí.
Způsob, jakým se to SAFe snaží kompenzovat, není dostatečný.
Plánování PI je jediný čas, kdy je každý ve Release Train zaručeně osobně pohromadě. Bohužel obsahuje krátkou retrospektivu vztahující se pouze k úspěchu samotné plánovací akce.
SAFe obsahuje událost „Inspect and Adapt“ ke konci každého PI, ale zdá se být téměř navržena k přeskočení na základě o tom, jak těžké je koordinovat pro RTE. Když se akce koná, je připravena kontrolou – samozřejmě – objemových metrik z posledního PI. Kromě toho je pro skutečnou retrospektivu, kde se objevují a odsouhlasují problémy, přiděleno pouze 30 minut akce. Pokud je tento čas rovnoměrně rozdělen mezi všechny členy Release Train pro 100 osob, pak každý účastník dostane přibližně 18 sekund každých ~ 10 týdnů, aby se dostali k problémům v kontextu, ve kterém by mohli být skutečně vyslechnuti.
SAFe má také některé další prvky, jako jsou „hodnotící tabulky“, kde jsou týmy dotazovány širší měrou, ale ty se silně opírají o potvrzení, že jsou dodržovány postupy SAFe, ne o to, zda jsou účinné.
SAFe degraduje koncepty, které agreguje
Klíč součástí SAFe, které jsem se zatím nedotkl, je agregace stávajících konceptů jako Scrum, Kanban, Lean Product, Lean UX a DevOPs.
Pokud nejste obeznámeni, navrhuji prozkoumat každý koncept nezávisle na čase, spíše než najednou. Mnohé z nich jsou samy o sobě cenné, ale SAFe nedělá skvělou práci při jejich skutečné syntéze a někdy může způsobit zmatek. Příklad:
SAFe se běžně hlásí k tomu, jak se její postupy řídí zásadami „Lean-Agile“. Trik spočívá v tom, že „Lean-Agile“ ve skutečnosti neodkazuje na „Lean“ nebo „Agile“ principy.
Místo toho „Lean-Agile Principles“ jsou výtvorem vlastního designu SAFe. Tato nová sada „principů“ pokřivuje koncepty, které asimiluje. Například stránka o decentralizujících rozhodnutích (nejnižší ze všech principů) se nenápadně podvrací zdůrazněním důležitosti centralizace rozhodování pro mnoho případů použití. Jiné uvedené zásady mají podobné problémy. Pro osobu, která je seznámena se všemi těmito informacemi najednou, může dojít ke ztrátě skutečného významu původních konceptů.
SAFe není agilní
Nyní je mnoho způsobů, jak SAFe v rozporu s agilním uvažováním by mělo být docela jasné. Je to plán zaměřený, byrokratický, komplikovaný, zahrnuje spoustu často zbytečných procesů, zbavuje tým autonomie týmu atd.
Ale záleží na tom, zda je SAFe Agile nebo ne, když na tom, na čem nám opravdu záleží, je efektivita ?
Ano. Ano.
Agilní principy jsou pouze agilní principy, protože byly obecně uznány a schváleny jako účinné. Toto myšlení rezonovalo v širší komunitě odborníků, a proto hnutí původně vzlétlo. Pokud si myslíte, že agilita je prediktorem efektivity (víra pravděpodobně za určitým zájmem o SAFe), pak docela záleží na tom, zda je SAFe v souladu s agilním myšlením. Zavádění lidí o tom, co kupují, je špatná věc a není špatné to nazývat.
A co všechny případové studie, u nichž je prokázáno, že SAFe fungovalo?
Na scaledagileframework.com existuje asi 40 případových studií o úspěšném přijetí SAFe. Případové studie o selháních nápadně chybí. Na rozdíl od zkratky zahrnuje SAFe simultánní změny obrovského nového procesu v obrovském ekosystému – obrovské riziko. Pokud by každá z těchto 40 úspěšných společností neměla 11 250 certifikovaných praktiků SAFe, existuje poměrně málo společností, od kterých neslyšíme.
Také nedávám příliš mnoho informací do případových studií, které to dělají existovat. I když metriky objemu, na které se skutečně zaměřují, byly cenné, je snadné vybrat několik statistik, díky nimž se bude zdát, že všechno šlo dobře.
Chcete-li se zaměřit na konkrétní příklad, podívejme se na výňatek z případové studie o implementaci SAFe ve společnosti Fitbit:
V roce 2016 uvedla společnost Fitbit pro spotřební technologie na trh čtyři nové produkty, které byly pozitivně přijaty spotřebitelé a dodali více než 22 milionů zařízení. Dodání nejvyššího počtu produktů za rok je částečně způsobeno závazkem společnosti k úspěchu a úspěchu v přijetí SAFe® (Scaled Agile Framework®) jako způsobu škálování týmu podle cílových dat.
© Scaled Agile, Inc.
Zde je cena akcií společnosti Fitbit za posledních pět let:
Ano … rok 2016 vypadá pro Fitbit jako skvělý rok.
Nyní nemůžeme pád Fitbitu ve skutečnosti připisovat SAFe přijetí s množstvím informací, které máme.Ale pokud se společnost může tolik potýkat a stále vítá přijetí SAFe jako zlepšení odezvy na svá rozhodnutí o produktech, zúžím oči ještě o několik stupňů, když se podívám na ostatní případové studie.
Je to v pořádku jako přechodný krok, že?
Pokud jste někdo, kdo by učinil tento argument, pak si musíte myslet, že od SAFe je třeba odejít. V tomto bodě souhlasíme!
Abychom tento přechod provedli, budeme samozřejmě muset strávit nějaký čas poukazováním na části, které nefungují dobře.
Je to něco, co jsi jste trávili hodně času?
I když jste, je SAFe nastaven tak, aby vám zabránil ve skutečném přechodu. Orgán, který umístí do rukou vedení, slouží jako legitimizace mentality kontroly shora dolů. To se špatně páruje s chybějícími metodami pro zlepšování procesů, které jsme již pokryli. Oprávnění „přizpůsobit“ SAFe příslušnému kontextu je většinou nedostupné pro skutečné týmy, které mají nejlepší pozici, aby rozpoznaly, co nefunguje.
Nikde v cestovní mapě SAFe ve skutečnosti neodkazuje na žádný z jejích základní postupy jako přechodné. Pokud se jedná o přechodný rámec, pak je docela špatné zajistit jakýkoli plán přechodu.
Hyper-zaměření na certifikace také poškozuje flexibilitu rámce . Pokud strávíte hodiny a hodiny prací na získání certifikace, stane se certifikace součástí vaší vlastní hodnoty. Přechod na něco, co vypadá méně jako SAFe, se může zdát, že tuto hodnotu ohrožuje. Nemohu vinit nikoho, že získal certifikaci v trh práce kde záleží na certifikaci. Ale tito jedinci mají zvláštní odpovědnost věnovat pozornost nevýhodám SAFe a možným způsobům, jak je zlepšit nebo se od nich odchýlit.
Tyto problémy jsou široce prožívány
Nejsem sám v vyjadřující mnoho z těchto kritik – i když doufám, že jsem zašel trochu dále v jejich spojování se specifickými postupy v rámci. Pokud hledáte podpůrná svědectví, je zde několik:
Ken Schwaber, spolutvůrce společnosti Scrum, vyjádřil vážné obavy ohledně SAFe již v roce 2013.
Nicholas M. Chaillan , Hlavní softwarový ředitel letectva USA, odrazuje od „používání rigidních, normativních rámců, jako je Scaled Agile Framework (SAFe).“
Přispěvatel Forbes Steve Denning ve svém článku o „obzvláště znepokojivých“ vyzývá SAFe. jak odhalit falešný Agile.
Marty Cagan ze skupiny produktů v Silicon Valley vysvětluje, jak je SAFe protikladný k myšlení společností v Silicon Valley.
Zůstaňte v bezpečí (ne SAFe)
Zatímco SAFe jistě dostalo hodně kritiky , můj osobní pocit je, že tato kritika se možná nedostala k širokému publiku mimo určité online kruhy. To je obzvláště pravděpodobné, když se vezme v úvahu spolu s rostoucím počtem společností, které přijímají tento rámec každý den.
Pro mnoho lidí může být myšlenka, že na SAFe něco není v pořádku – nebo že je vůbec v rozporu s agilními principy – zcela nový.
Pravděpodobně může pomoci zvýšená diskuse zaměřená na širší publikum. Doufám, že se tohoto tématu v budoucnu více dotknu a podrobně popíšu, jaké další alternativy existují.
Prozatím, i když nepracujete v prostředí SAFe, není to omluva, abyste se uspokojili . Obavy, které jsem zde uvedl, je třeba brát jako širší varování – i ty nejrozumnější nápady mohou být snadno kooptovány, poškozeny a zmateny, pokud nevěnujete velkou pozornost.