Tu Radar de Madurez Ágil no es la Meta, el Objetivo es Generar Valor

Hola a todos

Por lo general cuando realizamos una evaluación (assessment) del nivel de madurez ágil de un

• rol, 
• equipo, 
• grupo de equipos, 
• programa,
• área de negocio,
• framework,
• cadena de valor (value stream), 
• u organización

es común el uso de los radares (es la práctica común). Y respecto a los radadres los hay para todos los gustos, una lista por la cual podrías empezar son:

• los propuestos y sugeridos por agilityhealth https://agilityhealthradar.com/radars/
• TeamHealth® Radar
• Remote Work Health Radar
• DevOps Health Radar
• Agile Release Train
• Lean Product Health Radar
• Program Health Radar
• Enterprise Business Agility Health Radar
• Para roles tienen
• Enterprise Business Agility Strategist Health Radar
• Agile Coach Health Radar
• Agile Leader Health Radar
• Product Owner Health Radar
• ScrumMaster-Health-Radar
• SAFe® Release Train Engineer Health Radar
• Los usados en SAFe https://www.scaledagileframework.com/metrics/ :
• Business agility self-assessment
• Lean portfolio management self-assessment
• Continuous learning culture self-assessment
• Organizational agility self-assessment
• Enterprise solution delivery self-assessment
• DevOps Health Radar
• Lean-Agile leadership self-assessment
• Agile product delivery self-assessment
• Team and technical agility self-assessment
• Los de La lista de chequeo de Scrum Roosmalen (clic aquí) traducidos Lucho Salazar con:
• Lo fundamental
• Scrum Esencial
• Los Roles
• Los Eventos
• Los Artefactos
• Impedimentos
• Estimaciones
• Velocidad
• Product Backlog
• Grafica de Trabajo Pendiente
• Scrum Diario
• Escalado
• Indicadores Positivos
• Distribuido
• Reuniones
• Equipo

Sin negar, que según las organizaciones he participado en el desarrollo de los propios según los aspectos y cultura predominante - es una tarea común en este proceso de agile coaching- .

Lo que esta bien con los radares

Los radares:

• ayudan a identificar gaps
• muestran áreas de trabajo en las cuales la industria, un rol o una práctica esta poniendo interés
• permiten al agente de cambio el siguiente paso hacia el cual avanzar.

Lo que está mal con los radares y los niveles de madurez

El problema se presenta cuando el modelo de madurez se vuelve el objeto de deseo organizacional, perdiendo de vista lo realmente importante:

• la generación de valor
• la reducción del time to market
• la innovación
• la supervivencia
• la capacidad de adaptarse al cambio
• la satisfacción del cliente.

Los problemas fundamentales que he observado con los radares y modelos de madurez, son los siguientes:

• Son estáticos y de mentalidad fija
• nos hacen creer que no hay "más allá" y que si logramos eso estamos en el cima del desempeño o el objetivo buscado
• quedan facilmente obsoletos, debido a requieren de agregar otro anillo u otro sector según se progresa en el conocimento o en la práctica
• pueden llegar a convertise en el objetivo en vez de ser un medio para la mejora
• proliferan y es probable que estemos cayendo en el problema de los estandares (ver chiste abajo)
• podemos estar midiendo muchas cosas sin generar resultado o perdiendo de vista lo importante

Qué hacer entonces

Tal como lo sugiere el título del artículo, debemos enfocarnos primordialmente en métricas (valores que aumentan o disminuyen) que nos muestren si estamos o no generando valor, si estamos innovando, mejorando nuestra adaptabilidad y resiliencia, tales como:

• reducción del time to market (que cada vez sea menor 🡻)
• flujo de una pieza (que cada vez la unidad de generación de valor sea más pequeña y de a una pieza 🡻)
• cantidad de defectos (que cada vez sea menor 🡻)
• satisfacción del cliente interno (que cada vez sea mayor 🡹)
• satisfacción del cliente externo (que cada vez sea mayor 🡹)
• adopción de innovaciones propuestas (que cada vez sea mayor 🡹)
• salud, bienestar o felicidad de los equipos de trabajo (que cada vez sea mayor 🡹)

Esta forma de medir te moverá hacia la mejora continua de lo que estas buscando y tu objetivo será alcanzar la perfección tan deseada y sanamente inalcanzable (kaizen), y en consecuencia al tratar de mover estas métricas claves (aumentar o reducir su valor) hará que sistémicamente tomes decisiones que te dirijan hacia tu objetivo, con el beneficio adicional que este tipo de drivers nunca queda obsoleto.

