lunes, junio 24, 2019

Mi opinión sobre SAFe (Scaled Agile Framework): sí, es un buen comienzo y resuelve ciertos problemas de escalado



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.
Y aunque confieso que cuando vi el diagrama de SAFe - Scaled Agile Framework me asusté y me pareció algo complejo, quisiera compartir en este post lo que he vivido con el framework (1), cuándo recomiendo desplegarlo, los problemas que he visto que soluciona, y sus beneficios. Comencemos entonces.


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
y aunque todo esto se podría resolver sin el marco de SAFe, en organizaciones grandes cuesta generar este tipo alineación y sincronización debido a que su cultura actual - que es justo la que se quiere dinamizar y aumentar la colaboración - no les permite espacios para este tipo de coordinación

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.
Si deseas un ejemplo de resultados organizacionales generados con el framework de SAFe te recomiendo el link de la referencia (1).

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
Por último, quienes no lo han vivido, los invito a experimentarlo,  ver las sinergias organizacionales que son consecuencia de implementar el marco y después compartan sus experiencias, de esa manera todos crecemos.

Hasta acá este compartir.


Saludos ágiles

Jorge Abad




Notas, Comentarios, Referencias y Observaciones

  1. 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í.
  2. Agradecimientos a mi amigo Lucho Salazar por su revisión y feedback en este articulo

4 comentarios:

  1. Muy ecuánime, imparcial y objetivo, gracias por compartir, y por mostrarnos tu experiencia en este campo. Mi preocupación cómo te comentaba es el caer en el fundamentalísimo de los frameworks que nos sigue atando a un pensamiento de recetas y que nos cierra opciones, y lo menciono por ser un fenómeno que veo sigue creciendo.

    ResponderEliminar
  2. luego de leer, les recomiendo mi campaña
    https://es.surveymonkey.com/r/VTYGZTJ

    ResponderEliminar
  3. Beneficios que he visto y me permito agregar; sobre la base de la "excelencia técnica".

    1. Se genera correlación entre la estrategia de la organización y "el propósito de la solución", en algunos casos la estrategia permite mantener el foco en la definición del propósito, en otros, el avance en la definición y desarrollo de la solución, permite reestructurar y/o reenfocar la estrategia

    2. Documentar el contexto; permite que la organización construya y documente no solo los aspectos técnicos o funcionales de la solución, sino sus decisiones, más allá del entregable “software funcionando”; se mantiene en constante revisión el por qué? Y, ¿para qué? De la solución.

    Por otro lado, me surge una pregunta, comentas que “recomiendas comenzar con SAFe, cuándo; Existe una cultura de gestión tradicional muy fuerte”. Me pregunto; si la conclusión de comenzar con SAFe, es dada por una persona externa o “consultor”, y la cultura como dices es muy fuerte; ¿no cabría también la posibilidad que sea tomada como una imposición y por lo tanto un rechazo?

    ResponderEliminar
  4. "Big Planning", SAFe en SONY (mi experiencia personal)
    https://www.linkedin.com/pulse/big-planning-safe-en-sony-mi-experiencia-personal-santill%C3%A1n

    ResponderEliminar