Explicación de SAFe Esencial y Grandes Soluciones (SAFe Essential and Large Solutions)

DesEscalando Ágil: Cómo Evitar los Marcos de Escalamiento

¿Por qué Amazon no usa un marco de escalado y por que puede que tú sí lo necesites? - Actualizada

¿Por qué amazon no usa un marco de escalado y por qué puede que tú sí lo necesites? from Jorge Hernán Abad Londoño

¿Por qué Amazon no usa un marco de escalado y por qué puede que tú sí lo necesites?

---

¿Por qué amazon no usa un marco de escalado y por qué puede que tú sí lo necesites? from Jorge Hernán Abad Londoño

En Qué Radica el Éxito de la Transformación Ágil: Un Pensamiento Sobre la Batalla de los Frameworks de Escalado de Ágil

Te recomiendo visitar la versión mejorada de este artículo: http://www.lecciones-aprendidas.info/2020/06/en-que-radica-el-exito-de-la-transformacion-agil.html

Tomado de (1)

Hola a todos

Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado, algunos temas recurrentes son:

• organizaciones pagan millones de dolares a las consultoras top para que al final de tres meses que les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2)
• discutimos sobre cuáles son los beneficios y falencias de cada uno, cuál es más prescriptivo y cuál es más adaptativo
• comparamos sus estrategias de gestión del cambio
• confrontamos cual framework es más exitoso, o que autor prominente lo creo, promulga o defiende, 

Pero luego de desgastarnos un rato en discusiones bizantinas, pues todos los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican orgullosos en sus páginas, pero que luego "despublican" cuando se vuelven fracasos, concluimos que son muchos los factores que compiten o colaboran entre sí, para lograr el éxito o el fracaso.

Factor	Hacia el éxito	Hacia el fracaso
Compromiso del Top-Management	·       alto compromiso e involucramento	·         Delegación completa y desentendimiento
Gestion el cambio organizacional	·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.	·       Fija y predictiva
procesos y contratos	·       Modificados y en continua mejora hacia la agilidad	·       Sin modificar y orientados a la culpa en vez de la colaboración
Respecto a los líderes y al mindset	·        Capacitados y empoderados para compartir el mindset	·        La difusión del mindset es de lagada en los consultores y algunos roles
Tolerancia al fracaso	·       Alta	·        Baja
Comunicación	·       Fuerte y constante comunicación de la estrategia de cambio ·        Comunicación de la estrategia de cambio	·        Poca o nula comunicación
Espacios de trabajo y herramientas de colaboración	·        Acondicionados para la colaboración (los espacios moldean el comportamiento)	·        Limitados y restringidos
Silos organizacionales	·         Colaborando en torno al valor	·        Enfocados en optimizar la agilidad en su área
Métricas de gestión	·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda, "como me midas me comporto")(4)	·        No sufren cambios
Agilidad Técnica	·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica.	·        Adoptada como la compra de herramientas
Cultura	·        incentivar los nuevos comportamientos. ·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización	·        No intervenidos
Respecto a los frameworks ágiles	·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores	·        Adoptados con demasiadas adaptaciones, falencias y personalizaciones que terminan desfigurando y replicando el statu quo actual.
Mindset	·        Constante difusión y adopción del mindset lean - agile (5)	·        No intervenido
Respecto a los consultores (3)	·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento	·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio
Entre otros

Yo me quedo con mi conclusión

"Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

Por lo tanto, el problema al parecer no radica tanto en los frameworks, el problema radica en las personas y su disposición a adoptar este cambio, que dada vez es menos opcional.

Saludos Ágiles

Jorge Abad.

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
2. Yo también puedo hacerlo por la mitad del precio y mejor resultado
3. Sugerencias de mi amigo Lucho Salazar
4. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
5. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html

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

Video Recomendado: Meetup Agilidad a Escala con Ángel Medinilla

Hola a todos

Les comparto excelente video de Angel Medinilla - @angel_m donde nos habla desde el core de agile como afrontar la transformación ágil, hablando desde SAFE, LESS, NEXUS, y cambiando el enfoque en vez de montar frameworks, ¿cual es problema que quiero resolver para: entrega de valor, colaboración, mejora continua, adaptación, de forma empresarial.?

saludos ágiles

Jorge Abad