¿Será que Agile está en Crisis? (el caso del extremo #WIP)

Nuestra responsabilidad desde la AGILIDAD

 Un verdad cómoda, para uno e incómoda para otros. Desde la #AGILIDAD, nuestro deber es:

- 💡 Equipos de #AltoRendimiento y #BuenasPrácticas (generar el 🏎Ferrari ). - 🔧 Garantizar despliegue continuo: #DevOps (una 🛣 autopista para el Ferrari y el despliegue de valor de negocio). - 💼 AYUDAR al negocio a #GenerarValor 🎯 (que el Ferrari va en la dirección ⬆ correcta). ¡Si no lo estamos haciendo las tres cosas, nos invitarán a pertenecer a otra organización, no lo dudemos! Obsérvese que no mencioné: ¡Ni #Scrum, ni #Kanban, ni #LeSS, ni #SAFe, etc.! 🚫

---

Video: Las consecuencias del desarrollador barato

Podcast: ¿Generan o no valor? He ahí el dilema de algunos Scrum Masters y Agile Coaches

Diatriba: ¿Generan o no valor? He ahí el dilema de algunos Scrum Masters y Agile Coaches

Hola a todos, 

La agilidad se ha convertido en un elemento fundamental en el mundo empresarial, y los Scrum Masters y Coaches desempeñan un papel crucial en su adopción y éxito. Sin embargo, existe un dilema importante que enfrentan estos profesionales en su búsqueda de transformar equipos y organizaciones hacia la agilidad: ¿Realmente están generando valor? En este artículo, exploraremos en detalle este dilema y analizaremos cómo la entrega temprana y continua de software con valor (primer principio del manifiesto ágil (1)) se convierte en el principio fundamental que debe guiar sus acciones.

El Dilema de la Entrega de Valor

En el contexto empresarial actual, las organizaciones buscan constantemente formas de innovar, mejorar la satisfacción del cliente, reducir riesgos y aumentar sus ingresos. Aquí es donde entran en juego los Scrum Masters y Coaches, cuyo papel es vital para impulsar la agilidad y lograr estos objetivos. Sin embargo, surge una pregunta fundamental: ¿están realmente generando valor en sus equipos y organizaciones? Mucho se dedican a acompañar a sus equipos y a su ecosistema, verificando si hacen o no bien las prácticas ágiles: el daily, la retrospectiva, el Scrum of Scrums; pero olvidan el responder a la necesidad del contexto empresaríal, la razón clave por la cual fueron contratados y fue para cumplir a cabalidad el manifiesto ágil con sus principios en los cuales la palabra software en total aparece cuatro veces:

• Valor 2: Software funcionando sobre documentación extensiva (2).
• Principio 1: Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor (1).
• Principio 3: Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible (1).
• Principio 7: El software funcionando es la medida principal de progreso (1).

Y me pregunto ¿Cuándo rayos olvidamos lo esencial?¿Que parte de todo lo anteior no ha sido clara?  Mi afirmación, como lo digo en muchos espacios, no incluye negación, amo los equipos que se divierten, pero amo más los equipos que se divierten y entregan software valor, los primeros son candidatos a ser reemplazados, los segundos son indispensables.

La Agilidad más allá de las Metodologías

La agilidad no se trata simplemente de adoptar una metodología o marco de trabajo ágil, como Scrum, Kanban. LeSS, DAD  o SAFe. Si bien estos marcos proporcionan un conjunto de prácticas valiosas, el objetivo principal de la agilidad va más allá. Se trata de proporcionar resultados tangibles que es la entrega de software con calidad y uno de los problemas más comunes es la percepción errónea de que el trabajo de Scrum Masters y Coaches se limita a la facilitación de reuniones, la creación de diapositivas, creación de "awareness" (lo decimos en inglés por que suena cool). Si bien estas actividades son importantes, no deberían ser el enfoque principal. La verdadera esencia de su papel es garantizar que los equipos estén entregando software, software de calidad y de valor.

No en vano, en mi organización, amigos empresarios y líderes de transformación me preguntan:

¿Jorge, no tenes o conoces a un(a) Scrum Master / Agile Caoch, bien bueno(a), orientado al delivery que me recomendés?

La frecuencia con la que me encuentro con esta situación es asombrosa (y suena ilógico que explícitamente lo digan ¿No creen? Pues ese es uno de los objetivos claves del rol). Los individuos que no priorizan el "delivery", lamentablemente, suelen no ser de gran utilidad. Sin un software funcional, de calidad y valioso, se convierten en un lastre costoso que impide que un equipo igualmente costoso logre un impacto significativo. Además, estos líderes bien intencionados tienden a centrarse en la organización de eventos que, desafortunadamente, no conducen a mejoras en el desempeño, ni a nivel de equipo ni organizacional.

El Rol de los Scrum Masters y Agile Coaches en la Entrega de Valor

Los Scrum Masters tienen la responsabilidad de transformar a los equipos en equipos de alto desempeño, ese es su principal entregable. Esto significa mucho más que solo estar presente en las retrospectivas o crear visualizaciones de burndown. Implica medir y demostrar cómo el equipo está generando valor, reduciendo riesgos y mejorando el rendimiento de la organización en su conjunto.

Los Agile Coaches, por otro lado, deben crear un ecosistema de alto rendimiento en toda la organización. Esto no se trata solo de conversaciones con los equipos. Implica medir el impacto de las prácticas ágiles en la organización y dejar un legado de mejora continua. 

La agilidad debe generar dinero

es un imperativo inaplazable, donde el concepto de dinero o 'valor' abarca desde la mejora en el tiempo de comercialización (time to market), la reducción de costos y el aumento de ingresos hasta la satisfacción del cliente y la reducción de quejas (con la aspiración de que estas últimas desaparezcan), junto con una mayor participación en el mercado. Todo esto, se traduce en la creación de valor sólido para la organización, sin dejar de lado la importancia de cuidar a las personas, tanto a los equipos internos como a los externos, a todas las partes interesadas y, por supuesto, a los propios clientes.

Asumir esta responsabilidad se convierte en un deber fundamental, algo que destaco constantemente a quienes tengo el privilegio de acompañar. Quiero invitarte, mientras lees este artículo, a que reflexiones sobre tu papel. No puedes simplemente esperar que las cosas sucedan; eres un agente de cambio y tu función principal es dejar a los equipos y a su ecosistema en un estado mucho mejor del que encontraste. La única manera de saberlo es a través de la medición, ya que como bien se dice,

"Lo que no se mide no se mejora"

- atribuida a Lord Kelvin, otros la atribuyen  Peter Drucker.

La Importancia de las Métricas en la Agilidad

La clave para superar este dilema radica en el uso adecuado de las métricas. Las métricas ágiles deben ir más allá de la simple medición de la velocidad de entrega. Deben abordar aspectos como la satisfacción del cliente, la calidad del software, la reducción de la deuda técnica y la mejora continua.

Las métricas efectivas permiten a los Scrum Masters y Agile Coaches demostrar cómo su trabajo está contribuyendo al éxito de la organización. Esto no solo proporciona una base para la toma de decisiones informadas, sino que también ayuda a ganar la confianza de las partes interesadas y líderes empresariales.

Algunas métricas sugeridas para Scrum Masters pueden ser:

• Say/Do del equipo (mide lo que se entrega versus lo que se comprometió, ejemplo, en el planning el equipo se compromete con 20 puntos y entrega 16, el Say/Do= 80%)
• Deuda técnica
• NPS (net promote score) del equipo
• NPS del Product Owner
• % de alineación o logro de los objetivos organizacionales que son impactados por el equipo (OKRs o KPIs si es del caso).

Algunas métricas sugeridas para Agile Coaches pueden ser:

• Say/Do del ecosistema de equipos acompañado
• Deuda técnica promedio del ecosistema de equipos acompañado
• NPS del ecosistema de equipos acompañado
• NPS de los Product Owners o Product Managers acompañados
• Impacto en la métricas de negocio del ecosistema de equipos (OKRs o KPIs según el caso)

El Compromiso con el Cambio y la Mejora Continua

Para resolver el dilema de la entrega de valor en la agilidad, los Scrum Masters y Agile Coaches deben comprometerse a hacer una diferencia real. Esto implica no solo seguir un marco ágil, sino centrarse en generar un impacto significativo en la organización. Deben trabajar incansablemente para mejorar la satisfacción del cliente, reducir riesgos, aumentar los ingresos y mantener a los equipos en la búsqueda constante de la excelencia, en lograr ese primer principio para satisfacer al cliente: la entrega tempra y continua de software de calidad y de valor.

Conclusión

La agilidad no se trata solo de seguir procesos y prácticas, sino de crear un cambio significativo en las organizaciones. Los Scrum Masters y Coaches juegan un papel vital en este viaje, y su éxito depende de su capacidad para entregar software de valor y demostrar su impacto. Al abrazar esta responsabilidad y medir constantemente su contribución, pueden ayudar a sus equipos y organizaciones a alcanzar el alto desempeño y la verdadera agilidad, de lo contrario son reemplazables o inútiles para lo que fueron contratados.

En última instancia, la agilidad se trata de generar impacto, y los Scrum Masters y Agile Coaches tienen el poder de hacerlo. La entrega temprana y continua de software con valor es el núcleo de su misión, y al abrazar este principio, pueden llevar a sus equipos y organizaciones hacia un futuro más ágil y exitoso.

Saludos Ágiles, 

Jorge Abad.

Referencias

1. Principios del Manifiesto Ágil.
2. Manifiesto Ágil.
3. Recomiendo ver el vide asociado a este artículo: #RespuestasAgiles ¿Generan o no valor? He ahí el dilema con algunos #AgileCoaches y #ScrumMasters

¿Y qué pasó con la Definition of Ready y la Definition of Done?¿Pasaron de moda?

 

Hola a todos,

Hace rato no escribía, lo cierto es que sigo avanzando en diferentes proyectos con mi gran amigo Lucho Salazar, pero si algunos me siguen asiduamente, saben que continúo compartiendo notas, podcast y videos; pues este aprender y compartir es en doble vía, y siento un deber trabajar con la comunidad ágil para crecer y progresar juntos.

Bueno, quiero compartirles una disfunción que he visto emerger en muchos equipos Scrum y organizaciones ágiles, que uno supondría que está mitigada, pues en ellas se insiste insistentemente en los entrenamientos de Scrum y en los diferentes marcos de escalamiento que lo usan (y que también existe en el mundo Kanban (1)), y que por lo que estoy observando esta siendo ignorada o minimizada su importancia por los Scrum Masters, Facilitadores, Agile Coaches; y como lo "spoilié" con el título del artículo es: el no cumplir con la Definition of Ready (DoR) y la Definition of Done (DoD).

Continuamente en diversos escenarios, Product Owners y gerentes de área se me quejan de que sus equipos scrum no están funcionando, y para entender el contexto hago unas preguntas de rigor, como las del litmus test de la agilidad, y adicional incluyo estas cinco (entre muchas otras según me va llevando la conversación):

1. ¿Tienen Definition of Ready?
2. ¿La están cumpliendo?
3. ¿Tienen Definition of Done?
4. ¿La están cumpliendo?
5. ¿Y cada cuánto actualizan la Definition of Done? 

Siendo estas últimas en las que estoy encontrando mayor reincidencia, y casi todas teniendo como causa raiz la presión del negocio por entregar a como de lugar. Como se pueden imaginar, en estos escenarios de falla y queja, si se incumple en cualquiera de las primeras cuatro preguntas se esta incurriendo en errores de calidad que terminan pagando el producto, el cliente, el equipo y toda la organización, generando retrasos y reprocesos e inconformidad en todos los involucrados en el proceso Scrum; y si se incurre en la última pregunta, se tiene un equipo que no mejora sus estándares con el tiempo y en consecuencia se está desactualizando.

 

A continuación, comparto un listado de consecuencias de fallar en estos cinco aspectos:

Consecuencias de no tener o no cumplir la Definition of Ready

En Scrum, "Definition of Ready" (Definición de Listo) (2) es un criterio utilizado para determinar si un elemento del Backlog del Producto está en un estado adecuado para ser planificado y abordado en una próxima iteración o Sprint. Aunque ni en tradicional, ni en cascada, ni en ágil, Scrum o Kanban, etc., se recomienda trabajar con requisitos inestables o no definidos, pues¡No tiene sentido! ¡Es desperdicio de comienzo a fin!, veamos algunas consecuencias de no contar ni cumplir con la DoR

"Caminar sobre el agua y desarrollar software basado en especificaciones es fácil si ambos están congelados" - Edward V. Berard

• Entregas inconsistentes: El equipo puede encontrarse trabajando en elementos que no están bien preparados, lo que lleva a resultados inconsistentes y posiblemente de baja calidad.
• Ambigüedad en las expectativas: Si los elementos del Backlog del Producto no están claramente definidos antes de comenzar el trabajo, puede haber confusión en cuanto a las expectativas y los criterios de finalización, lo que puede llevar a malentendidos y retrabajos.
• Mayor tiempo de Sprint Planning: La falta de definición puede conducir a discusiones prolongadas durante la planificación del Sprint, ya que el equipo debe aclarar los requisitos y detalles de cada elemento.
• Riesgo de incluir elementos poco relevantes: Si los elementos no están bien definidos, existe la posibilidad de que se planifiquen tareas que no aporten un valor significativo al producto final.
• Acumulación de elementos no terminados: Si el equipo acepta elementos no preparados en el Sprint, existe una mayor probabilidad de que no puedan completarlos dentro del marco de tiempo del Sprint, lo que resulta en elementos no terminados y afecta la capacidad de entrega. Es frecuente ver que el Product Owner resuelve las inconsistencias o dudas durante el sprint y el equipo al estimarlas o trabajar desbordan la capacidad del equipo impactando otros elementos del sprint backlog o incluso el objetivo del sprint..
• Desperdicio de tiempo y esfuerzo: Trabajar en elementos no preparados puede dar lugar a un desperdicio de tiempo y esfuerzo, ya que el equipo podría descubrir problemas o requisitos faltantes durante el Sprint.
• Falta de transparencia: Una Definition of Ready clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado del proyecto.
• Frustración y desmotivación del equipo: Si el equipo se ve constantemente lidiando con elementos mal definidos, esto puede llevar a la frustración y la desmotivación, lo que afecta negativamente la moral y la productividad.
• Frustración de los interesados: Se genera un producto de baja calidad y no se tienen claras las reglas de interacción con el equipo, generando expectativas que no son cumplidas frecuentemente.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum y los interesados trabajen juntos para establecer una Definition of Ready 
• cumplir estrictamente la DoR y actualizarla cuando se observe pertinente.
• que los próximos elementos candidatos a ser sumados al sprint backlog se encuentren correctamente refinados y definidos.
• se realicen sesiones de refinamiento previas a la sprint planning.
• las dependencias con otros componentes sean resueltas y construidas al menos con un sprint de antelación.
• se trabajen en ítems de backlog pequeños (historias de usuario), pues esto permite la fácil identificación de áreas, escenarios, o criterios de aceptación, evitando áreas grises o no resueltas en el sprint planning.
• no incluir historias por presión del negocio que no complan la DoR.

Consecuencias de no tener o no cumplir con la Definition of Done

 La "Definición de Terminado" (3)(4) es un conjunto de criterios acordados que establece cuándo un incremento del producto se considera terminado y listo para ser entregado. Algunas de las consecuencias de no tener o no cumplir con esta definición son las siguientes:

"Cuando algo esta DONE, no me tengo que volver a preocupar de ello" - Alan Cyment

• Entregas de baja calidad: Si el equipo no cumple con los criterios de la "Definición de Terminado", es probable que los incrementos entregados no cumplan con los estándares de calidad requeridos. Esto puede llevar a problemas de funcionamiento, errores y dificultades para el usuario final.
• Acumulación de deuda técnica (6): Si se permite que el equipo entregue incrementos que no están completamente terminados, es probable que se acumule deuda técnica. La deuda técnica representa trabajo adicional que se requerirá más adelante para resolver problemas y mejorar la calidad del producto.
• Retraso en la entrega: La falta de cumplimiento con la "Definición de Terminado" puede llevar a retrasos en la entrega de incrementos completos y funcionales. Esto puede afectar la confianza del cliente y la capacidad del equipo para cumplir con los plazos establecidos.
• Dificultades en la planificación: Si el equipo no puede estimar con precisión el tiempo necesario para completar los incrementos debido a la falta de una "Definición de Terminado" clara, la planificación de futuros Sprints puede volverse complicada y menos confiable.
• Dificultades en la revisión del Sprint: Durante la revisión del Sprint, los incrementos se evalúan para determinar si cumplen con los criterios de la "Definición de Terminado". Si no se cumple, se pueden generar discusiones y conflictos innecesarios entre los interesados.
• Falta de transparencia: Una "Definición de Terminado" clara es esencial para mantener la transparencia en el proceso de desarrollo. Sin ella, puede ser difícil para las partes interesadas y el equipo comprender el progreso y el estado real del producto.
• Desmotivación del equipo: Si el equipo se ve obligado a entregar incrementos que no cumplen con los estándares de calidad, es probable que se sientan desmotivados y frustrados por no poder ofrecer un trabajo de alto nivel.
• Problemas de integración: Incrementos que no cumplen con la "Definición de Terminado" pueden generar problemas de integración con otros componentes del sistema, lo que dificulta el progreso general del desarrollo.
• Desconfianza de los interesados en el equipo y en el proceso Scrum: Al observar que el equipo Scrum no cumple entregando con calidad, se pierde confianza en el equipo y el proceso Scrum.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum adopte y cumpla la DoD de la organización.
• en su defecto, el equipo Scrum la defina y todos responsablemente la promuevan, comenzando por el Scrum Master como agente de cambio.
• no contar como Done, algo que no fue finalizado.
• usar la retrospectiva como fuente de indagación para comprender por qué no se cumplió la DoD.
• por presión de agenda o del negocio, evitar a toda costa declarar como DONE algo que no lo es. 

Consecuencias de no actualizar la Definition of Done

"Entre más maduro y DevOps sea un equipo, más robusta es su Definition of Done" - Jorge Abad

No revisar y mejorar con cierta frecuencia la "Definición de Terminado" como lo sugiere la guía de Scrum puede tener varias consecuencias negativas que afectan al equipo de desarrollo y al producto final a lo largo del tiempo. Aquí están algunas de las consecuencias de no realizar revisiones y mejoras periódicas:

• Estancamiento de la calidad: Si la DoD no se revisa y actualiza regularmente, es probable que la calidad del producto se estanque. Los criterios pueden volverse obsoletos o insuficientes para mantener el nivel de calidad deseado.
• Deuda técnica: La falta de revisión puede conducir a la acumulación gradual de deuda técnica. A medida que el producto se desarrolla sin mejoras en la DoD, es más probable que se tomen atajos y se sacrifique la calidad para cumplir con los plazos, lo que crea deuda técnica que debe abordarse más adelante.
• Mayor incidencia de errores: Si la DoD no se ajusta a las necesidades cambiantes del producto o del cliente, es más probable que se produzcan errores y problemas que afecten negativamente la experiencia del usuario.
• Dificultades en la entrega: Si la DoD no se actualiza para reflejar las nuevas expectativas o requisitos del cliente, el equipo puede tener dificultades para cumplir con las demandas cambiantes del mercado.
• Conflictos con los interesados: Si la DoD no se revisa en función del feedback de los interesados, puede haber conflictos y desacuerdos sobre el nivel de calidad aceptable para el producto.
• Pérdida de transparencia: Si la DoD no se revisa y comunica de manera efectiva, puede haber una falta de transparencia en el proceso de desarrollo, lo que dificulta que los interesados comprendan el estado real del producto.
• Desmotivación del equipo: La falta de revisión y mejora puede llevar a que el equipo se sienta frustrado y desmotivado, ya que pueden enfrentar problemas recurrentes y dificultades para cumplir con los objetivos de calidad.
• Estancamiento en la mejora continua: La revisión y mejora de la DoD son esenciales para la mejora continua del equipo. Sin esta práctica, el equipo puede dejar de buscar oportunidades para optimizar su proceso de desarrollo y entregar un producto de mayor calidad.
• Trabajar en un producto obsoleto: Sin el ejercicio de revisión frecuente de la DoD, se puede incurrir en trabajar en un producto que se va desactualizando y quedando obsoleto con el tiempo.

Para evitar estas consecuencias, se sugiere:

• que el equipo Scrum revise con cierta cadencia su DoD, al menos una vez cada trimestre en una retrospectiva.
• revisar el entorno del mercado (realizar vigilancia tecnológica) para identificar mejoras al producto, prácticas o proceso que deban ser incluidas en la DoD.
• identificar qué prácticas de calidad se encuentran al final del proceso de desarrollo (por ejemplo: prebas especializadas previos a la salida a producción) que puedan ser includias tempranamente (shift-left) para mejorar la velocidaddel equipo y del producto.

Cerrando

Scrum tiene dos puntos de control de calidad clave, que son: la entrada de lo que se quiere construir y la salida o increments; el compromiso del equipo Scrum en hacer cumplir la DoR y la DoD, garantizan la calidad del producto, menos errores, mayor velocidad, más transparencia, menos deuda técnica, mejor satisfacción de todos los involucrados, planeaciones y ejecuciones más efectivas, en consecuencia un mejor Scrum y una entrega de calidad de impacta positivamente la generación de valor.

Deteriorar el cumplimiento de la DoR y la DoD generará, como lo vimos, desconfianza en el producto, el equipo y el proceso; consecuentemente deteriora el entorno de agilidad que se quiere construir.

"Agilidad sin calidad, son incrementos de desperdicio entregados en ciclos cortos" - Jorge Abad

Volver a lo básico e insitir sobre lo esencial, garantizará una mejor agilidad y desempeño de los equipos construyendo productos exitosos.

Saludos ágiles.

Jorge Abad.

Referencias, notas, aclaraciones y comentarios

1. En el mundo Kanban, la Definition of Ready y la Definition of Done conocen como Politicas y consiste en que una tarjeta no mueve hacia la derecha (o en la dirección del flujo) si las políticas no se cumplen.
2. Definition of ready (scrumbook) - https://scrumbook.org/value-stream/product-backlog/definition-of-ready.html
3. Definition of done (scrumbook) - https://scrumbook.org/value-stream/definition-of-done.html
4. Definition of done (Scrum guide)- https://scrumguides.org/scrum-guide.html.
5. Deuda Técnica - http://www.lecciones-aprendidas.info/search/label/deuda%20t%C3%A9cnica
6. Algunos textos acá presentados fueron curados utilizando IA.

El peligroso espejismo de la "Metodología Híbrida" en el mundo del software

Hola a todos

Hace poco tuve tres momentos en donde la metodología o enfoque híbridos de trabajo me los he topado y considero que es valioso escribir y aclarar sobre ellos:

Primer Momento: hablando a cerca del Lean Business Agility Model (LBAM) con el PMI Antioquia, me preguntaban mi opinión sobre el modelo híbrido, en esencia mi respuesta fue:

"Si lo que se está pensando es llevar prácticas de lo tradicional al mundo ágil, esto NO es exitoso, lo contrario sí puede serlo"

Segundo Momento: en varios clientes para los cuales trabajo me están comenzando a decir: "No, no somos ágiles, tenemos una metodología híbrida" y cuando voy a ver, están haciendo proyectos a alcance, tiempo y costo fijo por sprints, sobre lo cual hablaré más adelante.

Tercer Momento: en el reporte de Certiprof Anual - clic aquí -, el cual recomiendo ampliamente pues la mayoría de quienes lo respondemos somos latinos, y cuenta con interesantes hallazgos para nuestra cultura y región; Lucho Salazar y yo opinábamos sobre la aproximación híbrida en la ejecución de proyectos:

CertiProf Agile Adoption Report 2022

"Muchas organizaciones en su acercamiento a la hacia la agilidad han adoptado marcos híbridos, es decir, combinan prácticas ágiles y tradicionales; lo cual es ilustrado en la gráfica. Aunque este enfoque no es la mejor práctica, es un inicio que invita a seguir cambiando, pero si se continua allí puede constituirse en un riesgo a largo plazo, debido a que quienes abrazan la agilidad completamente logran aumentar entre tres a cuatro veces su productividad, tomando una ventaja creciente sobre las híbridas" - Jorge H. Abad L.

---

“Cada día un mayor número de organizaciones están trabajando con un enfoque Agile y Lean. El hecho de que la mitad del estudio los participantes respondieron que usar un enfoque híbrido es natural, dado que la mayoría de las empresas se encuentran actualmente en un proceso de cambiar de las prácticas tradicionales de gestión y ejecución a los basados ​​en el pensamiento ágil. Este es un proceso lento que puede llevar años. Las organizaciones no pueden y no debe comprometerse con un gran cambio o un cambio de "todo o nada", porque primero deben aprender a lidiar con los impactos del cambio y es mejor empezar poco a poco, con una o dos iniciativas. A partir de ahí, a medida que aprenden de las reacciones del entorno, pueden agregar nuevos equipos y áreas de la empresa al proceso. El hecho de que una de cada tres empresas ya esté utilizando un enfoque Agile es consistente con el trabajo que se ha estado haciendo desde la década pasada. Estas empresas han recorrido un largo camino para entender, internalizar, practicar y promover una cultura de colaboración y innovación, pilares esenciales de las organizaciones exitosas de hoy”. - Lucho Salazar

Pero vamos por partes, entendamos el por qué del título de este artículo.

¿Qué es una metodología híbrida?

Inspirado en la "Figure 2-7. Development Approaches del PMBoK 7.0

Un enfoque híbrido, está definido por: "Un enfoque de desarrollo híbrido es una combinación de enfoques adaptativos y predictivos. Esto significa que se utilizan algunos elementos de un enfoque predictivo y otros de un enfoque adaptativo. Este enfoque de desarrollo es útil cuando existe incertidumbre o riesgo en torno a los requisitos. Híbrido también es útil cuando los entregables se pueden modularizar, o cuando hay entregables que pueden ser desarrollados por diferentes equipos de proyecto. Un enfoque híbrido es más adaptativo que un enfoque predictivo, pero menos que un enfoque puramente adaptativo." (1).

Por lo tanto, no es un enfoque donde nos estamos preguntando y validando constantemente "si lo que se está construyendo o entregando es la solución correcta", como ocurre en el mundo del desarrollo de software, pero tampoco se tiene completa certidumbre sobre el resultado final, un ejemplo podría ser el despliegue de un nuevo proceso organizacional, que implique construcción de instalaciones, capacitaciones, desarrollo de software (este software se debe desarrollar con una aproximación ágil) y construcción de máquinas; son varios frentes que se pueden modularizar para entregar valor de forma incremental.

Alguien dirá: ¿Pero en el desarrollo de una solución de software sabemos que módulos vamos a tener? Posiblemente sí, pero el enfoque ágil (adaptativo) te garantiza que no construyas software de desperdicio, y la constante repriorización y refinamiento del backlog, sumado al despliegue continuo de la solución (que te permite su validación) puede significar que se halló valor mucho antes implicando que los supuestos iniciales quedaron obsoletos, pero logrando economias mayores 60% debido a su enfoque basado en Pareto (2).

¿Por qué es un espejismo peligroso en el mundo del desarrollo de software?

Por las siguientes razones:

• Es una zona cómoda: he observado que se denomina híbrido a trabajar en cascada en grandes corporaciones, de forma que ya no es necesario tener al usuario con el equipo, ni es requerido que validen las soluciones. es decir,

el mismo desperdicio de siempre,

requerimientos al inicio, esfuerzo del proveedor, controles de cambio y quejas del cliente porque no entregaron lo que se pidió. Por lo tanto,

 Híbrido es el nombre de la nueva cascada corporativa

Observo que son organizaciones que no aprendieron a trabajar de forma ágil, no saben como hacer ahorros con este enfoque (aún siguen diciendo que ágil es costoso, lo cual es falso), pero para no verse muy anticuadas llamando a su metodología tradicional o cascada, le llaman híbrida, la cual es un desperdicio de tiempo, dinero, y oportunidad de generar valor por donde quiera que se le mire.

• Están poniendo reglas de cascada a proyectos ágiles:  he visto que se llama metodología híbrida al ponerle al desarrollo ágil las reglas de cascada, es decir, alcance, tiempo y costo fijo, pero eso sí, hecho en sprints, pero sin retrospectivas porque no es necesario aprender más ¡Plop! - recomiendo leer la referencia (3)-.

• Se está perdiendo oportunidad de generar y atrapar más valor: las organizaciones al casarse con este modelo híbrido (insisto no veo problema con que sea algo temporal, lo que veo peligroso es que de allí no se evolucione), están perdiendo oportunidad de capturar valor y de generarlo a sus clientes y más temprano que tarde, organizaciones que realmente si ejecuten ágil de forma disciplinada les tomarán una ventaja exponencial, debido a que la agilidad bien practicada cuadruplica la generación de valor y la eficiencia de los equipos.

¿Cómo evitar el espejismo?

Hay varias estrategias que pueden ayudar en evitar el espejismo:

• Comprender en que consiste la mentalidad lean-agile (3).
• Comprometerse a ejecutar los proyectos ágiles (y por ende de desarrollo de software) con las reglas de ágil, de forma que se generen ahorros y altos impactos.
• Si se tiene un proyecto tradicional y quiere volverlo híbrido, identifique posibles módulos, formas de generar valor temprano y retroalimentación valiosa en caso de que aplique; de manera que logre adaptaciones en caso de ser posible.
• No lleve prácticas tradicionales al mundo ágil, es decir, planeación predictiva para el mundo del software, pues estas no van a servir.

Para cerrar, algunas ideas ágiles para el mundo tradicional

Como se ha argumentado en el artículo, llevar prácticas tradicionales al mundo ágil es desperdicio y fricción, pero existen prácticas ágiles que pueden mejorar el mundo tradicional, a continuación, algunas ideas:

• tener dailys de sincronización del equipo de trabajo
• hacer retrospectivas o sesiones de mejora con cadencia de al menos de una vez al mes.
• usar backlogs y priorizarlos constantemente si la naturaleza del proyecto lo permite.
• preguntar y preguntarse constantemente ¿si lo que se hace está generando valor? y corregir en caso de que no.
• Identificar mínimos productos viables y liberarlos incrementalmente: 
• Ejemplo 1: Una casa de campo de forma incremental y adaptativa (pues no se posee todo el dinero), un posible plan de releases puede ser:
• Release 1 o MVP (PMV - Producto mínimo viable): La cocina, el baño, y una habitación para dormir.
• Release 2: otro cuarto
• Release 3: la sala
• Release 4: la piscina
• Release 5, etc, etc.
• Ejemplo 2: Una unidad residencial de 12 torres
• Release 1: torre 1 y 2 
• Release 2: torres 2 y 3
• Release 3: la piscina y el salon social
• Release 4: no se realizó debido a cambios económicos del entorno.

 

Hasta acá este compartir.

Bienvenidos tus comentarios

Saludos ágiles

Jorge Abad.

Referencias, aclaraciones, notas y comentarios

1. A Guide to the Project Management Body of Knowledge PMBOK® GUIDE. Seventh Edition
2. La "Zona de Valor de Negocio". Una reflexión sobre ¿cuándo termina un release en un proyecto Ágil / Scrum? (clic aquí)
3. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? (o ¿Por qué no puedes contratar en alcance, tiempo y costo fíjo un proyecto ágil?) 
4. Esto lo explico ampliamente en el libro: Nuevas Aguas, Nuevos Navíos, Nuevos Navegantes: Business Agility con notas sobre Transformación Digital (clic)

EP73 - La Agilidad ha Muerto, ¡Larga Vida a la Agilidad! con Jorge Abad - Y El 3er Aniversario de Hormigas Agilistas Podcast

Video en facebook aquí.




Artículo: La Agilidad ha Muerto (clic aquí)
_

La Agilidad ha Muerto, ¡Larga Vida a la Agilidad!

Hola a todos.

Ya han pasado los primeros años de lanzamiento de la Agilidad donde:

• la gente no creía en scrum
• no se sabía que había un método Kanban
• las empresas no creían que estuviésemos en tiempos disruptivos y altamente cambiantes
• se exigía predictibilidad en proyectos de software (solo para cuestionarte: ¿aun lo exiges?)
• en las bolsas de empleo no sabían que era un Agile Coach, un Scrum Master, un Product Owner o un ingeniero DevOps
• Los cursos de Scrum Master eran costosísimos

Lindos e inocentes años, no lo niego, tenían la magia del descubrimiento y la novedad.

Hoy la agilidad para muchas empresas ha muerto, pasó por su abismo de desilusión, según el Ciclo de Sobreexpectación de Gartner (1), y es cuando vemos que fracasaron en sus iniciativas de transformación por muchas razones, una de tantas, creyeron que solo era un cambio de procesos y no de mentalidad; llegando al caso de odiar la palabra Ágil o Agilidad; lo anterior es cierto, lo he vivido varias veces, me dicen: "necesitan agilidad pero no les puedes mencionar esa palabra", ni siquiera les gusta decir que sus proyectos son ágiles,  prefieren llamarlos híbridos o que continúan en cascada.

Ciclo de sobreexpectación de Gartner(1)

A otras organizaciones, las encontramos ya sea descendiendo al abismo de desilusión o subiendo en la rampa de consolidación, debido a su ágil mediocre con prácticas como:

• equipos ágiles de 3 personas con 7 proyectos
• equipos ágiles de una sola persona, con varios proyectos también
• Scrum Master con 5 equipos y 10 proyectos
• Product Owners desaparecidos de sus iniciativas
• Product Owners con 5 proyectos
• proyectos ágiles con alcance, tiempo y costo fijo (2) 
• que critican las implementaciones BY THE BOOK (3)
• usan OKRs, a diestra y siniestra, sin un verdadero cambio interno.
• creen que un Scrum Master es un gestor de muchos proyectos
• son expertas en SAFe, LeSS, modelo Spotify, de tribus, pero que arrastran la deuda técnica iteración tras iteración, y exigen una "predictibilidad ágil" que ni cuidan, ni cultivan
• gerentes que sobresaturan el WIP (work in progress) de sus áreas de trabajo y las acusan de lentas
• empresas que no transforman su mentalidad y creen que es hacer lo mismo de siempre, pero con otro nombre.
• personas que asisten a cursos de Scrum + PO + OKr + Workshop de Jira por 50 dólares, por un total de 24 horas.

Estamos en un momento donde hay mucho conocimiento y poca implementación disciplinada, similar a como se encuentran hoy en día en manufactura los que promueven Lean; pues Lean tuvo su boom hace más de 30 años, pero actualmente, muchos se quedan en las prácticas y solo consiguen un 20% a 30% de mejora, pero quienes realmente lo aplican con toda la rigurosidad, amor, filosofía, paciencia alcanzan impactos del 200% al 300% en la productividad; misma promesa que la Agilidad cumple con creces en el mundo del software y el empresarial.

La meseta de la productividad está a la espera de quienes quieran pasar de un "Hacer Ágil" de solo prácticas, un ágil mediocre o un ágil de nombre, a un ágil de mejora continua y alto desempeño, en el que se embarcan quienes quieren vivir un proceso de transformación coherente, consistente, gradual, donde se impacten cultura, formas de trabajo, procesos, tecnología a nivel estratégico, táctico y operativo.

Quisiera terminar como empecé:

La Agilidad ha muerto, ¡larga vida a la Agilidad!

o mejor,

La Agilidad ha muerto, ¡larga vida a la verdadera Agilidad!

Saludos ágiles,

Jorge Abad.

Referencias

1. Ciclo de sobreexpectación (Gartner hype cycle) - https://es.wikipedia.org/wiki/Ciclo_de_sobreexpectaci%C3%B3n
2. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles? http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html
3. Diatriba: "by the book" una frase que me produce escozor - http://www.lecciones-aprendidas.info/2020/01/diatriba-by-book-una-frase-que-me-produce-escozor.html

Hay que Ahorrar Costos, ya Aprendimos Ágil, Volvamos a la Estimaciones

Hola a todos

El COVID19 generó impactos a todo nivel, el primero y más doloroso de todos en vidas irrecuperables, pero adicionalmente continúa golpeando la economía, la forma en que trabajamos, nos reunimos, interactuamos, entre muchos otros. Hoy quiero poner luz en algo que he observado como Líder Regional Ágil dentro de una gran corporación, y es que muchos clientes en diferentes regiones afirman debido a la pandemia de forma más o menos similar: 

"¡Hay que controlar costos, ya aprendimos Ágil, volvamos a las estimaciones!"

 

Es decir, vamos a hacer estimaciones al inicio del proyecto pero ejecutaremos a tiempo, alcance, costo fijos, scrum con sprints fijos y plan de releases inamovible (te recomiendo leer; ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?), esto siempre me recuerda la citada frase de mi gran amigo Lucho Salazar @LuchoSalazarC) "Exigir los compromisos no los garantiza". Lamentablemente, nada más en contra de los propios intereses de la organización, pues pierde la organización y probablemente también lo haga el proveedor, estas son las razones:

• Una estimación buena implica conocer "TODO" desde el inicio, cosa que nunca tendrás, en un mundo tan cambiante como este, considerando adicionalmente la distorsión e inestabilidad que ha generado el COVID19.
• Genera desperdicios al construir producto innecesario que fue pactado a construirse totalmente desde el inicio.
• Genera desperdicios funcionales y técnicos de partes innecesarias.
• Nunca se logran identificar todas las dependencias a priori.
• El plan perfecto no existe, y como lo dice este tweet contestado por Elon Musk con un 100 : "El primer paso de cualquier proyecto es subestimar enormemente su complejidad y dificultad"
• Siempre que hay dependencias externas hay probabilidad alta de fallo, pues las dependencias no siempre están a tiempo.
• Implica que se construye algo que se pactó, así sea que se identifique que no va a generar valor
• Quien estima, extenderá tiempos en búsqueda de cubrir las incertidumbres.
• Entre más grande el proyecto, más grandes las suposiciones, más grandes los riesgos, más grandes "los colchones", mayor costo, y mayor probabilidad de fracaso.
• El enfoque en los costos y en el ahorro, pondrá foco en las áreas de gestión en el ahorro, en la maximización del tiempo comprado y en el cumplimiento estricto de lo pactado en etapas tempranas, pero por lo general (y lo he observado muchas veces), nunca se valida la generación de valor, ni se ve con buenos ojos la adaptabilidad a nuevas circunstancias.

