Hacer frente a horizontes de planificación más largosEditar
Los equipos de desarrollo normalmente refinan su backlog hasta dos o tres iteraciones por delante, pero en organizaciones más grandes el equipo de marketing de productos debe planificar más adelante para sus compromisos con el mercado y conversaciones con los clientes. A menudo trabajarán con un mapa de ruta de muy alto nivel, de 12 a 18 meses, y luego planificarán en colaboración con los equipos durante tres meses de trabajo. Los equipos de desarrollo seguirán entrando en refinamientos detallados 2-3 iteraciones por delante, y solo entrarán en planes de tareas detallados para la siguiente iteración.
Manteniéndose ágiles en niveles abstractos de responsabilidadEditar
tienen una serie de marcos que definen cómo deben ser ágiles, hay muy poco que describa esto para la gestión. SAFe ofrece muchos de los mismos principios, como equipos multifuncionales, a los grupos que manejan los niveles más abstractos de responsabilidad y planificación (producto y cartera). SAFe también ha sido criticado por agregar demasiadas prácticas dispares.
Tratar con la autoridad delegadaEditar
En Scrum, se espera que el propietario del producto asuma la responsabilidad del ciclo de vida completo del producto, incluyendo el retorno de la inversión de las decisiones de desarrollo, así como el desempeño en el mercado. En los desarrollos a gran escala, la organización quiere una vista de los trabajos pendientes de varios equipos, como la que proporciona un gerente de producto. Aunque SAFe asume que el rol del propietario del producto se encuentra en la gestión del producto, sin embargo, ha sido criticado por separar a los propietarios del producto en la organización de desarrollo.
Sincronización de entregablesEditar
Los marcos ágiles están diseñados para permitir el desarrollo equipo para que sea autónomo y libre para diseñar cómo funcionan. SAFe reconoce que, a la escala de muchas decenas o cientos de equipos de desarrollo, se vuelve cada vez más caótico que los equipos se autoorganicen por completo. Por lo tanto, impone algunas limitaciones a esto, de modo que cuando los equipos están trabajando en el mismo producto, sus entregables se pueden sincronizar mejor para lanzarlos juntos, aunque esta ha sido un área en la que SAFe ha sido criticado.
Permitir tiempo para la innovación y la planificaciónEditar
El ciclo de planificación de SAFe recomienda incluir una iteración adicional después de un lanzamiento, para que los equipos puedan mejorar sus prácticas y estén listos para el siguiente incremento de planificación. Las ediciones anteriores de SAFe también diseñaron esto para ser una iteración de endurecimiento, es decir, para estabilizar o endurecer el producto antes de lanzarlo. Esto se basó en las complicaciones de trabajar con grandes entornos de integración donde las dependencias significaban que no se podía probar todo hasta el final. SAFe fue criticado por esto ya que representaba un elemento anti-ágil o en cascada, pero estaba en línea con incrementos ajustados de 90 días que suman 13 semanas, y si realiza sprints de dos semanas, necesita seis de ellos más una planificación de una semana o ciclo de endurecimiento. Esto no está incluido en las ediciones recientes de SAFe.