¿El framework SAFe está desfasado?

  • Actualizado: 15 octubre 2024
  • 7 minutos
Artículo escrito por

Antítesis de agilidad, burocracia kafkiana, marco rígido... Los calificativos poco halagüeños son a veces numerosos cuando se trata de hablar de SAFe, el principal framework para hacer avanzar la Agilidad a nivel empresarial. Pero, ¿estas críticas están justificadas o SAFe es víctima de una mala prensa, alimentada por ciertas ideas preconcebidas? Para averiguarlo, hemos preguntado a varios expertos de Thiga sobre sus experiencias en este campo y sus consejos para maximizar los beneficios de este marco.

Londres, marzo de 2024. Carlos González De Villaumbrosia, fundador de Product School, lanza un órdago en la conferencia ProductCon con su abierta crítica al Scaled Agile Framework (SAFe). En su opinión, las intenciones son buenas, pero el framework se ha vuelto demasiado complejo, demasiado centrado en la entrega en lugar de en el impacto, olvidando las fases críticas de discovery y Go-to-market.

Una crítica regularmente amplificada por voces influyentes como Marty Cagan. Pero, ¿por qué tanto odio? Repasemos los principales fundamentos de SAFe para deconstruir los mitos que lo rodean y proponer un marco de referencia útil para cualquier proyecto de transformación.

🧑‍🍳 SAFe a la carta: de ti depende elegir los ingredientes

SAFe 6.0 es definido por sus fundadores como una "base de conocimiento compuesta por principios, prácticas y habilidades integradas y probadas para lograr Business Agility utilizando Lean, Agile y DevOps."

La elección de las palabras llama la atención. Porque SAFe documenta principalmente prácticas probadas que existían antes y seguirán existiendo después. Reúne áreas que a menudo tienden a trabajar en silos, por ejemplo, la experiencia del usuario y el product management, frente a DevOps. Es un marco de referencia y un lenguaje común para alinear a los equipos en torno a un roadmap de transformación y competencias compartidas, al tiempo que permite la flexibilidad y adaptabilidad necesarias en un mercado en constante cambio.

"A menudo, el negocio habla de negocios, las TI habla de TI y el marketing habla de marketing. SAFe tiene la ventaja de establecer un vocabulario común que permite el diálogo y evita malentendidos", confiesa Romain Pabot, Product Coach y Transformation Lead en Thiga.

Existe una idea intimidante que sugiere que es necesario aplicar todo en SAFe para lograr una transformación exitosa. Pero utilizar SAFe es, ante todo, tomar decisiones. Elecciones entre diferentes prácticas, asociadas a competencias específicas, como Design Thinking, Scrum o incluso el método OKR. Depende de ti elegir las competencias relevantes y extraerlas de la caja de herramientas para desarrollarlas.

"Coge lo que te interese de SAFe. Si tienes un problema de convergencia y alineación, por ejemplo, quizá el concepto de "tren"- el Release Training (ART), un tren virtual formado por equipos multidisciplinares auto-organizados que planifican, organizan y ejecutan su trabajo conjuntamente - sea relevante para ti. En ese caso, hazlo evolucionar en función del valor y el feedback de los usuarios", confirma Romain Pabot. 

SAFe es un modelo de gestión del cambio basado en la práctica, cuya ventaja reside en su capacidad para implantarse de forma rápida. Tienes a tu disposición una gran cantidad de bibliografía y comentarios de la comunidad para implantar rápidamente prácticas y herramientas. Tomemos el ejemplo la PI Planning, un acto clave para alinear el trabajo de los distintos equipos en torno a objetivos comunes. Al final, pasa muy poco tiempo entre la decisión, la aplicación y los primeros resultados. Dede la primera PI Planning, el consenso en torno a las opciones estratégicas se alcanza en el espacio de unas pocas horas, lo que acelera el proceso de toma de decisiones. Algo crucial en un contexto de transformación complejo y costoso.

Según Renaud Chevalier, Socio de Thiga y consultor certificado SPC (SAFe Program Consultant) desde 2015, "SAFe es especialmente útil para las grandes empresas que todavía operan en modo de proyecto MOA/MOE y donde hay urgencia, dados los desafíos post-covid económicos y el Time to market que no está alineado con los desafíos del negocio." Este es el concepto de "burning platafor" de SAFe, que evoca la metáfora de una plataforma petrolera en llamas, donde la urgencia obliga a tomar decisiones conjuntas, radicales y rápidas. 

