La comunidad Ágil abraza una fantasía inviable

by Cliff Berg

Soy un agilista. La empresa que cofundé en 1995, con casi 200 empleados en el año 2000, adoptó eXtreme Programming (XP) ese año. Mi libro de 2005 High-Assurance Design interpretó prácticas de ingeniería seguras y de alta confiabilidad en un contexto ágil, proponiendo una respuesta concreta a la pregunta: «¿Cómo pueden las organizaciones construir sistemas altamente confiables y seguros utilizando métodos ágiles?» Desde entonces, he ayudado a más de diez grandes organizaciones a pasar a enfoques Agile y DevOps.

Pero la comunidad ágil está muy descarrilada. Le enseña a la gente un modelo ideal que no funciona. Este modelo es como un becerro sagrado: sus elementos son discutidos por los entrenadores ágiles como si fueran obviedades. Uno lo desafía con gran peligro: si uno habla en contra del modelo, puede ser etiquetado como un «escéptico ágil», o alguien que «no es realmente ágil», una marca de muerte en la comunidad ágil. La comunidad ágil ha sido históricamente de mente muy cerrada y no ha podido debatir ideas ágiles de una manera sana y de mente abierta. Mi editor de Pearson lo describió como «insular». Fue DevOps el que irrumpió por las puertas de Agile y humilló a la comunidad para que aceptara un debate más abierto.

De hecho, escribir sobre esto siempre es un riesgo personal para mí: aquellos que no estén de acuerdo se referirán a mí como “ese tipo anti-ágil”. Lo sé porque ha sucedido. Sin embargo, están equivocados: fui uno de los primeros en adoptar Agile y estoy totalmente comprometido con las ideas centrales de Agile; y he tenido un éxito inmenso en la implementación de Agile, pero no de la manera típica de adoptar prácticas ágiles estándar listas para usa

Mi enfoque es más un enfoque de DevOps: mirar siempre la singularidad de cada situación y considerarla como un sistema : considerar qué cambios de comportamiento lograrán el objetivo comercial, si es un tiempo de comercialización más corto y la construcción de las cosas correctas , o más. calidad y construcción de cosas en las que se puede confiar para que funcionen . Siempre empiezo desde la perspectiva de un impulsor de negocios y me baso en ideas ágiles, ideas Lean, ideas de terapia conductual y muchas otras, en lugar de intentar encajar a la fuerza el modelo idealista del becerro sagrado en cada situación.
Veamos qué es el modelo de becerro sagrado ágil.

Si uno toma un curso de capacitación en «conceptos básicos» ágiles, se le enseñará el Manifiesto Ágil, un documento brillante y atemporal, pero luego se le enseñará el proceso Scrum, aunque se puede decir que Kanban se adapta mucho mejor a los métodos DevOps actuales. Además, se le contarán las siguientes falsedades:

1. Los equipos autónomos autoorganizados son la mejor manera de organizar a los programadores.
2. Los gerentes son un «anti-patrón»; idealmente no debería haber jerarquía, y nadie debería tener autoridad explícita. Toda autoridad y todos los líderes deben surgir a través de la autoorganización.
3. Ningún individuo debe rendir cuentas: solo equipos enteros deben rendir cuentas.
4. El fracaso es la mejor forma de aprender.
5. Uno siempre debe confiar en el equipo, incluso si nunca antes ha trabajado con él.
6. Todos los equipos de desarrollo deben ser equipos de funciones que trabajen en todo el conjunto de pilas de tecnología del producto.
7. Cualquiera debería poder trabajar en cualquier cosa.
8. Una sala de equipo abierta es el mejor arreglo para que las personas puedan colaborar más fácilmente y se beneficien de la comunicación «osmótica».
9. Más colaboración siempre es mejor y la comunicación verbal siempre es mejor.

El Manifiesto Ágil no dice ninguna de estas cosas. Déjame repetir eso:

El Manifiesto Ágil no dice ninguna de las nueve cosas de la lista.

Si bien el Manifiesto menciona elementos de algunas de estas cosas, nunca dice “haz solo esto” o “haz siempre aquello”. Casi todas las declaraciones del Manifiesto Ágil están escritas para implicar una compensación, de modo que uno pueda decidir qué enfoque es mejor para una situación.