Similar a como lo adopta el State of Devops (2), con 4 métricas puedes comprender cual es el performance de una organización respecto a este conjunto de prácticas o cultura:

Tomado de (2)

• Deployment frecuency 🡹 - Frecuencia de despliegues  
• Lead time for changes 🡻- Tiempo del proceso para cambios (desde el commit hasta producción)- 
• Time to restore service🡻 - Tiempo para restaurar el servicio
• Change failure rate 🡻- Tasa de cambios fallidos -  (aunque la verdad prefiero traducir esto como: tasa de problemas desplegados a producción)

Cerrando

No se trata pues de satanizar los radares, ¡No, ni más faltaba! pues estos sirven de guía, pero no podemos perder del foco de lo que buscamos, por lo tanto, la próxima vez que te enfrentes determinar un estado de madurez, en primer lugar, diseña y adopta métricas que te ayuden a validar si se genera valor al cliente final desde un:

• rol 
• equipo
• grupo de equipos
• programa
• área de negocio
• framework
• cadena de valor
• capacidad
• organización

y luego si lo deseas apóyate adicionalmente en los radares.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. The Key to High Performance: What the Data Says - Dr. Nicole Forsgren
• https://www.youtube.com/watch?v=RBuPlMTXuFc
• https://es.slideshare.net/nicolefv/the-key-to-high-performance-what-the-data-says 
2. State of Devops
• https://cloud.google.com/blog/products/devops-sre/the-2019-accelerate-state-of-devops-elite-performance-productivity-and-scaling
• https://cloud.google.com/devops/state-of-devops/
• https://services.google.com/fh/files/misc/state-of-devops-2019.pdf
3. Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles (clic aquí) 

Capacidades de la Agilidad Organizacional

• Sensiblidad (capacidad de percibir el cambio y dar respuesta)
• Versatilidad 
• Flexibilidad 
• Resistencia y Resiliencia
• Capacidad de Innovar
• Adaptabilidad

Tomado de: Enterprise Agility: Being Agile in a Changing World

¿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 y los Diferentes Marcos de Escalamiento

---

Con mi gran amiga Paola Becerra, líder del mundo de Banca Empresarial y Telecomunicaciones, con experiencia en procesos de cambio, formación de equipos agiles y administración de portafolios de transformación; luego de conversar sobre un post anterior - ver acá - decidimos reescribirlo y darle más profundidad. A continuación, les compartimos nuestro primer post juntos, esperamos lo disfruten.

---

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 y su trascendencia en la Transformación Ágil de las organizaciones, algunos temas recurrentes son:

• Hay diversas interpretaciones y expectativas acerca de lo que es el escalar ágil, sus beneficios y desventajas.
• Organizaciones pagan millones de dólares a las consultoras top para que al final de tres meses 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 framework de escalado, cuál es más prescriptivo y cuál es más adaptativo, y como aportan a la transformación organizacional.
• Comparamos sus estrategias de gestión del cambio y confrontamos cual framework es más exitoso, mejor mercadeado, que autor prominente lo creo o que referente promulga y defiende.

Pero luego de desgastarnos varias horas en discusiones bizantinas, nos damos cuenta que los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican y mercadean fuertemente en sus páginas y redes sociales, pero que luego, cuando las empresas citadas fracasan (por razones que se vuelven más un chisme de redes, pero de seguro fueron muchas las causas las que generaron esa debacle– ver Cynefin, espacio del problema complejo (3)- ), los “despublican”, dejándolos de mercadear, y así se concluye que son muchos los factores que impactan el logro o no de un proceso de escalamiento y transformación ágil y este no depende únicamente del framework utilizado.

A continuación, revisaremos algunos de estos aspectos.

Comencemos

Para iniciar, es importante aclarar que escalar ágil (o desescalar una organización - como lo citan varios autores (4) -) es una herramienta de transformación del Management y del Delivery, y como toda herramienta tiene sus beneficios y sus desventajas, por lo que es muy importante conocer el contexto empresarial donde se hace la transformación, haciendo una profundización en:

• conocer la empresa,
• el tamaño,
• su presente y su pasado,
• su cultura organizacional visible e invisible (esta es más importante aún),
• su estilo de liderazgo
• el estado de la tecnología para habilitar el negocio,
• entre otros factores,

