Estudios de casos de SAFe: Notas de transformación del campo

Este artículo es la tercera parte de la serie de escalamiento Agile de Toptal, diseñada para guiar a los gerentes de proyecto en los esfuerzos de expansión de su equipo. Asegúrese de leer la primera parte, “5 marcos de trabajo de escalamiento ágil comparados: ¿cuál debería usar?” y la segunda parte, "Agile Scaling: SAFe Best Practices for Scrum Masters".

La agilidad es practicada de alguna manera por el 94 % de las empresas, según el 15.º Informe anual sobre el estado de la agilidad. Pero la investigación también sugiere que el 90% de las organizaciones luchan con la implementación Agile en toda la empresa. Por lo general, es el trabajo de los entrenadores ágiles, los maestros de Scrum y otros profesionales de la gestión de proyectos liderar y organizar estos esfuerzos. A menudo, trabajan con equipos o departamentos que se resisten al cambio, en una cultura empresarial que es difícil de entender.

En esta mesa redonda, tres gerentes de proyecto de Toptal discuten los desafíos de liderar transformaciones Agile. Debido a que sus soluciones son compatibles con Scaled Agile Framework (SAFe), también hablamos con Dean Leffingwell, creador de SAFe. Sus ideas colectivas ilustran la necesidad de que los profesionales de SAFe preparen una visión clara de lo que es la agilidad y un plan de liderazgo que pueda atraer a los equipos recalcitrantes.

Hablando SAFe con el creador del Framework

SAFe, un marco formalizado por Scaled Agile, se remonta solo a 2014. Pero para Leffingwell, el trabajo comenzó cuando se encontró por primera vez con equipos Agile a principios de la década de 2000. Como metodólogo de desarrollo de software, quedó impresionado con los resultados de las prácticas Agile en los equipos de desarrollo, e inmediatamente comenzó a explorar cómo se podría aplicar la mentalidad en toda la empresa. Si un equipo ágil pudiera producir resultados, ¿qué podría producir un equipo de equipos ágiles alineados? ¿Cómo se podrían utilizar las prácticas ágiles para proyectos de transformación a gran escala en empresas nacionales o internacionales? Como dice Leffingwell, “Me encanta el desarrollo de software. Me encanta Agile. Solo lo quiero grande ”.

En los años transcurridos desde entonces, las empresas han reconocido los beneficios de SAFe, que incluyen entregas más cortas, mayor calidad del producto, mayor eficiencia y empleados más comprometidos. A partir de 2021, más de un tercio de las organizaciones de todo el mundo utilizan SAFe, y entre sus aspectos más importantes se encuentran los procesos compartidos y el lenguaje unificado que proporciona. Por ejemplo, si un equipo piensa que un sprint dura dos semanas y otro piensa que dura 30 días, crea lo que Leffingwell describe como un "problema de la Torre de Babel". Es difícil para los equipos discutir qué características agregar si ni siquiera pueden ponerse de acuerdo sobre qué significa "característica". “Se [necesita] personas que trabajen de manera común si se quiere construir grandes soluciones”, dice. “No hay un término en nuestra industria que no esté sobrecargado, como 'iteración' o 'sprint' o 'backlog'. Eso no es útil si está tratando de trabajar más allá de los límites regionales y de equipo”.

Historias de éxito ágiles

Lograr que todos en una empresa adopten una forma unificada de hablar y hacer el trabajo es una tarea abrumadora, incluso cuando existe una tremenda urgencia de cambio. En corporaciones establecidas, puede ser más difícil. Leffingwell elabora: “Estás viendo a las compañías más grandes del mundo que están ganando mucho dinero y les va increíblemente bien y compiten, y tienen que cambiar. Bueno, la pregunta para ellos es ¿por qué deberían hacerlo?”. Cada uno de los gerentes de proyecto de Toptal presentados aquí se encontró con preguntas como esta durante sus propias actividades de escalado, y cada uno encontró su propia forma de trabajar a través de sus transformaciones Agile utilizando SAFe.

Demostrando Valor

Álvaro Villena, gerente de proyectos de Toptal en Santiago, Chile, completó recientemente una transición SAFe para una cartera que desarrolla una plataforma de negocios cruzados. “El primer hito en mi transición fue realizar un taller de flujo de valor”, dice. En términos simples, un taller de flujo de valor es una reunión inicial para identificar todo el proceso comercial desde el concepto hasta la entrega y todos los pasos, usuarios, sistemas y puntos débiles intermedios.

