A hosszabb tervezési horizontokkal való megküzdésSzerkesztés
A fejlesztői csapatok általában két-három ismétléssel finomítják elmaradásukat, de nagyobb szervezeteknél a termékmarketing-csapatnak meg kell terveznie a piac iránti elkötelezettségük és az ügyfelekkel folytatott megbeszélések terén. Gyakran nagyon magas szintű, 12-18 hónapos ütemtervvel fognak dolgozni, majd három hónapos munkára közösen terveznek a csapatokkal. A fejlesztőcsapatok továbbra is részletes finomításba fognak kerülni 2-3 ismétlés előtt, csak a következő iteráció részletes feladatterveibe kerülnek.
Mozgás az elvont felelősség szintjénEdit
Míg a fejlesztői csapatok számos keretrendszerrel rendelkezik, amelyek meghatározzák, hogy miként legyenek mozgékonyak, nagyon kevés leírja ezt a menedzsment számára. A SAFe ugyanazokat az elveket, például a többfunkciós csapatokat szállítja azoknak a csoportoknak, amelyek a felelősség és a tervezés elvontabb szintjeit (termék és portfólió) kezelik. Az SAFe-t azért is kritizálták, mert túl sok eltérő gyakorlatot gyűjtött össze.
Felhatalmazott hatóság kezeléseSzerkesztés
A Scrumban a terméktulajdonos várhatóan felelősséget vállal a termék teljes életciklusáért, beleértve a következőket is: a fejlesztési döntések megtérülése, valamint a piaci teljesítmény. Nagyszabású fejlesztéseknél a szervezet több csapat lemaradását szeretné megtekinteni, amelyet például egy termékmenedzser biztosít. Bár a SAFe feltételezi, hogy a terméktulajdonos szerepe a termékmenedzsment mellett áll, ennek ellenére kritikát róttak rá a terméktulajdonosok szétválasztására a fejlesztési szervezetbe.
A szállítmányok szinkronizálásaEdit
Az agilis keretrendszereket a fejlesztés lehetővé tételére tervezték. hogy a csapat önálló legyen és szabadon megtervezhesse működését. A SAFe elismeri, hogy sok tíz vagy száz fejlesztőcsapat méretében egyre kaotikusabbá válik a csapatok teljes önszerveződése. Ezért bizonyos korlátozásokat ró erre, hogy ahol a csapatok ugyanazon a terméken dolgoznak, az eredményeiket jobban szinkronizálhassák az együttes kiadáshoz, bár ez volt az egyik olyan terület, ahol az SAFe-t kritizálták.
Engedélyezés ideje az innovációnak és a tervezésnekEdit
Az SAFe tervezési ciklusa azt javasolja, hogy egy kiadás után tegyen további iterációt, hogy a csapatok javíthassák gyakorlatukat és készen álljanak a következő tervezési lépésekre. Az SAFe korábbi kiadásai ezt is keményítő iterációnak tervezték, vagyis stabilizálni vagy megkeményíteni a terméket, mielőtt kiadják. Ez a nagy integrációs környezetek kezelésének bonyodalmain alapult, ahol a függőségek azt jelentették, hogy nem lehet mindent a legvégéig tesztelni. A SAFe-t ezért kritizálták, mivel agilis vagy vízeséses elemet képviselt, de összhangban volt a sovány 90 napos emeléssel, amely 13 hetet tesz ki, és ha kéthetes sprinteket végez, akkor hatra van szükség plusz egy hét tervezésre vagy keményedési ciklus. Ez nem szerepel a SAFe legújabb kiadásaiban.