Faire face à des horizons de planification plus longsModifier
Les équipes de développement affinent généralement leur backlog jusquà deux à trois itérations à lavance, mais dans les grandes organisations, léquipe marketing produit doit planifier plus loin pour leurs engagements de commercialisation et les discussions avec les clients. Ils travailleront souvent avec une feuille de route de très haut niveau sur 12 à 18 mois, puis planifieront en collaboration avec les équipes trois mois de travail. Les équipes de développement continueront à affiner en détail 2 à 3 itérations à venir, nentrant que dans des plans de tâches détaillés pour la prochaine itération.
Rester agile à des niveaux abstraits de responsabilité ont un certain nombre de cadres qui définissent comment ils doivent être agiles, il y en a très peu qui décrit cela pour la gestion. SAFe propose bon nombre des mêmes principes, tels que les équipes interfonctionnelles, aux groupes qui gèrent les niveaux les plus abstraits de responsabilité et de planification (produit et portefeuille). SAFe a également été critiqué pour avoir regroupé trop de pratiques disparates.
Gérer les pouvoirs délégués Modifier
Dans Scrum, le propriétaire du produit est censé assumer la responsabilité du cycle de vie complet du produit, y compris le retour sur investissement des décisions de développement, ainsi que la performance sur le marché. Sur les développements à grande échelle, lorganisation souhaite avoir une vue sur plusieurs backlogs déquipe, tels que fournis par un chef de produit. Bien que SAFe assume que le rôle de propriétaire de produit relève de la gestion de produit, il a néanmoins été critiqué pour avoir séparé les propriétaires de produit dans lorganisation de développement.
Synchronisation des livrablesEdit
Les frameworks agiles sont conçus pour permettre le développement léquipe doit être autonome et libre de concevoir son fonctionnement. SAFe reconnaît quà léchelle de plusieurs dizaines ou centaines déquipes de développement, il devient de plus en plus chaotique pour les équipes de sauto-organiser. Cela impose donc certaines contraintes, de sorte que là où les équipes travaillent sur le même produit, leurs livrables puissent être mieux synchronisés pour être diffusés ensemble, bien que ce soit un domaine dans lequel SAFe a été critiqué.
Permettre le temps de linnovation et de la planificationEdit
Le cycle de planification SAFe recommande dinclure une itération supplémentaire après une version, afin que les équipes puissent améliorer leurs pratiques et soient prêtes pour le prochain incrément de planification. Les éditions précédentes de SAFe ont également conçu cela comme une itération de durcissement, cest-à-dire pour stabiliser ou durcir le produit avant de le libérer. Cela reposait sur les complications liées au travail avec de grands environnements dintégration où les dépendances signifiaient que vous ne pouviez pas tout tester jusquà la toute fin. SAFe a été critiqué pour cela car il représentait un élément anti-agile ou en cascade, mais était conforme à des incréments maigres de 90 jours qui durent 13 semaines, et si vous faites des sprints de deux semaines, vous en avez besoin de six plus une planification dune semaine ou cycle de durcissement. Ceci nest pas inclus dans les éditions récentes de SAFe.