Constantemente leo y escucho dentro del mundo ágil: fanáticos, detractores, amigos por conveniencia, amigos con derechos, relaciones casuales y relaciones duraderas, affairs, mercenarios, fundamentalistas y todo tipo de relaciones con los frameworks, métodos y metodologías que caen en la sombrilla del Manifiesto Ágil (clic aquí) y eso es bueno, pues genera interesantes discusiones, conclusiones y fuentes de aprendizaje.
En este camino he aprendido que no hay recetas únicas para resolver problemas que tienen los equipos de trabajo que hacen soluciones de software. Desde el punto de vista ágil me declaro Scrum por fuera y Kanban por dentro - pongo de manifiesto que cualquier framework ágil sin excelencia técnica es un desperdicio y dolor de cabeza -, de ahí en adelante lo que funcione será útil para mí, o sea, en pocas palabras soy un mercenario del escalado de ágil.
A nivel de frameworks he trabajado en el mundo ágil con:
- Kanban
- Scrum
- Scrumban
- Playbacks (para BPM)
- Scrum de Scrums
- Nexus
- SAFe
- Scrum@Scale
- y en compañía con el equipo de profesionales que trabajo actualmente también hemos generado nuestros híbridos y combinaciones.
Algunos problemas sistémicos escalando la agilidad
Cuando he trabajado escalando ágil con más de 3 equipos con el mismo Product Backlog, en grandes organizaciones me he topado con los siguientes problemas:- Product Owners que no están al menos tres sprints adelante de su equipo realizando definiciones y resolviendo dependencias
- Product Owners reactivos (similar a la anterior)
- Pobre gestión de dependencias entre equipos (consecuencia de la primera)
- Crecimiento de la complejidad
- Poca o nula comunicación entre equipos
- Se excede la capacidad de los equipos de soporte (infraestructura, riesgos, pruebas no funcionales, legal, etc).
- No se mejora sistemáticamente
Cuándo recomiendo comenzar con SAFe
Considerando lo anterior cuándo recomiendo comenzar con SAFe:- Existe una cultura de gestión tradicional muy fuerte
- Existen al menos 4 equipos trabajando con el mismo Product Backlog
- Los Product Owner no tiene dedicación de al menos el 50% para ejecutar el rol correctamente.
- Se están presentando problemas de gestión de dependencias y
- Se están presentando problemas de gestión de la capacidad de las áreas de soporte
Algunos Beneficios
A continuación comparto algunos beneficios conseguidos en las implementaciones de SAFe que he acompañado, así como algunas que he conocido en la industria:- Beneficios Generales
- Usa Scrum y Kanban como base, lo que permite una mejora sistemática
- Mínimo cada dos semanas hay software funcionando
- Se sale a producción por demanda
- Se tiene al cliente como fundamento y validación de hipótesis
- El latir de Program Increment comienza a dinamizar las organizaciones y a fuerza del hábito termina agilizando el entorno.
- SAFe y cualquier marco ágil requiere de excelencia técnica y de DevOps, SAFe lo pone de forma explícita como insumo para su ejecución.
- La demo gigante al final del ciclo del Program Increment genera un espacio de celebración que genera motivación a los participantes y a la par "presión" social para equipos que han decidido no trabajar con el profesionalismo mínimo que deberían tener.
- Beneficios Asociados al Program Increment Planning (PI Plannig)
- Genera Product Owners proactivos, pues deben estar adelantados al menos 2 o 3 meses en su horizonte de tiempo para la sesión.
- Durante los dos días de PI Plannig genera alineación entre equipos y la organización
- Se resuelven dependencias entre equipos, áreas de negocio y áreas de soporte
- Los equipos de un mismo programa se alinean con el propósito de la solución
- Los equipos del programa se ayudan entre sí, pareciendo una gran tribu. He visto a estos equipos:
- tomar historias de usuario de otros equipos
- probar software que otros equipos hicieron
- expresar su disponibilidad para ayudar a otros
- inquietarse como programa
- celebrar juntos como programa
- Existe validación de capacidad por áreas de soporte
- No permite avanzar con supuestos irreales,
- Permite identificar un plan factible (no fijo) para el próximo ciclo de 2 a 3 meses, es decir un plan sobre el cual se puede hacer inspección y adaptacion.
Y las Conclusiones
A continuación comparto algunas conclusiones:- SAFe en su nivel esencial (o sea a nivel de programas) lo considero un buen comienzo, para agilizar la organización, los otros niveles (Portafolio, Grandes Soluciones, Full SAFe) contienen prácticas que son buenas guías, pero las organizaciones determinarán cuales implementar y cuales no.
- No he conocido la primera gran organización que ha desplegado el 100% de SAFe
- Es un buen comienzo, propone soluciones interesantes a nivel de portafolio y de priorización
- Su orientación a flujos de valor - value streams -, propuesta por muchos en el Mundo Ágil, resuelve problemas sistémicos generados por los silos
- Sugiero desplegar SAFe con Scrum@Scale para dinamizar la toma de decisiones, y acelerar el flujo de información a nivel organizacional, tanto horizontal como vertical.
- SAFe es un medio, no el fin en sí, lo que se quiere es proporcionarle a la organización la capacidad de adaptarse al entorno de forma dinámica.
- En caso de que la organización fuera proclive a la agilidad, prefiero un enfoque más orgánico con una combinacion de Design Thinking + Scrum + Kanban + DevOps y prácticas de Scrum@Scale
Hasta acá este compartir.
Saludos ágiles
Jorge Abad
Notas, Comentarios, Referencias y Observaciones
- Testimonio de uno de los clientes en los que he participado en el despliegue de SAFe -Innovación en Claro para beneficio de sus clientes (clic aquí), los videos juntos los puedes ver aquí.
- Agradecimientos a mi amigo Lucho Salazar por su revisión y feedback en este articulo