Entonces, ¿cuál es el punto de partida para elegir las prácticas SAFe adecuadas para tu contexto? Puedes establecer un diagnóstico inicial utilizando una matriz de madurez ágil y de producto para identificar las primeras competencias que deben desarrollarse de forma prioritaria en el próximo PI, y permitir que los colaboradores sean eficientes. El objetivo es pasar de un SAFe mecánico a un SAFe profesional.

La adopción de SAFe debe ser reflexionada y adaptada al contexto específico de cada empresa. Como suele señalar Marty Cagan, los procesos y las herramientas no son universales ni aplicables de la misma manera en todas partes. Hay que asegurarse de que los comportamientos y las competencias que los acompañan están en consonancia con el contexto y los objetivos de la transformación. En resumen, SAFe no es una solución mágica, sino un marco poderoso cuando se adapta a tus necesidades.

🤨 Una cuestión de mentalidad

¿Qué se critica concretamente de SAFe? Para algunos, el framework impone una rigidez que contradice los propios principios de la Agilidad. En concreto, estos críticos acusan a SAFe de volverse demasiado procedimental y de crear una burocracia que ralentiza los procesos de toma de decisiones. Esto puede conducir a una pérdida de flexibilidad y resistencia al cambio.

Sin un fuerte patrocinio, la implantación de SAFe está condenada al fracaso.

Sí, SAFe es un framework y, como cualquier framework, los individuos deben seguir las mismas reglas y hablar el mismo lenguaje para colaborar en equipo. La rigidez que algunos atribuyen a SAFe no es intrínseca al framework en sí, sino que a menudo es el resultado de problemas de gestión del cambio. Si el despliegue de SAFe se vuelve rígido, suele deberse a que los equipos no han recibido el apoyo adecuado para apropiarse de estas prácticas a través de las distintas fases del cambio. El modelo de gestión del cambio ADKAR es una excelente brújula para definir el plan de acción y apoyar a los equipos a través de las diferentes fases de la transformación: 

    • A de Awareness: Explicar por qué es necesario el cambio. 
    • D de Desire: Motivar a los individuos para que se impliquen en el cambio.
    • K de Knowledge: Comunicar la información necesaria para explicar cómo llevar a cabo la transformación.
    • A de Ability: Garantizar que los equipos cuentan con las habilidades necesarias
    • R de Reinforcement : Reforzar el cambio para garantizar su sostenibilidad a lo largo del tiempo. 

Para Kai Hansen, consultor de Peak Product, gran parte del pensamiento inteligente de SAFe queda eclipsado por las reglas y los procesos. Las empresas suelen aplicar el framework sin entender por qué lo hacen, lo que les impide alinearse en torno a objetivos comunes. Sugiere inculcar, ante todo, la mentalidad correcta centrándose en los principios más que en las reglas. Las herramientas y procesos pueden seleccionarse luego para hacer operativos estos principios.

"SAFe propone una jerarquía de roles que puede enfrentar obstáculos, pero tiene el mérito de situar a las personas en el centro. No es perfecto, pero ofrece evaluaciones periódicas, encuestas, retrospectivas, mejora continua, y eso es poderoso", añade Élodie Dufour, consultora y coach Agile en Thiga. Si bien la agilidad requiere una transformación cultural, tener en cuenta el factor humano en el cambio es esencial. Según Renaud Chevalier, "hay que integrar a los mandos intermedios que, hasta ahora, aún no han encontrado su lugar en SAFe. Sin un fuerte patrocinio, la implantación está condenada al fracaso". Primer paso: integrarlos de verdad en el equipo de gestión del cambio para convertirlos en protagonistas.

"SAFe pone de relieve la necesidad de contar con personas transversales, algo que se vuelve crítico a medida que escalas, afirma Romain Pabot. Esto puede ayudar a los mandos intermedios a proyectarse hacia un rol de "líder servidor", es decir, a ponerse al servicio de los equipos que, a su vez, están al servicio de los clientes."

La clave reside en el apoyo al cambio, donde los líderes deben fomentar un profundo conocimiento de los principios ágiles, ofreciendo al mismo tiempo la libertad de adaptar SAFe a las necesidades específicas. SAFe no dicta una forma rígida de trabajar: es la cultura que seas capaz de instaurar la que permitirá a los equipos conservar su capacidad de innovar.

La clave está en el acompañamiento del cambio, donde los líderes deben fomentar una profunda comprensión de los principios ágiles, ofreciendo, al mismo tiempo, libertad para adaptar SAFe a las necesidades específicas. 