Los nueve axiomas anteriores forman un modelo que la mayoría de la comunidad ágil toma como cierto, a pesar de la gran cantidad de evidencia de que el modelo es incorrecto. Las personas que realmente entienden Agile no hacen las nueve afirmaciones absolutistas anteriores, pero esas personas son un pequeño porcentaje, y saben que no deben criticar abiertamente el modelo del becerro sagrado, a menos que estén hablando en privado con alguien que realmente entienda Agile.

Abundan los libros que desacreditan el modelo anterior, aunque lo hacen de una manera cuidadosa y políticamente correcta, dando vueltas alrededor del modelo y afirmando, en cambio, que es necesario “aumentar” las prácticas ágiles típicas. Uno reciente es Repensar lo ágil: por qué los equipos ágiles no tienen nada que ver con la agilidad empresarial , de Klaus Leopold. En ese libro, Leopold conecta de manera experta los puntos en las brechas de liderazgo que tienden a existir en las organizaciones que crean equipos autónomos autoorganizados y luego esperan que, como resultado, sean ágiles.

A pesar del título que llama la atención, el libro no critica directamente el modelo Agile de nueve axiomas, sino que muestra cómo la adopción de ese modelo por las organizaciones deja enormes lagunas, y Leopold explica cómo llenar esas lagunas.

Los agilistas (incluyéndome a mí) se apresuran a señalar que uno no puede simplemente «insertar» Scrum o equipos autoorganizados: hay que «cambiar la cultura de la organización». Pero ¿qué significa eso? Las mismas personas que respaldan las nueve prescripciones anteriores rara vez tienen una buena respuesta sobre lo que significa un cambio de cultura. Dicen tópicos como, «Uno debe hacer que los gerentes acepten el fracaso» y «La organización necesita aprender a experimentar».

Bien, pero ese tipo de consejo es demasiado vago, y un consejo abstracto que termina en un tópico me dice que alguien realmente no sabe de lo que está hablando, que aprendió algo en un libro pero que en realidad no ha resuelto ese problema.

He ayudado a más de diez organizaciones a “volverse ágiles” o “ir a DevOps”, y he visto todas las permutaciones de esto. También he visto patrones comunes que suelen estar presentes. Estos son:

1. Las organizaciones mantienen sus métodos existentes de investigación de mercado y definición de productos, que tienen un tiempo de espera prolongado y que «traspasan» los requisitos del producto a «TI» para su construcción.
2. Las organizaciones desmantelan el liderazgo de nivel de programa o de producto de estilo antiguo, pero no lo reemplazan con un equivalente ágil.
3. Las organizaciones intentan “implementar” Agile, tratándolo como un cambio de proceso, cuando en realidad es principalmente un viaje de aprendizaje.
4. Las organizaciones no ponen suficiente énfasis en el aspecto técnico de Agile, que hoy es «DevOps»

Muchas organizaciones intentan «implementar» Agile adoptando SAFe, o alguna variación de eso. En realidad, esto ayuda un poco porque llena algunos vacíos relacionados con el elemento B anterior, y posiblemente incluso afecte a A, aunque eso es menos común. Pero el enorme ejercicio de planificación del Incremento de Producto que prescribe SAFe es innecesario, en mi opinión.

Las mayores brechas de liderazgo que veo normalmente pertenecen al liderazgo técnico . Las organizaciones pueden adoptar un proceso de «cartera ajustada» (que recomienda SAFe) y una estructura de «tren de lanzamiento» de productos, pero no logran abordar cómo se integran los muchos componentes de su producto. Desmantelan su enfoque tradicional de tener un equipo de control de calidad separado que se enfoca en las «pruebas de integración del sistema», pero no lo reemplazan con un equivalente Agile y DevOps, que idealmente son pruebas de integración automatizadas a pedido basadas en cadencia frecuentes, respaldadas por » prueba de integración local «shift-left».

A menudo ponen a un gerente de desarrollo a cargo de los equipos de producto, pero el gerente ha escuchado el mensaje de que los equipos deben ser «autoorganizados y autónomos», por lo que no interviene y proporciona el liderazgo que se necesita. El resultado es que los equipos tienden a operar de manera muy independiente y no logran abordar adecuadamente la integración entre equipos. El modelo del becerro sagrado es entonces la causa directa de la disfunción resultante.

