Affrontare orizzonti di pianificazione più lunghi Modifica
I team di sviluppo in genere perfezionano il loro backlog fino a due o tre iterazioni in anticipo, ma nelle organizzazioni più grandi il team di marketing del prodotto deve pianificare più avanti per i loro impegni sul mercato e le discussioni con i clienti. Lavoreranno spesso con una roadmap di livello molto alto, dai 12 ai 18 mesi, quindi pianificheranno in collaborazione con i team per tre mesi di lavoro. I team di sviluppo continueranno a perfezionare dettagliatamente 2-3 iterazioni successive, entrando in piani di attività dettagliati solo per literazione successiva.
Mantenersi agili a livelli astratti di responsabilità Modifica
Mentre i team di sviluppo hanno un numero di framework che definiscono come dovrebbero essere agili, cè ben poco che lo descriva per la gestione. SAFe fornisce molti degli stessi principi, come i team interfunzionali, ai gruppi che gestiscono i livelli più astratti di responsabilità e pianificazione (prodotto e portafoglio). SAFe è stato anche criticato per aver aggregato troppe pratiche disparate.
Trattare con autorità delegataModifica
In Scrum, il proprietario del prodotto dovrebbe assumersi la responsabilità per lintero ciclo di vita del prodotto, incluso il ritorno sullinvestimento delle decisioni di sviluppo, nonché la performance nel mercato. Sugli sviluppi su larga scala, lorganizzazione desidera una visione di più backlog di team, come quella fornita da un product manager. Sebbene SAFe presupponga che il ruolo di proprietario del prodotto appartenga alla gestione del prodotto, è stato comunque criticato per aver separato i proprietari dei prodotti nellorganizzazione di sviluppo.
Sincronizzazione dei risultatiModifica
I framework agili sono progettati per consentire lo sviluppo team per essere autonomi e liberi di progettare come funzionano. SAFe riconosce che, su scala di molte decine o centinaia di team di sviluppo, diventa sempre più caotico per i team auto-organizzarsi completamente. Pertanto pone alcuni vincoli a questo, in modo che quando i team stanno lavorando sullo stesso prodotto, i loro risultati possono essere sincronizzati meglio per il rilascio insieme, sebbene questa sia stata unarea in cui SAFe è stata criticata.
Consentire tempo per innovazione e pianificazione Modifica
Il ciclo di pianificazione SAFe consiglia di includere uniterazione aggiuntiva dopo un rilascio, in modo che i team possano migliorare le loro pratiche e siano pronti per il successivo incremento di pianificazione. Le precedenti edizioni di SAFe hanno anche progettato che questa fosse uniterazione di rafforzamento, ovvero stabilizzare o indurire il prodotto prima di rilasciarlo. Ciò si basava sulle complicazioni derivanti dal lavorare con ambienti di integrazione di grandi dimensioni in cui le dipendenze significavano che non era possibile testare tutto fino alla fine. SAFe è stato criticato per questo in quanto rappresentava un elemento anti-agile o a cascata, ma era in linea con incrementi magri di 90 giorni che fanno 13 settimane e, se si fanno sprint di due settimane, sono necessari sei di essi più una pianificazione di una settimana o ciclo di tempra. Questo non è incluso nelle ultime edizioni di SAFe.