Vigyázzon a SAFe-re (a Scaled Agile Framework for Enterprise), a sötétség szentségtelen megtestesítésére
… vagy talán nem.
Ha inkább a SAFe önmagáért beszélne, használhatja a fenti link. Több száz oldalnyi dokumentáció, órányi videó, 15 különféle tanfolyam és még sok más található. Ha ez kicsit soknak tűnik, minden tőlem telhetőt megteszek, hogy magyarázatot nyújtsak a SAFe működésére, amikor végigmegyek az egyes pontokon.
A SAFe a legmagasabb szinten, Portfolio néven emlegeti határozatlan idejű „Értékfolyamok” finanszírozása – amelyek általában egy terméket, termékcsaládot vagy ügyféltípust képviselnek. Ugyanakkor a finanszírozást ellenőrző Lean Portfolio Management (LPM) funkció (valószínűleg ugyanazok az emberek, akik korábban felelősek voltak a vízesés-stílusú projektek költségvetéséért), kizárólagos hatáskörrel rendelkeznek annak jóváhagyására, hogy mely portfólió-eposzok (nagy kezdeményezések) mozognak az egyes folyamokban. Az epika nem magyarázat egy olyan problémára, amelyet meg kell oldani. Ők előre megalkotott ötletek arról, hogy miként lehet a legjobban megoldani ezeket a problémákat.
Rögtön láthatjuk a régi iskolák szemléletének jeleit, hogy a csapatokat stratégiai helyett “kézbesítési” funkcióként tekintik meg a csapatok. szintű gondolkodók ötletekkel állnak elő, és az alacsony szintű cselekvők végrehajtják ezeket az ötleteket. Figyelmen kívül hagyják azt a lehetőséget, hogy a műhöz legközelebb állók a legjobban képesek döntéseket hozni ezzel kapcsolatban. Az agilis gondolkodás egyik alapvető célja, hogy megszabaduljon a téves gondolkodásmód elől. A SAFe nem képes távolról teljesíteni.
Hasonló probléma ismét felbukkan, ha valamivel alacsonyabb szintet nézünk.
A SAFe kis termékcsoportokat (gyakran Scrum csapatokat) gyűjt össze az “Agile Release Trains” -be ”- csapattagok, további menedzsment szerepkörökkel, amelyek minden csoportot átfognak az úgynevezett” program szintjén “.
Ezek a szerepek általában gátolják a csapatok autonómiáját. Aránytalanul növelik a folyamat és a kommunikáció általános költségeit az általuk megadott értékkel.
Ezek a szerepek tartalmazzák a Product Manager (PM), az S ystem Architect (SA) és egy Release Train Engineer (RTE).
Az SA és a PM meghatározza és feldarabolja a nagyobb (gyakran a fenti portfóliófolyamatból örökölt) munkákat, majd átadja azokat csapatok.
A Terméktulajdonos és a csapat elméletileg képes lehet más, kisebb munkákat rangsorolni a rájuk rótt munkával szemben, de ezeknek az erőfeszítéseknek korlátozott a láthatósága és a felülről történő vásárlás. Természetes nyomás nehezedik arra, hogy a legmagasabb pontról érkező munkát kezeljük a legfontosabbnak – még akkor is, ha minden egyes csapattag úgy gondolja, hogy más elemek értékesebbek lennének. Emiatt a terméktulajdonos szerepe történetek írására és az elfogadási kritériumok ellenőrzésére szorítkozik, ahelyett, hogy a termék vezetésének egyetlen felelősségvállalási pontja lenne a szerep eredeti szándéka.
The System Architect nincs olyan helyzetben, hogy közel álljon a tényleges mérnöki munkához, ezért az általuk átadott építészeti terv elszakadhat a munka valóságától. Az ilyen jellegű szerepek fémjelezték a nagy tervezésű, előre kialakított vízesés projekteket, és jól megőrződnek az SAFe-ben.
A Release Train Engineers meghatározza a csoportok közötti folyamatokat és a kadenciát, valamint számos operatív feladatot kezel. Végül ez kevesebb teret hagy az egyes csapatok számára, hogy bármilyen módon módosítsák, javítsák vagy kísérletezhessenek saját gyakorlatukkal, amely eltér a kialakult normáktól.
Néha ezeket a problémákat megismétlik egy „Nagy” hozzáadásával. Megoldás szintje ”- a program szintjéhez hasonló, de a kiadási vonatokon átívelő csoportok csoportjainak csoportjai. Amikor ez megtörténik, ugyanazok a problémák valószínűleg megismétlődnek, de úgy tűnik, hogy a Megoldás szintet ritkábban alkalmazzák.
A SAFe (gyakran) a Rally-val együtt érkezik – TOVÁBB korlátozza a csapat autonómiáját
A SAFe gyakran csomagügylet a Rally projektmenedzsment szoftverrel. A Rally az a szoftver, amelyre számíthat egy vállalat, amely a SAFe használatát használja – túlterhelt funkciókkal, céltalan, zavaros, instabil, következésképpen nehéz megtanulni és használni.
Az az érv, hogy elfogadják a Rally-t vezetésért, láthatják majd jelentés, amely egyszerű, egységes képet ad nekik a th A haladás és a problémák az egész vállalkozásban.
Természetesen ez azt jelenti, hogy a vállalatban mindenkinek nemcsak a Rally-t kell használnia, hanem következetesen is. Ez megint csak felülről lefelé történő diktálással érhető el. A rally és a munkáról való gondolkodásmód minden csapatra kényszerül, tekintet nélkül a preferenciákra, a kontextusra vagy a nevezésre. Ahhoz, hogy az összes információ ténylegesen szerepeljen, hihetetlen többletköltségekre van szükség a becslésben és a nyomon követésben, ami mindent lelassít, és rendkívül zavaró lehet a tényleges munka elvégzésében.
Ezenkívül a legfelső szintű jelentés még különösebben sem hasznos. Összpontosít azokra a dolgokra, amelyeket a Rally követ – olyan mutatókra, mint a leadott sztori pontok mennyisége (szó szerint kitalálva) vagy a megoldott hibák mennyiségére (a termék minőségének rettenetes mércéje).Ha a menedzsment figyelmen kívül hagyja ezeket a statisztikákat, akkor az általuk hozzáadott rezsi semmi. Ha sikerül elérni a mutatókat, akkor a statisztikák összemosódnak, így a csapatok jól mutatnak és egyedül maradnak. A becslések túl vannak kitöltve, a kis munkák túlzottak lesznek, és ez könnyen a bizalom megszakadásához vezethet.
A SAFe a lehető legrosszabb megközelítést alkalmazza a függőségek kezelésében
A A függőség olyan eset, amikor a csapatnak meg kell várnia, hogy máshol tegyenek valamit, mielőtt befejezhetné saját munkáját. A SAFe egy olyan visszafelé irányuló szemlélet köré épül, amely szerint a függőségek az élet megváltoztathatatlan tényei, amelyeket el kell fogadni és kezelni kell. Ez néha stratégiai előnyként is említi őket. A valóságban, amikor a függőségeket rossz dolognak gondolja – amelyet minden lehetőségnél minimalizálni kell – akkor azt tapasztalhatja, hogy ezek a lehetőségek bőségesek, és hogy ezek kihasználása elsősorban előnyöket eredményez. Íme néhány javaslat, amelyet az SAFe alul hangsúlyoz vagy teljesen figyelmen kívül hagy:
- Ösztönözze a belső beszerzés kultúráját, ahol az egyik csapat munkákat küldhet be egy másik csapat kódbázisába anélkül, hogy tőlük túl kellene függenie az egyesítés elfogadása
- Könnyítse meg a csapattagok számára a csapatok ideiglenes vagy végleges cseréjét, ha ennek van értelme
- Koncentráljon a csapatok felvételére, strukturálására és képzésére saját szükségleteinek kezelésére külső segítség nélkül
A SAFe valójában a függőségek kezelését választja azáltal, hogy fokozottabban összpontosít a tervezésre, a folyamatra, a hierarchiára és a szabványosításra. Előreláthatólag ez sok olyan találkozót eredményez, amely zavarja a munka elvégzésének képességét. Ezt a megközelítést egy univerzális bevezetés útján írja elő, amely egyszerre érinti az egész szervezetet. Nem veszik figyelembe, hogy mely területek lehetnek önállóak a további megterhelő struktúra nélkül.
Az SAFe túlzottan a tervezés köré irányul
A SAFe alapvető jellemzője a ~ 10 hét gondolata Programnövekmények (PI). Ilyenfajta hatalmas sprintekre gondolhat, amelyek tartalmazzák az összes normál sprintet.
Mindegyik PI körülbelül két napig tartó PI-tervezési eseménnyel kezdődik. A PI-tervezés előszervezési és utótervezési tevékenységeket is igényel a Program szintjén.
Biztosan van némi értéke annak, ha az emberek személyesen állnak össze kapcsolatok építésére, információk megosztására és a célok tájékozódására. Másrészt az a korlátozott időablak használata, hogy előre meghatározott funkciók alapján 10 hetes terveket készítsen meghatározott felhasználói történetekről, majd az ilyen tervek iránti elkötelezettség előírása sokkal kevésbé értékes.
Amint a PI tervezés befejeződik, azok a tervek korlátozottan a megértés és számos feltételezés elavulnak, amint valami újat megtudnak. A csapatok folyamatosan szakadozni fognak azon a téren, hogy ragaszkodnak-e ahhoz a tervhez, amelyet megtanultak, nincs értelme, és az elvárások átirányítása olyan okok miatt, amelyek felettük vannak, nem biztos, hogy megérthetik.
A SAFe a hangerőre irányul, nem érték
A mennyiségi mutatókra, a becslésekre és a csővezetéken keresztüli munkálatokra összpontosítva a valóságban értékes vagy sikeres koncepció könnyen elveszik. Gyakran feltételezik, hogy az ajtón kivitt több munkának “értéknek” kell lennie, még akkor is, ha a termék tapasztalatai valóban szenvednek, és a felhasználók nem részesülnek a további funkciókból.
A SAFe tisztában van azzal a kritikával, hogy nem értékközpontú, és a közelmúltban hozzáadta dokumentációjához a “tervezési gondolkodást”, az “ügyfélközpontúságot” és más koncepciókat. Eddig nem vagyok meggyőződve arról, hogy olyan jelentős változtatásokat eszközölne a folyamatában, amelyek valóban teret engednek ezeknek a dolgoknak. , és eleve megértik őket.
Például az SAFe „ügyfelek” meghatározása nyitva hagyja az üzleti érdekelt felek vagy az értékáramokat „ügyfelekként” finanszírozó személyek meghatározását. nagyon különbözik attól, hogy mindenkit (beleértve a finanszírozást nyújtókat is) átirányítsunk arra, hogy a szoftvert ténylegesen használó végfelhasználók igényeire összpontosítsunk, ami a tervezési gondolkodás alapvető eleme.
A SAFe szükségtelenül összetett
A SAFe természetes előnye, amely véd a kritikától; Olyan bonyolult, hogy nehéz teljesen felfogni. Annak ellenére, hogy több időt töltöttem a keretrendszer kutatásával, valószínűleg még mindig el fogok tévedni néhány dolgot, vagy elmulasztok néhány fontos pontot. A bonyolultság bősége azonban maga is jogos aggodalomra ad okot. Az SAFe-nek annyi találkozója, ellenőrzési pontja, értéke és módszere van, hogy alapvetően lehetetlen mindenkit ugyanazon az oldalon elhelyezni.
A SAFe korlátozza a visszamenőleges kilátásokat és a folyamatos fejlesztéseket
A szerepek a program szintjén és a fenti tagok nem vehetnek részt az összes csapat retrospektíván.Ez azt jelenti, hogy a retrospektívákat nem fogják közvetlenül meghallgatni azok az emberek, akik valóban megváltoztathatják a tárgyalt dolgokat.
Az SAFe módja ennek kompenzálására nem elegendő.
PI tervezés ez az egyetlen alkalom, amikor egy Release Train-ben mindenki garantáltan személyesen együtt lehet. Sajnos rövid retrospektívumot tartalmaz, amely csak a tervezési esemény sikeréhez kapcsolódik.
Az SAFe tartalmaz egy “Ellenőrzés és alkalmazkodás” eseményt az egyes PI vége felé, de úgy tűnik, hogy szinte átugrásra tervezték arról, hogy mennyire nehéz összehangolni az RTE-t. Ha megrendezik, akkor az esemény alapja az utolsó PI mennyiségi mutatóinak áttekintése. Ezenkívül az eseménynek csak 30 percét szánják egy tényleges visszatekintésre, ahol a kérdések felmerülnek és megállapodnak Ha ez az idő egyenletesen oszlik meg a 100 fős kimenő vonat összes tagja között, akkor minden résztvevő körülbelül 10 másodpercenként 18 másodpercet kap arra, hogy problémákat teremtsen olyan körülmények között, ahol valóban meghallgathatók.
SAFe lebontja az összesített fogalmakat
Egy kulcs A SAFe része, amelyhez még nem nyúltam hozzá, a meglévő fogalmak összesítése, például a Scrum, a Kanban, a Lean Product, a Lean UX és a DevOPs.
Ha nem ismeri, javasoljuk, hogy vizsgálja meg az egyes fogalmakat. idővel függetlenül, nem pedig egyszerre. Sokan értékesek maguk is, de a SAFe nem végez nagyszerű munkát a szintetizálásuk során, és néha zavart okozhat. Példa:
Az SAFe rendszeresen támogatja azt, hogy gyakorlata hogyan követi a „Lean-Agile” elveket. A trükk az, hogy a „Lean-Agile” valójában nem utal a „Lean” vagy „Agile” elvekre.
Ehelyett a “Lean-Agile Principles” alkotják a SAFe saját tervezését. Ez az új “elvek” elvetemítik az általa asszimilált fogalmakat. Például a döntések decentralizálásáról szóló oldal (az összes alapelv közül a legalacsonyabb helyre rangsorolva) finoman felforgatja önmagát, hangsúlyozva a döntéshozatal központosításának fontosságát sok felhasználási eset esetében. Más felsorolt elvek hasonló problémákkal küzdenek. Annak a személynek, akinek egyszerre megismerik ezeket az információkat, elveszhet az eredeti fogalmak tényleges jelentése.
A SAFe nem mozgékony
A SAFe mára számos módon megtalálható az agilis gondolkodásmóddal ellentétesnek elég világosnak kell lennie. Tervközpontú, bürokratikus, bonyolult, sok sokszor felesleges folyamatot tartalmaz, felhatalmazza a csapat autonómiáját és még sok minden mást.
De vajon számít-e az, hogy a SAFe agilis-e vagy sem, ha az igazán fontos a hatékonyság? ?
Igen. Megteszi.
Az agilis alapelvek csak agilis alapelvek, mivel általánosságban elismerték és egyetértettek abban, hogy hatékonyak. Ez a gondolkodás a gyakorló szakemberek szélesebb körében visszhangzott, ezért a mozgalom eredetileg elindult. Ha úgy gondolja, hogy az agilitás megjósolja a hatékonyságot (vélhetően a SAFe iránti érdeklődés mögött rejlő meggyőződés), akkor nagyon fontos, hogy az SAFe összhangban áll-e az agilis gondolkodással. Az emberek megtévesztése arról, hogy mit vásárolnak, rossz dolog, és nem helytelen ezt felhívni.
Mi a helyzet az összes olyan esettanulmánnyal, ahol a SAFe bizonyítottan bevált?
Körülbelül 40 esettanulmány található a sikeres SAFe elfogadásról a scaledagileframework.com oldalon. A kudarcok esettanulmányai feltűnően hiányoznak. A rövidítéssel ellentétben az SAFe egy hatalmas új folyamat egyidejű megváltoztatását jelenti egy óriási ökoszisztémában – hatalmas kockázattal. Kivéve, ha mind a 40 sikeres vállalat mindegyikének 11 250 minősített SAFe gyakorlata van, van néhány olyan társaság, amelytől nem hallunk.
Emellett nem teszek túl sok készletet az esettanulmányokba, amelyek létezik. Még akkor is, ha az általuk összpontosított mennyiségi mutatók valóban értékesek voltak, könnyen össze lehet választani néhány olyan statisztikát, amelyek alapján úgy tűnik, hogy a dolgok jól sikerültek.
Ha egy konkrét példára kívánunk koncentrálni, nézzünk meg egy részletet a Fitbit SAFe megvalósításáról szóló esettanulmányból:
2016-ban a Fitbit fogyasztói technológiai vállalat négy új terméket adott ki a piacra, amelyeket pozitívan fogadtak több mint 22 millió készüléket szállítottak. Az év során a legnagyobb számú termék szállítása részben annak köszönhető, hogy a vállalat elkötelezett az iránt, és az SAFe® (Scaled Agile Framework®) bevezetésének sikerének köszönhető, hogy a csapatot a kitűzött időpontok elérésére skálázzák.
© Scaled Agile, Inc.
Íme a Fitbit árfolyama az elmúlt öt évben:
Igen… 2016 nagyszerű évnek tűnik a Fitbit számára.
Most nem tulajdoníthatjuk a Fitbit bukását a SAFe-nek elfogadása a rendelkezésünkre álló információk mennyiségével.De ha egy vállalat ennyire megküzdhet, és még mindig üdvözli a SAFe elfogadását, mivel javítja a termékdöntéseik reakciókészségét, akkor a többi esettanulmány megnézésekor még néhány fokkal összeszűkítem a szemem.
Átmeneti lépésként rendben van, igaz?
Ha valaki olyan, aki ezt az érvet megfogalmazza, akkor gondolnia kell arra, hogy a SAFe-ről át kell térni. Ebben a kérdésben egyetértünk!
Az áttéréshez természetesen egy kis időt kell fordítanunk arra, hogy rámutassunk azokra a részekre, amelyek nem működnek jól.
Ez az, amit Ön sok időt töltött rá?
Még akkor is, ha Ön az, a SAFe úgy van beállítva, hogy megakadályozza a tényleges átállást. Az a hatóság, amelyet a vezetés kezébe ad, a fentről lefelé irányuló irányítási mentalitás legitimációjaként működik. Ez rosszul párosul a folyamat javításának hiányzó módszereivel, amelyeket már ismertettünk. A SAFe megfelelő kontextusba “testreszabásának” joga többnyire nem érhető el azoknak a csapatoknak, akik a legjobban képesek felismerni, hogy mi nem működik.
Az SAFe ütemtervében sehol sem hivatkozik egyikre sem. alapvető gyakorlatok mint átmeneti. Ha átmeneti keretrendszerről van szó, akkor elég rossz munkát végez bármilyen átmeneti terv biztosításával.
A tanúsításokra való túlzott összpontosítás a keret rugalmasságát is sérti . Ha órákat és órákat tölt el a tanúsítás megszerzéséért, a tanúsítás a saját értékének részévé válik. Úgy tűnik, hogy az átmenet valamire, ami kevésbé hasonlít a SAFe-re, fenyegeti ezt az értéket. Nem hibáztathatok senkit azért, mert munkapiac ahol a minősítések számítanak. De ezeknek az egyéneknek különös felelősségük, hogy figyeljenek a SAFe hátrányaira és a javításának vagy az attól való eltérés lehetséges módjaira.
Ezek a problémák széles körben tapasztalhatók
Nem vagyok egyedül e kritikák közül sokat megfogalmazva – bár remélem, hogy valamivel tovább mentem, hogy összekapcsoljam őket a keret konkrét gyakorlataival. Ha megerősítő tanúvallomásokra vágyik, íme néhány:
Ken Schwaber, a Scrum társfejlesztője már 2013-ban komoly aggodalmát fejezte ki az SAFe miatt.
Nicholas M. Chaillan , Az amerikai légierő szoftver vezérigazgatója nem ajánlja, hogy “olyan merev, előíró kereteket használjon, mint a Scaled Agile Framework (SAFe).”
A Forbes munkatársa, Steve Denning felszólítja az SAFe-t, hogy “különösen aggasztó” cikkében. hogyan lehet észrevenni a hamis agilit.
Marty Cagan, a Szilícium-völgy termékcsoportból elmagyarázza, hogy a SAFe hogyan ellentmond a Szilícium-völgyi vállalatok gondolkodásmódjának.
Biztonságban maradhat odakint (nem SAFe)
Bár a SAFe bizonyosan sok kritikát kapott , személyes érzékem szerint ez a kritika bizonyos online körökön túl nem biztos, hogy nagy közönséget ért el. Ez különösen akkor valószínű, ha a keretet nap mint nap alkalmazó vállalatok növekvő száma mellett mérlegeljük.
Sok ember számára elképzelhető, hogy az SAFe-vel bármi baj van – vagy egyáltalán ellentmond az agilis elveknek. teljesen újszerű.
A szélesebb közönség felé irányuló fokozott vita valószínűleg segíthet. Remélem, hogy a jövőben még többet fogok érinteni ezzel a témával, és részletesen bemutatom, milyen alternatívák vannak még.
Most még akkor is, ha nem SAFe környezetben dolgozol, ez nem mentség az önelégültségre. . Az itt kifejtett aggályokat szélesebb körű figyelmeztetésnek kell tekinteni – még a legésszerűbb ötletek is könnyen választhatók, sérülhetnek és összezavarodhatnak, ha nem figyel oda nagyon.