Gestionarea orizonturilor de planificare mai lungi Editare
Echipele de dezvoltare își rafinează în mod normal restanțele până la două până la trei iterații înainte, dar în organizațiile mai mari, echipa de marketing a produselor trebuie să planifice mai departe pentru angajamentele lor de piață și discuțiile cu clienții. Aceștia vor lucra adesea cu o foaie de parcurs de 12-18 luni de nivel foarte înalt, apoi vor planifica în colaborare cu echipele trei luni de muncă. Echipele de dezvoltare vor intra în continuare în rafinări detaliate cu 2-3 iterații, urmând doar planuri de sarcini detaliate pentru următoarea iterație.
Menținerea agilității la niveluri abstracte de responsabilitate Editare
În timp ce echipele de dezvoltare au o serie de cadre care definesc modul în care acestea ar trebui să fie agile, există foarte puțin care descrie acest lucru pentru management. SAFe oferă multe dintre aceleași principii, cum ar fi echipele multifuncționale, grupurilor care gestionează nivelurile mai abstracte de responsabilitate și planificare (produs și portofoliu). SAFe a fost, de asemenea, criticat pentru că a agregat prea multe practici disparate.
Tratarea autorității delegate Editează
În Scrum, se așteaptă ca proprietarul produsului să își asume responsabilitatea pentru întregul ciclu de viață al produsului, inclusiv rentabilitatea investiției a deciziilor de dezvoltare, precum și performanța pe piață. În ceea ce privește evoluțiile la scară largă, organizația dorește o vizualizare asupra mai multor restante ale echipei, cum ar fi furnizate de un manager de produs. Deși SAFe presupune că rolul de proprietar al produsului se potrivește cu gestionarea produselor, acesta a fost totuși criticat pentru separarea proprietarilor de produse în organizația de dezvoltare.
Sincronizarea livrabilelor Editare
Cadrele agile sunt concepute pentru a permite dezvoltarea echipa să fie autonomă și liberă să proiecteze modul în care funcționează. SAFe recunoaște că, la scara multor zeci sau sute de echipe de dezvoltare, devine din ce în ce mai haotic ca echipele să se autoorganizeze pe deplin. Prin urmare, pune unele constrângeri asupra acestui lucru, astfel încât acolo unde echipele lucrează la același produs, livrările lor pot fi mai bine sincronizate pentru lansarea împreună, deși acesta a fost un domeniu în care SAFe a fost criticat.
Permiterea timp pentru inovație și planificare Editare
Ciclul de planificare SAFe recomandă includerea unei iterații suplimentare după lansare, astfel încât echipele să își poată îmbunătăți practicile și să fie gata pentru următoarea creștere a planificării. Edițiile anterioare ale SAFe au conceput, de asemenea, acest lucru pentru a fi o iterație de întărire, adică stabilizarea sau întărirea produsului înainte de eliberare. Acest lucru a fost bazat pe complicațiile de a lucra cu medii mari de integrare în care dependențele au însemnat că nu puteți testa totul până la sfârșit. SAFe a fost criticat pentru acest lucru, deoarece reprezenta un element anti-agil sau cascadă, dar era în concordanță cu creșteri slabe de 90 de zile, care fac 13 săptămâni, iar dacă faceți sprinturi de două săptămâni, aveți nevoie de șase dintre ele, plus o planificare de o săptămână sau ciclu de întărire. Acest lucru nu este inclus în edițiile recente ale SAFe.