Los métodos ágiles incluyen tener retrospectivas regulares, y la mayoría de las organizaciones lo hacen a nivel de equipo porque Scrum lo prescribe, pero fallan en instituirlo a nivel de producto o programa. Agilsts señalará que este es un síntoma de “no tener una cultura ágil”, porque una cultura ágil seguramente pensaría en tener retrospectivas en todos los niveles. Pero cuando una organización está tratando de adoptar métodos ágiles, no pueden mágicamente «convertirse en una cultura ágil». Necesitan orientación sobre qué prácticas instalar. Con el tiempo, esas prácticas fomentarán un pensamiento más ágil, pero ese cambio de pensamiento llevará mucho tiempo.

Y aquí es donde la comunidad ágil, en general, se confunde: la afirmación es que las organizaciones deben cambiar su cultura para ser ágiles. Sin embargo, la realidad es que para cambiar la cultura de una organización, primero se debe cambiar el comportamiento, no al revés . El cambio de cultura sigue al cambio de comportamiento, y si el cambio de comportamiento se mantiene durante el tiempo suficiente, el cambio se vuelve autosostenible y se convierte en la nueva cultura. (En la comunidad de terapia conductual, este ciclo de vida de cambio se describe mediante el » modelo transteórico «).

En otras palabras, no es razonable esperar que las organizaciones propongan enfoques ágiles simplemente aprendiendo el Manifiesto Ágil: necesitan ayuda para definir nuevos procesos y prácticas, que con el tiempo se convertirán en la nueva normalidad; y en el curso de esos cambios de comportamiento, necesitan agilistas para interpretar los cambios por ellos, para ayudarlos a ver los cambios de comportamiento a través de una lente ágil; de esa manera, su pensamiento comienza a cambiar. Pero los cambios de comportamiento deben ser lo primero. La gente va de lo concreto a lo abstracto, no de lo abstracto a lo concreto.

Por lo tanto, es culpa de la comunidad Agile por popularizar el modelo demasiado simple de equipos autónomos y no ayudar a las organizaciones a anticipar todos los nuevos procesos y prácticas que necesitarán para que esos equipos trabajen juntos. Decirles que deberían tener una colección de equipos autoorganizados y que deberían «empezar a pensar en Agile» no es suficiente. Los equipos necesitan métodos explícitos para organizar su comportamiento colectivo: no se auto organizarán adecuadamente en torno a un producto o flujo de valor, y la mayoría de los gerentes de desarrollo no sabrán cómo estimular el nivel requerido de colaboración entre equipos: retrocederán y observarán, y espere que los equipos comiencen a colaborar mágicamente, porque así es como se les ha dicho que Agile funciona, pero no sucede.

El hecho de no tener retrospectivas a nivel de producto o programa bloquea las mejoras que Agile podría traer: el tiempo de ciclo de las características del producto no se puede reducir sustancialmente, ni tampoco la tasa de defectos del producto que se escapan, a menos que uno se enfoque en la mejora de un extremo a otro, que abarque el muchos equipos de un producto o flujo de valor.

La mejora de los equipos individuales no desbloqueará los beneficios de Agile. Y los entrenadores ágiles, que tienden a no ser técnicos, evitan discutir problemas técnicos durante las retrospectivas, así que no confíe en ellos para ayudarlo a mejorar su flujo técnico de extremo a extremo. Le dirán que necesita identificar dependencias y reducir su «WIP», pero no tendrán ninguna idea sobre cómo administrar las dependencias para que la integración ocurra con frecuencia y las pruebas en todos los niveles de integración sean suficientes. (Consulte este artículo sobre gestión de dependencias y esta serie de artículos sobre la definición de una estrategia de prueba). Tampoco la mayoría de los equipos conocen las prácticas de CI / CD que se necesitan para una integración rápida; no saben lo que no saben: por lo tanto, el adagio «confíe en el equipo» no tiene en cuenta la La mentoría de DevOps que necesitan los equipos.

