Podcast: ¿Qué es el Agilismo y para qué sirve?

Un mal líder puede estropear la cultura y el sistema

Quisiera aprovechar el blog para compartir algo que he visto y que todos sabemos

"Un mal líder puede estropear la cultura y el sistema"

Me explico, en este trasegar acompañando organizaciones en su transformación hacia la agilidad he visto de todo, tal como:

• organizaciones llenas de procesos con equipos muy dinámicos dando excelentes resultados
• organizaciones sin procesos detallados con resultados lentos
• organizaciones con procesos de adorno
• organizaciones con líderes inspiradores y líderes desmotivadores
• y toda clase de combinación pervesa, positiva y mediocre de las anteriores

Llevándonos a decir con Deming

Y en esa misma dirección recordé ésto que publiqué hace un tiempo en linkedin.

Cosa cierta, pero cada vez creo que esto de culpar al sistema, la cultura, los incentivos, los procesos, las métricas, los kpi, etc. es una excusa frecuente, cuando muchas veces una de las causas raíces a muchos problemas sistémicos son:

• el liderazgo
• y la forma como interactuamos

Es por tanto clave intervenir tanto el liderazgo como la forma como interactuamos, pero primeramente el liderazgo, sino será muy poco lo que podamos mejorar en el sistema y la cultura.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

De Colección: Culpamos el sistema, pero el sistema somos nosotros

Me encanta esta cita de Seth Godin

https://seths.blog/2016/06/the-problem-with-complaining-about-the-system/

The problem with complaining about the system …is that the system can’t hear you. Only people can. And the problem is that people in the system are too often swayed to believe that they have no power over the system, that they are merely victims of it, pawns, cogs in a machine bigger than themselves. Alas, when the system can’t hear you, and those who can believe they have no power, nothing improves. Systems don’t mistreat us, misrepresent us, waste our resources, govern poorly, support an unfair status quo and generally screw things up–people do. If we care enough, we can make it change.

Que podría traducirse como:

El problema de quejarse acerca del sistema ... es que el sistema no te oye. Solo la gente puede oir. Y el problema es que las personas en el sistema a menudo se sienten inclinadas a creer que no tienen poder sobre el sistema, que son simplemente víctimas de él, peones, piñones en una máquina más grande que ellos mismos. Por desgracia, cuando juntas que el sistema no puede escucharte, con aquellos que creen que no tienen poder, nada mejora. Los sistemas no nos maltratan, no nos tergiversan, no malgastan nuestros recursos, no gobiernan mal, no apoyan un status quo injusto y, en general, no arruinan las cosas, las personas lo hacen. Si nos importa lo suficiente, podemos hacerlo que cambiar.

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

Más de un millón de mejoras en el año en Toyota

Hola a todos

Con frecuencia citamos cosas por que las hemos escuchado de personas que son relevantes para nosotros y que son referentes.

Hace un tiempo escuché y constantemente compartía algo que varios referentes decían:

 "En Toyota se hacen más de un millón de mejoras en el año con su proceso de mejora continua o Kaizen"

Decidí averiguar la referencia a esa cita y un agilista, Hugo Suaréz me proporcionó la referencia exacta,

Kaizen, la clave de la cultura Japonesa por Masaaki Imai

y la Cita exactamente reza:

"Una de las características de los trabajadores japoneses es que usan tanto el cerebro como las manos. Nuestros trabajadores proporcionan 1.5 millones de sugerencias al año y el 95% de ellas se ponen en uso práctico. Existe un interés casi tangible por el mejoramiento en el aire de Toyota" 

Eiji Toyoda, Presidente del Consejo de la Toyota Motor.

Gracias Hugo por la referencia y esta es una invitación a no detenerse, quiero invitarlos a:

no caer en la tentación de realizar mejora continua por que lo dice el proceso, el framework, el marco, la metodología, o la norma, esta aproximación es una mala interpretación del método de Toyota y se aleja radicalmente del propósito del Kaizen, hay que hacer mejora continua por que es la única forma de hacernos inalcanzables.

Gracias a mis amigos y referentes que han compartido información que es verídica y comprobable, suena obvio, pero es importante saber a que líderes seguir en el mundo empresarial y de la agilidad.

Saludos ágiles


Jorge Abad

Una idea sobre cultura, propósito, principios, valores y procesos

Una conclusión a partir de tantas lecturas y observaciones:

"Los procesos no alcanzan a legislar sobre todo lo que ocurre en una organización y en ausencia de procesos: los valores, principios y cultura de la organización guiarán a lo colaboradores ante cualquier situación, incluso sobre cualquier proceso definido previamente.

Una buena cultura, principios y valores te guiarán al éxito, similar en caso contrario."

Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"

Hola a todos

Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

Casca-Agile (TM)

cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

"El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

"Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:

Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

Las desventajas que esto genera

• Largos tiempo de entrega del incremento (al menos tres sprints más)
• La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
• Bajo involucramiento del PO
• La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
• la responsabilidad sobre el producto construido no existe.
• Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
• El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
• Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
• A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

Las ventajas

• Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

Solución a este antipatrón

La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.

Cerrando

Bien parafrasean muchos a Jeff Sutherland,

"el peor enemigo de Scrum, es un mal Scrum" 

o mejor como él lo dice:

Referemcia(4)

Hasta acá este compartir, bienvenidos los comentarios y experiencias.

Saludos ágiles
Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. La Guía Oficial de Scrum - https://scrumguides.org/
2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html