ya que no todas las organizaciones necesitan y están dispuestas a hacer lo mismo.

"Ágil es la capacidad de crear y responder al cambio. Es una forma de lidiar y finalmente tener éxito en un entorno incierto y turbulento."  - https://www.agilealliance.org/agile101/

Muchas de las organizaciones quieren ser Ágiles o mejorar su nivel de Agilidad, simplemente porque está de moda decirlo, y debido a esto, los ejecutivos ponen expectativas a veces irreales acerca de lo que implica hacer una iniciativa de escalamiento y transformación ágil, ya que las historias que publican tienen finales felices, que tienen un antes y un después, pero quienes han iniciado el proceso saben muy bien que detrás de esas historias, pues hay innumerables cambios que impactan a la empresa y que redefinen por completo su ADN.

"La agilidad empresarial es la capacidad de una organización para detectar cambios internos o externos y responder en consecuencia para entregar valor a sus clientes."  - https://www.agilealliance.org/glossary/business-agility

Forzar no es Ágil

Por otro lado, las organizaciones no están en el mismo nivel para gestionar una transformación ágil que implicará adoptar uno u otro marco de escalamiento (5); y al igual que las personas tienen su propio “tiempo”, las empresas tienen sus propios ciclos y es importante manejar el cambio sin tratar de presionar tantas modificaciones simultáneas, pues la experiencia nos ha mostrado: primero, forzar es “antiágil”; segundo, lleva a la confusión de las personas quienes no saben cómo comportarse, no entienden qué de lo que hacían estuvo mal antes y qué es lo nuevo que viene a traerles la agilidad; y tercero, se pierde foco de lo que se debe hacer o no; surgiendo preguntas como:

• ¿debo hacer el daily para ser ágil?
• ¿un tablero kanban o Jira, me cambian mi forma de trabajo?
• ¿debo hacer mi día a día operativo como venía haciéndolo?

Dando lugar a interpretaciones y ejecuciones erróneas que terminan torpedeando el proceso, y generando más detractores que promotores. Es de aclarar, que muchos de esos malentendidos surgen al tratar de leer el Paradigma Ágil desde el Tradicional.

Decisión Genuina e involucramiento de la Alta Gerencia

Por lo anterior, es clave que la Transformación Ágil sea una decisión genuina de los ejecutivos del más alto nivel, no es un “cambio para la gente” es un cambio donde la alta dirección participa activamente, entiende, se pone la camiseta, cambia su forma de interactuar, priorizar y decidir; lidera con el ejemplo y son el referente principal de esta nueva forma de trabajo.

Este liderazgo es fundamental, pues mantiene en alto la moral y el foco, guía a los equipos a continuar con flujo constante y es fuente de determinación para hacer el cambio a pesar de las vicisitudes que se encuentren en el camino, pues cuentan con el apoyo y entendimiento de la alta dirección.

Enseñar a los silos a coordinarse para generar valor

Las organizaciones tradicionales tienen en sus estructuras jerárquicas silos funcionales que por años han funcionado de forma aislada (y hasta egoísta) y que bajo este nuevo reto de generar valor más rápido y con menos desperdicio, requieren aprender a funcionar en redes que terminaran generando nuevas topologías de equipos.

El Piloto y los primeros equipos

Tomar la decisión de quienes son los primeros equipos en escalar ágil y las misiones que deben abordar son fundamentales, para enfocar la transformación, pues con ello se da inicio al rediseño del “organigrama” y la identificación de las áreas a comenzar a transformar, pues son las que primero generan fricción con esta forma de trabajo.

Los equipos que inician la transformación ágil requieren un alto grado de coordinación y acompañamiento para fortalecerlos y hacer de ellos casos de éxito, para los siguientes equipos; esos equipos pioneros llevan un peso en sus hombros que no es fácil de manejar; están en la curva de aprendizaje de planear por sprint, manejar la transparencia del error, generar aportes e ideas para un equipo, cambiar de mentalidad y entender el agilísimo integralmente, con los temores que representa el cambio.

Está bien visto fallar, pero no todos están listos

