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) |
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.
 |
| 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
- 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
- https://heartofagile.com/
- https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
