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 fracazos ágiles, pero no comparten el contexto y se les olvida que en cascada el factor de fracaso es mucho más alto
• 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)

Hagámonos cargo