Contar con representantes de toda la empresa en el taller ayudó a Villena a comprender la cultura de la empresa y cuáles serían sus obstáculos. “Antes de implementar el taller, había una estructura en la que una empresa tenía su equipo, otra empresa tenía su equipo y la siguiente empresa tenía su equipo; las tres no se hablaban entre sí”.

Villena descubrió que aunque todos los equipos compartían puntos débiles similares, no había colaboración en las soluciones. Por ejemplo, aunque todas las empresas de la cartera enviaron productos, solo una había desarrollado un sistema de seguimiento. No había ninguna razón por la que no pudieran usarlo todos, excepto que nadie había compartido el conocimiento. Una vez que el taller los puso a hablar, el conocimiento comenzó a fluir entre los equipos, las empresas y los propietarios de productos. “Ese tipo de conversación fue muy, muy poderosa para el programa. Fue un buen punto de partida”, dice Villena. Cuando DevOps, diseño y producto saben lo que están haciendo otros equipos, ven que hay soluciones en la empresa que pueden estar usando. “Empiezan a preguntar, '¿Cómo puedo tener eso?' Y ahí es donde intervienes y dices: 'Sigue este proceso'”.

“Nadie quiere un cambio hasta que sabe por qué. Así que empiezas con un por qué y les das un futuro mejor”. Dean Leffingwell, creador de SAFe

Leffingwell sabe que los equipos a veces son resistentes. “Nadie quiere cambios hasta que saben por qué”, le dice a Toptal. “Así que comienzas con un por qué y les das un futuro mejor”. Dar a los equipos una idea de cuánto más eficientes pueden ser es una herramienta poderosa para el liderazgo del cambio.

Incluso cuando todos están entusiasmados a bordo, debe esperar un comienzo difícil. Los equipos que están acostumbrados al desarrollo Waterfall tradicional y los grandes lanzamientos, por ejemplo, pueden tener problemas para pasar a un proceso de desarrollo más iterativo y ágil, incluso si ven el valor en ello. “El primer incremento de programa que hicimos fue un desastre con los equipos”, dice Villena. “Y sabíamos que lo sería; le dijimos al cliente que esperara que los primeros tres meses pudieran ser difíciles”. Para compensar esto, incorporó una iteración única de una semana al final del primer incremento del programa (PI) en la que los equipos podían evaluar su progreso. Organizó un sprint dedicado exclusivamente a mejoras y evaluaciones de procesos que irían más allá de la inspección y adaptación habituales. Encontró útil aplicar una mentalidad ágil no solo al producto sino también a la transición comercial, tomándose el tiempo para dar un paso atrás, ver qué funcionó y qué no, y ajustarlo en consecuencia.

Creando pequeñas victorias

Es importante estar preparado para obstáculos inesperados en su adopción de SAFe. Hace algunos años, el gerente de proyectos de Toptal, Miroslav Anicin en Belgrado, Serbia, estaba haciendo la transición de una empresa de telecomunicaciones a SAFe. La empresa había subcontratado todo su desarrollo de software. Incorporar un equipo fuera del sitio no fue una tarea particularmente onerosa, los problemas involucrados fueron principalmente logísticos. Pero el esfuerzo creó desafíos imprevistos en la transición de la propia empresa. “Estaba buscando las competencias que necesitamos en el tren de lanzamiento”, dice. “Y todas las personas entre las que tuve que elegir eran de marketing, legales, de productos, de finanzas, sin la mentalidad ágil ni siquiera experiencia en Agile”.

Se hizo evidente que la gerencia no tenía experiencia en el manejo de equipos ágiles. La toma de decisiones distribuida requiere que los gerentes renuncien a cierto control, un hecho que los líderes pueden rechazar si no tienen experiencia con marcos ágiles. Para resolver esto, Anicin tuvo que entrenar de abajo hacia arriba y de arriba hacia abajo, entrenando a los líderes junto con sus equipos.

Tal movimiento hacia una toma de decisiones más descentralizada requiere "cambiar la forma de trabajar de comando y control, a través del liderazgo de servicio, a esta cultura de aprendizaje y cultura ágil, y la capacidad de tolerar errores", dice Leffingwell.

Anicin comenzó el proceso de escalamiento incremental, con pequeños proyectos Agile realizados dentro de equipos individuales, no dentro de un marco SAFe, para que los equipos individuales pudieran desarrollar algo de experiencia práctica. Estos proyectos tenían que ser no esenciales y lo suficientemente pequeños para que la empresa no se viera perjudicada si algo salía mal en el primer intento, pero lo suficientemente útiles para mostrar al equipo lo que se podía lograr con el enfoque. Por ejemplo, el equipo de marketing creó una campaña de marketing interna, durante la cual Anicin les enseñó los conceptos básicos de Scrum. Al igual que en el taller de Villena, estos proyectos más pequeños demuestran el valor de Agile en términos reales, para que los miembros del equipo y el liderazgo puedan ver los beneficios de los lanzamientos breves y la mejora continua antes de la transición a gran escala.