Hay que cuidar a los miembros de los equipos, pues para ellos antes era mal visto equivocarse, estaban solo para hacer caso, no podían aportar o hablar, este cambio genera un choque a nivel personal y estos miembros del equipo tienen bajos niveles de resiliencia, si no se administra el proceso positivamente. Estas personas mal acompañadas pueden llegar a convertirse en los resistentes pasivos de una transformación, algunos de estos miembros pueden impactar negativamente a sus equipos y a los resultados, pues no están convencidos de las virtudes de la agilidad al 100% y prefieren hacer lo de antes, lo que han conocido siempre y desconfiguran lo que se espera de un equipo ágil desde el principio, impactando su desempeño y las iniciativas de escalamiento ágil.

Condiciones de éxito y fracaso

A continuación se comparten algunas condiciones de éxito y fracaso que hemos observado en los procesos de transformación y en la adopción de marcos de escalamiento ágil a nivel organizacional.

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, predictiva y forzada.
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 liderar con el ejemplo	·        La difusión del mindset es delegada en los consultores y algunos roles específicos
Tolerancia al fracaso	·       Alta	·        Baja
Comunicación	·       Fuerte y constante difusión de la estrategia de cambio, de éxitos, fracasos, logros y retos. ·        Pone a todos en el mismo barco.	·       Tímida, orienta solo al área funcional que la lidera sin involucrar toda la organización.
Espacios de trabajo y herramientas de colaboración	·        Acondicionados para la colaboración (recordar: 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")(5)	·        No sufren cambios
Agilidad Técnica	·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica y Excelencia Operacional.	·        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 modificaciones y personalizaciones que los terminan desfigurando y replicando la situación actual.
Mindset	·        Constante difusión y adopción del mindset lean - agile a todo nivel en la organización(8), viéndose reflejado de forma gradual en los procesos y decisiones de la organización.	·        No intervenido
Respecto a los consultores (7)	·        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

Cerrando

En conclusión, hacer escalamiento de equipos ágiles y transformar una organización hacia la agilidad es un camino de rosas con espinas, no es fácil, y es clave saber armonizar elementos que están colaborando y compitiendo entre sí, pues no es una receta, adicional que no soluciona todos los problemas de una empresa, es un medio para mejorar permanentemente, no es el fin en sí mismo,

Lo que se observa (y faltará que se compruebe estadísticamente) es que:

"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, radica en las personas y su disposición a liderar y adoptar este cambio que cada vez es menos opcional.


Saludos Ágiles
Jorge Abad y Paola Becerra

Notas, Referencias, Aclaraciones, Comentarios y Observaciones

1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
2. Sobre el "Modelo Spotify"
• Failed #SquadGoals https://www.jeremiahlee.com/posts/failed-squad-goals/
• There is No Spotify Model - https://www.infoq.com/presentations/spotify-culture-stc/
• The ‘Spotify model’ is not a model. Here is why. - https://www.linkedin.com/pulse/spotify-model-here-why-jasper-verdooren/
3. Cynefin - https://martinalaimo.com/es/blog/cynefin
4. Interesantes links sobre desescalar:
• The Descaling Manifesto https://xscalealliance.org/
• Descaling Organizations with LeSS- https://less.works/blog/2015/05/08/less-scaling-descaling-organizations-with-less.html
• How to Descale an Organization - https://www.infoq.com/news/2015/05/descaling-organization/ 
• The Shu Ha Ri of Scrum @ Scale https://www.scruminc.com/wp-content/uploads/2016/11/Scrum-at-Scale-GTFS-22-Nov-2016.pdf 
• Welcome to the GOTO Night – Jeff Sutherland & Klaus Bucka-Lassen - https://confadmin.trifork.com/dl/scrum/GOTONight_Jeff%20Sutherland_Scrum%20at%20Scale%20.pdf
• Don’t scale agile – descale your organization! - https://fuehrung-erfahren.de/en/2019/02/dont-scale-agile-descale-your-organization/
5. Algunos Marcos de Escalamiento de equipos ágiles:
• Scrum de Scrums
• Nexus - https://www.scrum.org/resources/nexus-guide
• Discipline Agile Delivery (DAD) - https://www.pmi.org/disciplined-agile
• LeSS (Large-Scale Scrum)- https://less.works/
• Enterprise Scrum - http://www.enterprisescrum.com/
• SAFe (Scaled Agile Framework) - https://www.scaledagileframework.com/
• Scrum at Scale - https://www.scrumatscale.com/
• Enterprise Kanban - https://resources.kanban.university/enterprise-kanban-where-to-start/
6. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
7. Sugerencias de Lucho Salazar
8. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html