El hecho es que alguien debe ser responsable del flujo técnico a nivel de producto. De lo contrario, no existe un liderazgo a nivel de producto en cosas como las pruebas de extremo a extremo. El estilo de liderazgo debe ser un liderazgo de servicio, de modo que sea colaborativo y habilitador, no autocrático y basado en el miedo. Pero alguien debe tener el ojo en esa bola todo el tiempo: los problemas del nivel de integración que surgen son complejos y numerosos, y bloquearán por completo una mejora sustancial si no los aborda.

Una persona que tiene responsabilidad necesita tener autoridad real: la rendición de cuentas sin autoridad es una situación terrible en la que estar. Pero un líder servidor no ejercerá su autoridad la mayor parte del tiempo: la guardará para raras ocasiones en las que necesita tomar una decisión. sobre algo que no se puede resolver de forma colaborativa, como la necesidad de reorganizar algunos equipos. El resto del tiempo, están atentos a las cosas que se están desmoronando y se aseguran de que los problemas se discutan y resuelvan, principalmente haciendo preguntas y sugerencias, pero a veces, con suerte rara vez, insistiendo en que se aborde algo. y pedirle al equipo que confíe en la otra dirección.

¡Hasta aquí la falsedad de que uno debería tener equipos autónomos y autoorganizados! Lo que los equipos necesitan es liderazgo de servicio, en todos los niveles: el nivel del equipo, el nivel del producto y el nivel del programa o flujo de valor.

Luego está la afirmación de los agilistas de que el fracaso es la mejor manera de aprender. A nadie le gusta fallar . Un mercado que se enfrenta a una falla nunca es algo bueno. La idea de «fallar temprano, fallar a menudo» se refiere a experimentos controlados, que podrían estar orientados al mercado si es necesario. SpaceX utiliza la técnica de «fallar temprano, fallar a menudo»: construyen muchos motores de cohetes y los ejecutan hasta fallar, para aprender cómo fallan. Incluso lo hacen con cohetes enteros. ¡Pero lo último que quieren es un fracaso durante una misión!

En lugar del engañoso «fracasar temprano, fracasar a menudo», la máxima debería ser, «prueba cosas, experimenta mucho y espera que muchos experimentos fracasen, de esa manera aprenderás y no fallarás cuando sea necesario».

Los otros elementos de la lista de nueve falsedades ágiles se pueden resumir como extremos que contienen buenas ideas pero que generalmente no funcionan en su forma extrema, la forma que generalmente se explica durante un curso de «Conceptos básicos ágiles» y que es defendida por un gran porcentaje de entrenadores ágiles.

¿Autoorganización? Seguro, hasta cierto punto, pero es mejor tener un verdadero líder servidor que pueda ayudar al equipo a organizarse y a tener discusiones dialécticas de alta calidad. ¿Cualquiera puede trabajar en cualquier cosa? Tal vez, pero a veces los microservicios centrales críticos para el negocio deben ser mantenidos por un solo equipo para garantizar la cohesión de su diseño. ¿Sala de equipo abierta? A nadie parece gustarle eso, pero tal vez el formato de «cafetería» sea un buen compromiso, por lo que cerramos el círculo con la vieja idea de «cuevas y bienes comunes». ¿La comunicación en persona es siempre la mejor? Para cosas simples, sí, pero para cuestiones muy complejas, algunas personas se comunican mejor escribiendo primero sus pensamientos: eso es una cuestión de personalidad.

Etcétera.

Los extremos no funcionan, excepto en circunstancias extremas. La mayoría de las organizaciones no se encuentran en circunstancias extremas. El Manifiesto Ágil trataba sobre el equilibrio y el juicio, no sobre los extremos. Aquellos que enseñan las nueve falsedades no entienden realmente Agile: son Agilistas de culto a la carga. Todas esas nueve ideas son variantes extremas de buenas ideas, pero los extremos no tienen ningún sentido la mayor parte del tiempo.

Cada una de las nueve máximas debe enseñarse como una idea a considerar, y nada más, con la precaución de que el enfoque correcto depende de la situación.

Es hora de desmantelar el modelo ideal falso de extremos que se está enseñando en los cursos de Agile Basics y que en realidad no funciona, y devolver el juicio y la realidad a Agile