Mi recomendación para estos casos siempre es:

• A nivel de priorización y estimación
• Priorizar las iniciativas con casos de negocio livianos, es decir, la estimación no podemos evitarla, pero no tiene sentido invertir demasiado tiempo en una actividad en la cual más le inviertas, más desperdicio es. 
• Usar como método de priorización de iniciativas del Costo del Retraso dividido por la duración (conocido como CD3 - Cost of Delay Divided by Duration - o WSJF -Weighted Shortest Job First -) (http://www.lecciones-aprendidas.info/2020/09/Un-Ejemplo-Practico-de-Gestion-Lean-Agile-de-Portafolio.html ver diapositivas18,19 y 20)
• Asignar un presupuesto al programa o portafolio de forma que se esten buscando siempre las alternativas de mayor impacto y valor para el negocio.
• Orientar las áreas de gestión a que se cuestione siempre la generación y validación del valor generado sobre el cumplimiento, ya hemos vivido, que cumplir el plan no implica generar valor, solo cumplir y ya. Son innumerables los casos de proyectos que se engavetan o nadie usa usa.
• A nivel de ejecución
• Poner un Product Owner empoderado que:
• priorice por valor
• acompañe al desarrollo
• decida qué construir y qué no sobre el producto
• asegure que se esté construyendo el producto correcto
• Validar constantemente la generación de valor, poniendo en producción versiones del producto, de forma que se identifique si se requiere detener el desarrollo o  perseverar para mejorar los resultados.

En resumen, el costo se controla más construyendo el producto correcto y valioso, que desde la estimación, al menos en el mundo de tecnología y desarrollo de soluciones de software.

Saludos ágiles,

Jorge Abad

Agile Apesta | Ágil Apesta | Agile Sucks

¡Que bueno, atrapé tu atención! Al parecer varios estudios han demostrado nuestra preferencia por las noticias malas y todo aquello escrito en tono negativo es fuente de observación inmediata de nuestra mente, ya sea por instinto de supervivencia o por morbo, es una de las razones por las cuales las redes sociales y los periódicos tienden a volverse más tóxicos -les recomiendo ver las referencias (1)-.

Quiero aprovechar este comportamiento que todos poseemos para compartirte que Agile Apesta o Ágil Apesta o Agile Sucks bajo muchas circunstancias endógenas y exógenas, pues se volvió un objeto de deseo, mas eso no implica que se esté haciendo bien, se asemeja más a un jabón resbaloso que solo se deja atrapar junto a la esquina de la ducha, que a un concepto claramente entendido y dominado por todos.

Ágil según la propuesta de Alistair Cockburn (uno de los firmantes del Manifiesto Ágil) podría resumirse en 4 pilares (que él denomina el Corazon de Ágil - https://heartofagile.com ), todos trabajando a la vez, ninguno más importante que otro, complementándose y ayudándose:

• Entrega de Valor (entiéndase como lo que el cliente quiere y con calidad)
• Reflexión (Inspección y Adaptación)
• Mejora Continua
• Colaboración

Corazón de Ágil por Alistair Cockburn (2)

Cuando alguno de estos elementos falta o está mal concebido, lo que llamamos ágil, apesta y generará más problemas que soluciones.

A continuación te comparto un breve listado que he identificado cuándo Ágil Apesta y mucho.

Ágil apesta cuando:

• Exógenas a los equipos ágiles
• cuando es contratado con alcance tiempo y costo fijo (clic aquí)
• la PMO hace seguimiento tradicional a un enfoque ágil 
• a la empresa no le gusta la transparencia y "mata" al mensajero que trae las malas noticias, de que las cosas no funcionan
• la empresa dice que no necesita acompañamiento y cree que con dos días de entrenamiento de sus gerentes de proyecto es suficiente
• la empresa cree que es solo ponerle a los Gerentes de proyecto el rol de Scrum Masters, y a los Business Analyst el rol de Product Owners.
• la empresa cree que será ágil en 3 meses y exige un plan para hacerlo 
• cuando la alta dirección no está involucrada y delega el cambio 
• a las personas les siguen diciendo recursos 
• no se exige excelencia técnica, ni internamente ni a proveedores
• no se remueve la deuda técnica.
• tenemos a los equipos bajo presión y les imponemos lo que deben entregar y cuándo deben hacerlo 
• cuando creemos que sabemos más que el Agile Coach o el Scrum Master con experiencia y no se siguen sus recomendaciones
• cuando no dejamos madurar los pilotos ágiles (al parecer 6 meses es una buena métrica para empezar)
• Cuando mi jefe dice que es ágil pero no le puedo dar feedback, ni le puedo sugerir cosas.
• Endógenas a equipos ágiles
• no se entrega valor al cliente de forma temprana y continua
• no existe excelencia técnica 
• el alcance está fijo 
• no se reflexiona, es decir, no se hace inspección y adaptación.
• cuando tienes soluciones ahogadas en deuda técnica
• cuando no usas DevOps
• cuando la mejora continua se enfoca únicamente en los procesos y las personas y no se enfoca en resolver los problemas técnicos (clic aquí)
• Endógenas a Scrum 
• el 50% de los equipos Scrum apestan (se lo vi decir a Jeff Sutherland, pues no son capaces de generar valor y de lograr un desempeño del 400% - promesa cumplida por Scrum una y otra vez) 
• las historias de usuario demoran dos o más sprints en ser construidas y nos olvidamos que a lo sumo deben tomarnos entre 2 a 4 días en construirse totalmente, es decir, con pruebas y despliegue incluido.
• se tienen Scrum Masters (SM) con 3 equipos (lo mejor, es un SM por equipo, lo menos peor es un SM con 2 equipos, la pésima práctica un SM con 3 o más equipos, pues no alcanza a mejorar nada, solo corre de un lado para otro haciendo reuniones) 
• se tienen Product Owners con 2 equipos (la verdad, debería ser a lo sumo uno solo, 2 es demasiado riesgoso, y le resta foco en el producto que construye) 
• el SM solo se dedica a agendar reuniones 
• cuando el PO no va a los eventos
•  el PO no hace refinamiento y se convierte en un PO reactivo que solo trabaja para el siguiente sprint, debiendo estar avanzando en 2 a 3 sprints adelante
• el SM no enseña Scrum al PO o al Equipo y como hacerlo cada vez mejor
• el PO no se deja enseñar por el SM
• cuando creemos que 5 sprints mejorarán técnicamente a un equipo de inexpertos (nunca pasará)
• no hay retrospectivas, porque no agregan valor
• las retrospectivas no abordan temas técnicos (clic aquí)
• no hay dailys 
• no hay planning, solo trabajo impuesto a realizar por el equipo de forma cíclica
• tienes un equipo con varios proyectos (multitasking) y lo llamas equipo 
• existen equipos que los llaman células y son unicelulares (equipos de una persona - OMG, lo he visto varias veces)
• las pruebas son hechas por otro equipo diferente al que construye el producto, y en el sprint subsiguiente (casca-agile)
• el equipo no es multidisciplinario 
• el Product Backlog no está priorizado por valor 
• existe un product Backlog con un solo release y un MVP, o sea, sino se sale a producción con todo el sistema o producto, este no sirve 
• el PO no tiene autoridad sobre el producto 
• el PO es el jefe del equipo y no se le puede dar feedback 
• el SM es el jefe del equipo y no se le puede dar feedback 
• dentro del equipo hay subequipos 
• no existe incremento de valor potencialmente entregable al final de cada sprint
• dentro del equipo hay rangos y jerarquías (cosa que va en contra de la guía de Scrum)
• ni el SM, ni el PO, y el Team son orientados a resultados
• el SM no reta al equipo, ni le ayuda en su proceso de mejora continua
• no hay verdaderos profesionales haciendo parte del equipo Scrum
• En la comunidad ágil
• cuando los líderes de la propia comunidad lo atacan, en vez de avanzar de forma propositiva 
• cuando las conferencias se quedan sin feedback, y la falta de validación de expertos hace que se acepte todo, que todo valga, pero la verdad no todo vale, y algunas conferencias terminan perdiendo valor. 
• cuando dejamos que otros se hagan cargo, y solo caemos en el terreno de la crítica y no construimos responsablemente 
• cuando no vemos en la crítica de los otros una oportunidad de mejora 
• cuando dejamos que los líderes tóxicos prosperen y no compartimos los éxitos y las buenas prácticas
• cuando criticamos los eventos y los speakers, pero no vamos, ni nos proponemos como speakers
• cuando alguien que recibe un entrenamiento de 2 a 4 días es nombrado Master, Consultant, Coach y no hay validación de la práctica. 
• cuando quienes toman los entrenamientos creen que pueden dictarlo al día después 
• cuando como miembro un equipo ágil dejas de estudiar y aprender y buscar tu propia excelencia y reinvención.
• cuando no te conectas con la comunidad
• cuando es más importante la foto y llenar las redes sociales del entrenamiento, que la generacion de valor en el cliente y en el equipo
• cuando nos atacamos en vez de construir 
• cuando los que no entienden los marcos ágiles
• los critican sin conocerlos o haberlos usado
• cuando critican la forma (ej: los posit o dinámicas), pero no validan el fondo
• juzgan por las fotos, pero realmente no saben toda la movilización y cambios que están ocurriendo al interior del equipo o de la organización
• cuando los que creen entender los marcos ágiles
• empapelan de posit a la organización pero no generan valor 
• leen un libro o un post salen a vender entrenamientos sin entender, comprender y validar lo leído 
• instalan Jira pero no generan valor
• tienen un pipeline de DevOps pero el negocio no prioriza por valor, ni valida las hipótesis de los incrementos o releases que va lanzando al mercado, haciendo desperdicio ágil.
• confunden felicidad con esoterismo o chamanismo 
• confunden compromiso con explotación 
• comparten información que no está respaldada por datos o experiencias (al menos propias)
• ponen primero la felicidad que la generación de valor, el mensaje es diferente, los equipos felices o que tienen bienestar son más productivos.(https://hbr.org/2011/06/the-happiness-dividend) (aporte de Fabian Schwartz)
• comparten jubilosamente fracasos ágiles, pero no comparten el contexto y se les olvida que en cascada el factor de falla es mucho más alto. Pero para ser claros, es muy probable que dentro de las causa raíz de esos fracasos se encuentren algunos de los elementos enunciados en este post.  
• cuando cualquiera del ecosistema ágil, personas como usted o como yo, no elevamos o exigimos el estándar, no compartimos el riesgo o consecuencias de las malas implementaciones y somos complacientes con esas personas que desde su paradigma no lo entienden, o desde su esquema de poder no quieren que sea exitoso, y permitimos el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido.

Bien dice Sutherland, el peor enemigo de Scrum es un mal Scrum

Referencia (3)

parafraseánndolo un poco,

El peor enemigo de Ágil es un mal Ágil o si lo desean El peor enemigo de Agile es un mal Agile o también Agile's worst enemy is a bad Agile

Hagámonos cargo 

• No llamemos Ágil a lo que no lo es.
• No llamemos Scrum a lo que no lo es.
• Exijamos excelencia técnica de los equipos de desarrollo (tanto internos como de proveedores)
• Midamos y ataquemos la deuda técnica
• Si vamos a criticar un marco o framework ágil, hagámoslo desde la experiencia o desde el minucioso estudio.
• Valida lo que dice el autor, o entrenador que te acompaña, pídele datos y referencias.
• En las redes sociales no promuevas gente tóxica, por la razón que: "de vez en cuando dice algo bueno", pues terminarás aprobando su discurso tóxico, poco constructivo y poco empoderado.
• No confundas posición crítica, con una posición tóxica, la primera llama a la acción, la segunda destila veneno, señala lo malo y no propone acciones. 
• Hazte acompañar de expertos.
• Si vas a hacer Scrum al menos sigue la guía oficial de Scrum (el SBOK no es Scrum) 
• No caigas en el "borregismo", es decir, seguir a alguien sin objetar lo que dice (como borregos, o un cardúmen), todos erramos y todos tenemos oportunidades de mejora 
• Criticas porque otros critican, pero no compruebas nada de lo que afirman
• No te quedes con lo que te dicen, investiga, valida, busca datos
• Ten una actitud de continuo aprendizaje
• No seas complaciente con el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido, identifica disfunciones, corrígelas y exígelas.

Hasta acá este desahogo o diatriba.

Vamos juntos, vamos por más.

Bienvenidos sus comentarios y observaciones.

Saludos ágiles

Jorge Abad

Aclaraciones, Comentarios, Referencias y Notas 

1. links que apoyan esta afirmación
• Las noticias positivas están pidiendo primera plana
• Efecto de las malas noticias en el cerebro humano
• Consumer Demand for Cynical and Negative News Frames - Marc Trussler, Stuart Soroka, 2014
• ¿Por qué las malas noticias abundan más en los medios de comunicación?
• Psychology: Why bad news dominates the headlines
2. https://heartofagile.com/
3. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/

Diatriba: "by the book" una frase que me produce escozor

Hola a todos

Como algunos de ustedes saben, la mayoría de post los escribo tienen como objeto de dejar registro de mis experiencias y luego remitir a mis compañeros, jefes, estudiantes, y amigos,  a mi blog con miras a hacer reutilización del conocimiento,  gastar menos energía y de paso hacer un aporte a la comunidad.

Hoy quiero desahogarme, hacer un poco de catarsis, respecto a esta frase "BY THE BOOK",que me he encontrado en varias latitudes en este ejercicio de acompañar equipos y organizaciones. Por lo general, sson variaciones de las frases que han antepuesto a "by de book", veamos:

• tus scrum masters son "by the book"
• los equipos de transformación de ustedes son"by the book"
• lo que ustedes me estan proponiendo es"by the book"
• ese aseguramiento o assessment es "by the book"
• tus agile coaches son "by the book"
• tus consultores son "by the book"

y en el sentido estricto de la palabra voy a indagar,  el comentario no tiene nada de constructivo ni realista, la mayoría de las veces:

• su mensaje principal respecto a nostoros "no sabemos que estamos haciendo", o "sabemos muy poco" (ese mensaje por lo general lo da la competencia)
• su intención de plano es destructiva
• busca garantizar de que no se hagan cambios o el "statu quo" (sí, es sin la "s" al final de statu)
• su intención en la mayoria de los casos es :
• mostrar desconfianza, 
• generar descofianza, 
• destruir y desacreditar cualquier observación que se haga
• atacarme o atacar a "mi gente" por parte de la competencia:
• que no entiende el proceso 
• o que si lo entiende pero no le conviene que se hagan observaciones sobre su trabajo

Hagamos precisiones

Respecto a “saber poco”: cuando esto ocurre, somos profesionales y se lo aclaramos al cliente y conjuntamente decidimos acoger el riesgo. En tecnología siempre hay conocimiento nuevo. Sin embargo, cuando se va a indagar o a validar algo relacionado con las prácticas ágiles que lleva un equipo interno o externo, cosa a todas luces necesaria pues siempre queremos saber qué tan “correcto” lo estamos haciendo, lo primero que se pregunta es:

¿qué marco de trabajo siguen?

o ¿qué marco le han dicho al cliente que siguen?

y desde esa luz que los equipos mismos dan, se comienza a identificar si realmente eso que dicen ejecutar lo están haciendo y en qué nivel de "shu-ha-ri"(ver imagen) se encuentran.

"

Un ejemplo del "ataque" que comunmente recibimos, son de las personas, equipos u organizaciones que hacen el "scrumbut"(3):

• hacemos scrum pero no hacemos retrospectiva
• hacemos scrum pero no tenemos definition of done
• hacemos scrum pero no hacemos pruebas
• hacemos scrum pero el sprint backlog no esta definido
• hacemos scrum pero no hacemos planning
• hacemos scrum pero no tenemos review

todos esos scrumbut, o scrum pero, realmente implica que NO se está haciendo haciendo scrum, con razon dice la frase, que aparece en la misma guía oficial:

"scrum es liviano, fácil de entender, dificil de dominar"(2)

para terminar los dejo con dos interesantes recursos:

• la lista de chequeo de scrum elaborada por Henrik Kniberg (3) y traducida por migran amigo Lucho Salazar (4) (que justo comienza validando con lo esencial - validando si se está en nivel "ha" o "ri", que es entregar software de valor de manera frecuente y tener u proceso de mejora continua y luego se va a la validación de marco)

• y la leyes de Compartamiento Organizacional de Larman(5) traducidas por Hiroshi Hiromoto(6)

1. Las organizaciones están implícitamente optimizadas para evitar el cambio del statu quo de las posiciones y estructuras de poder de los mandos medios y de primera línea y de “especialistas”. 2. Como corolario de (1), cualquier iniciativa de cambio será reducida a redefinir o sobrecargar la nueva terminología para que signifique básicamente lo mismo que el statu quo. 3. Como corolario de (1), cualquier iniciativa de cambio será ridiculizada como “purista”, “teórica”, “revolucionaria”, “religión”,"BY THE BOOK"(7), y “necesitada de una customización pragmática para preocupaciones locales” — que desvía de atender las debilidades y el statu quo del manager/especialista. 4. Como corolario de (1), si luego del cambiar el cambio algunos managers o especialistas son desplazados, ellos se convierten en “coaches/entrenadores” para el cambio, frecuentemente reforzando (2) y (3). 5. La cultura sigue a la estructura (Culture follows structure)

Por lo tanto, si eres cliente, o proveedor y alguien se te acerca con el 

"BY THE BOOK"

en su discurso, te sugiero revises:

• si es un sesgo cognitivo (o prejuicio que llamábamos hace un tiempo)
• realmente no se tiene conocimiento y es una primera aproximación (esto se resuelve validando experiencias previas en otras organizaciones y contextos)
• realmente estan evaluando el nivel  "SHU" o aprendiz de algo o alguien, y lo primero que se valida es si sigue las reglas minimas
• o es una maniobra de "alguien" para destruir la confianza en la estrategia o en una persona, equipo u empresa y salvar su propio pellejo.

Hasta aca esta diatriba, y desahogo

saludos ágiles

Jorge Abad

Notas, aclaraciones, comentarios

1. https://www.scrum.org/resources/what-scrumbut
2. https://www.scrumguides.org/scrum-guide.html o https://www.scrumguides.org/download.html
3. www.crisp.se/scrum/checklist
4. http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html
5. https://www.craiglarman.com/wiki/index.php?title=Larman%27s_Laws_of_Organizational_Behavior
6. https://medium.com/scrumorganico/las-leyes-de-larman-sobre-comportamiento-organizacional-a9f8a1ec127f
7. "BY THE BOOK", Lo adicioné intencionalmente, pues significa lo mismo