Skalowane środowisko zwinne

Radzenie sobie z dłuższymi horyzontami planowaniaEdytuj

Zespoły programistyczne zwykle udoskonalają swoje zaległości do dwóch do trzech iteracji do przodu, ale w większych organizacjach zespół marketingu produktu musi zaplanować w dalszej perspektywie na ich zobowiązania do wprowadzenia na rynek i rozmowy z klientami. Często pracują na bardzo wysokim poziomie, 12-18-miesięcznym planem działania, a następnie wspólnie z zespołami planują trzy miesiące pracy. Zespoły programistyczne nadal będą szczegółowo dopracowywać 2-3 iteracje z wyprzedzeniem, wchodząc tylko w szczegółowe plany zadań na następną iterację.

Utrzymywanie zwinności na abstrakcyjnych poziomach odpowiedzialnościEdytuj

Podczas gdy zespoły programistyczne mają wiele ram, które definiują, w jaki sposób powinny być zwinne, niewiele jest opisów tego dla zarządzania. SAFe dostarcza wiele takich samych zasad, takich jak zespoły wielofunkcyjne, grupom, które zajmują się bardziej abstrakcyjnymi poziomami odpowiedzialności i planowania (produkt i portfolio). SAFe był również krytykowany za agregowanie zbyt wielu rozbieżnych praktyk.

Radzenie sobie z delegowanymi uprawnieniamiEdit

W Scrumie właściciel produktu powinien przyjąć odpowiedzialność za pełny cykl życia produktu, w tym zwrot z inwestycji decyzji rozwojowych, jak również wyniki na rynku. W przypadku projektów na dużą skalę organizacja potrzebuje widoku wielu zaległości zespołu, na przykład dostarczonych przez menedżera produktu. Chociaż SAFe zakłada, że rola właściciela produktu jest związana z zarządzaniem produktem, niemniej jednak jest krytykowany za oddzielanie właścicieli produktów do organizacji programistycznej.

Synchronizacja elementów dostarczanych zespół, aby był autonomiczny i mógł swobodnie projektować sposób ich pracy. SAFe przyznaje, że w skali wielu dziesiątek lub setek zespołów programistycznych pełna samoorganizacja zespołów staje się coraz bardziej chaotyczna. W związku z tym nakłada na to pewne ograniczenia, aby tam, gdzie zespoły pracowały nad tym samym produktem, ich rezultaty można było lepiej zsynchronizować w celu wspólnego wydania, chociaż był to jeden z obszarów, w którym SAFe był krytykowany.

Zezwalanie czas na innowacje i planowanie Wcześniejsze edycje SAFe również zaprojektowały to jako iterację utwardzającą, czyli stabilizującą lub utwardzającą produkt przed jego wypuszczeniem. Było to oparte na komplikacjach związanych z pracą z dużymi środowiskami integracyjnymi, w których zależności oznaczały, że nie można było przetestować wszystkiego do samego końca. SAFe był krytykowany za to, ponieważ reprezentował element anty-zwinny lub kaskadowy, ale był zgodny z odchudzonymi 90-dniowymi przyrostami, które dają 13 tygodni, a jeśli robisz dwutygodniowe sprinty, potrzebujesz sześciu z nich plus tygodniowe planowanie lub cykl hartowania. Nie jest to uwzględnione w ostatnich wydaniach SAFe.