SAFe no dicta una forma rígida de trabajar: es la cultura que se implemente la que permitirá a los equipos mantener su capacidad de innovar.

🚨 Alerta spoiler: ¡SAFe es una organización de producto!

SAFe es criticado por centrarse únicamente en el delivery y el desarrollo, en lugar de en el impacto y el valor. ¿El síndrome de la “feature factory”?

El framework pone en el centro de su enfoque la Arquitectura Empresarial, lo que permite estructurar y alinear el trabajo con los objetivos empresariales y las necesidades de los usuarios. Un concepto clave es el de "value streams" (flujos de valor), que organiza el desarrollo en torno a las etapas por las que pasa un producto o servicio para aportar valor al usuario. Por ejemplo, en el caso de un préstamo bancario, incluye etapas como la evaluación, la decisión y la gestión del préstamo. Estas etapas forman una cadena de valor, que representa todas las actividades necesarias para prestar estos servicios a los usuarios.

Hoy en día, algunas empresas construyen sus equipos ágiles en torno a limitaciones, principalmente cognitivas. Por ejemplo, el precepto de que los equipos deben limitarse a siete personas para reducir y optimizar el número de interacciones. El riesgo es aumentar el número de equipos de Producto, crear silos y, en última instancia, crear la famosa "fábrica de funcionalidades" cuyo objetivo es entregar funcionalidades con frecuencia, en detrimento de los objetivos estratégicos comunes. Esta reflexión sobre el tamaño es sin duda importante, pero sobre todo se trata de hacerse las preguntas correctas a la hora de crear trenes: ¿cuáles son los servicios de mi empresa? ¿Qué acciones podrá realizar mi usuario?

"Para apoyar la implantación de SAFe en un contexto de Arquitectura Empresarial, es importante utilizar ejemplos concretos y plantillas para ayudar a las partes interesadas a comprender los conceptos", confiesa Renaud Chevalier, que trabaja con el grupo La Poste en la identificación de sus cadenas de valor. Por ejemplo, en una gran organización pública, los trenes se desglosan según la cadena de tratamiento de los recursos humanos para desarrollar los sistemas y competencias necesarios: nóminas, gestión de personal, sustituciones... ¿El resultado? Dependencias reducidas al mínimo y profesiones comprometidos. La división les permite disponer de un número razonable de interlocutores por parte del Departamento de Sistemas de Información (DSI) e implicarse en la co-construcción de las principales funcionalidades y la programación presupuestaria.

Como señala Romain Pabot, "no por seguir SAFe al pie de la letra tendremos éxito. Necesitas un conocimiento profundo del mercado y anclar tus decisiones en una estrategia empresarial sólida, no sólo ser un experto en procesos de Producto." También necesitas poner en marcha movimientos progresivos y medibles para evaluar los beneficios de esta nueva organización, a través de los grandes indicadores de negocio de la empresa y métricas operacionales como las métricas DORA (DevOps Research and Assessment):

  • DF (Deployment Frequency): la frecuencia con la que el código se despliega en producción.
  • MLTC (Mean Lead Time for Changes): el tiempo medio entre el inicio del desarrollo y el despliegue a producción.
  • CFR (Change Failure Rate): el porcentaje de despliegues en producción que dan lugar a incidencias.
  • MTTR (Mean Time To Recovery): el tiempo que se tarda en restaurar un servicio estable después de un incidente.

Estos cuatro grandes indicadores DORA permiten a la organización identificar oportunidades de mejora continua y medir la excelencia operativa de los cambios implementados, y por tanto tratar la transformación ágil como un producto.

SAFe, mal interpretado o mal implementado, puede generar rigideces. Muchos fracasan por centrarse únicamente en aspectos operativos y procesos, olvidando la dimensión de gestión del cambio. La clave, por tanto, reside en el alineamiento con una estrategia y unos objetivos comunes; la integración y formación de equipos y patrocinadores; y la evaluación continua de las prácticas. SAFe, adaptado al contexto empresarial, ofrece una estructura sólida para el éxito de las transformaciones ágiles a gran escala. De ti depende encontrar lo que buscas.

Si tienes alguna duda o deseas orientación, contacte con nuestro equipo experto en organización de productos.

La newsletter que no querrás perderte

ES-A_Product_Letter

A Product Letter: la newsletter de producto que te hará pensar

El primer miércoles no es un día cualquiera. Es el día en el que sale a la luz un tema de producto desmigajado y reflexionado desde una mirada crítica y humana.