Satisfacer las necesidades de sus equipos

Cuando Imane Marouane, gerente de proyectos de Toptal con sede en París, lideró una transformación para una gran institución financiera multinacional, entró en un entorno caótico donde los equipos individuales producían un trabajo sólido pero no compartían la visión de toda la empresa. “Cada equipo tenía su propia prioridad. Cada gerente de producto quería que su producto se entregara primero”.

La solución de SAFe a este problema se puede encontrar en el modelo ponderado del trabajo más corto primero (WSJF). WSJF proporciona un estándar para priorizar el trabajo, de modo que cuando sea el momento de decidir cuál debe ser la próxima tarea, el primer paso no implica disputas sobre cómo clasificar la importancia. En un sistema Agile basado en flujo, no tiene que preocuparse por entregar todo a la vez porque, como dice Leffingwell, “lo más importante es qué trabajo hacer a continuación. Y esa es una pregunta mucho más fácil de responder que cuál es el trabajo más valioso”. SAFe proporciona una forma de resolver las dependencias entre equipos; ordenar las tareas es esencial para este resultado.

El camino de Marouane hacia la resolución de dependencias se volvió incierto: "Después de dos sprints, antes de la primera inspección y adaptación, notamos que algunos equipos no estaban siguiendo nuestro plan de PI". No se seguían las dependencias que se definieron en el plan de PI, por lo que el trabajo de un equipo no pudo comenzar porque la contribución de otro equipo no estaba lista.

“Como era la primera iteración y los equipos no estaban acostumbrados a este tipo de trabajo, decidimos organizar una ceremonia adicional: una reunión semanal para discutir el progreso de las dependencias”, dice Marouane. “Una persona de cada equipo vino a actualizar el progreso de sus contribuciones”. De esta forma, si el Equipo A decía que no podía cumplir, el Equipo B podría saberlo con anticipación y planificar en consecuencia, en lugar de esperar contribuciones que no se materializarían al comienzo de su sprint.

Leffingwell recomienda precaución al realizar este tipo de ajustes en SAFe: “SAFe es un sistema de responsabilidades. … Puedes adaptarlo, pero debes tener mucho cuidado”. Aunque se pretende que el marco sea adaptable, los cambios tienden a quedar integrados si no se reevalúan. La configuración Essential SAFe existe para asegurarse de que cualquier alteración cumpla con los criterios básicos.

La ceremonia adicional de Marouane se incluyó nuevamente en el segundo PI, y en el tercero se eliminó gradualmente. Los equipos no tenían nada que informar que no se hubiera comunicado ya. Un poco más de flexibilidad permitió a Marouane que los equipos regresaran a un proceso más tradicional. Descubrió que la transición en sí misma requería una mentalidad ágil para aprovechar al máximo los equipos de la institución financiera. Y lo que es más importante, el cambio que realizó, a través de su compromiso con la mejora continua, sirvió en última instancia a los principios Lean-Agile que son la base de Essential SAFe. Su solución le dio a la empresa la visión unificada que le faltaba y permitió que los equipos trabajaran juntos hacia las mismas prioridades.

Adaptarse para el futuro

Cualquier marco que opere a escala vendrá con desafíos. El número de partes móviles e intereses en competencia es inmenso. Pero los beneficios son igualmente grandes, y una transición bien ejecutada brindará a los equipos las herramientas que necesitan para trabajar hacia objetivos comunes. Los obstáculos a los que se enfrentará en una implementación a gran escala serán impredecibles, y una mentalidad ágil ayudó a Villena, Anicin y Marouane a adaptarse a desafíos inesperados. Después de todo, para eso está la entrega continua: potenciar su proceso con las herramientas para adaptarse a lo imprevisto.

Scaled Agile también se adapta a las nuevas tecnologías y los estándares de la industria en evolución, introduciendo nuevas herramientas y capacidades según sea necesario. Todos deben mantenerse ágiles y prepararse para lo inesperado. “No tenemos una bola de cristal”, dice Leffingwell. “Simplemente corremos rápido, lideramos con fuerza y ​​seguimos con fuerza, y escribimos lo más rápido que podemos”.