¡“Agile” no tuvo la culpa!

Creado por: Michael Lambert

Traducido por: rick@oncedev.com

https://www.linkedin.com/pulse/agile-didnt-do-michael-lambert

Publicado el 3 de agosto de 2019

El otro día, David Dombkins respondió a un comentario de Rajesh Mathur indicando lo siguiente:

Totalmente de acuerdo, Agile no es una bala [plateada] y no es adecuada para más del 96% de las organizaciones. Agile ha matado a miles de personas debido a su [falta] de estándares, cumplimiento, [débiles] T&E (Prueba & Evaluación por sus siglas en inglés) y productos mínimamente suficientes.

Luego señaló que:

Los informes sobre Boeing claramente culpan a Agile. En Australia, la agencia de prestación de servicios del gobierno con su proceso de recuperación [Robodebt] está acusada [de más de] 2000 muertes. El proceso Agile ofrece resultados [mínimos] suficientes que no están sujetos a los estándares y tienen un T&E poco confiables. Ya es hora de que los riesgos de Agile se hagan públicos. Agile es, al final, una metodología de reducción de costos / maximización de beneficios que consiste en envolver en papel de regalo la innovación falsa y el manejo del presupuesto.

Estoy totalmente en desacuerdo con esto y dije que Agile se está utilizando como un "chivo expiatorio conveniente" en estas situaciones. Este es mi lado del argumento. Recomiendo a cualquiera que no esté de acuerdo conmigo que publique una respuesta breve en los comentarios, o que escriba un artículo que indique sus puntos de vista. Estoy más que feliz de que cites cualquiera de mis argumentos como parte de tu respuesta a esto.

Para comenzar, repasemos el Manifiesto Agile. El Manifiesto Agile establece 4 valores:

• Individuos e interacciones sobre procesos y herramientas;

• Software funcionando sobre documentación extensiva;

• Colaboración con el cliente sobre negociación contractual;

• Respuesta ante el cambio sobre seguir un plan.

También he visto mencionar un Manifiesto Agile 2.1; Aunque no creo que haya mucha tracción para la versión 2, y mucho menos una versión 2.1, para aquellos que creen en este movimiento, los valores revisados son:

• Trabajo en equipo y responsabilidad sobre individuos e interacción;

• Valor comercial sobre software funcionando;

• Elaboración de alianzas sobre colaboración con el cliente;

• Estar preparado ante el cambio sobre responder al cambio.

Ten en cuenta que en estos comentarios no hay nada sobre resultados mínimos, de hecho, el segundo elemento en cada versión establece exactamente lo contrario, lo que exige software funcionando o valor comercial. En ninguna parte establece que las normas deben reducirse o eliminarse; ni dice que se puede ignorar el cumplimiento. Muchas organizaciones han adoptado con éxito prácticas Agile en entornos altamente regulados y basados en estándares.

No importa qué sistema use una organización, si la organización está reduciendo costos, algo tiene que ceder; en el caso de Boeing se redujo la calidad; en el caso de Robodebt, se han implementado malas prácticas de coincidencia de datos.

David declaró que Agile es esencialmente una "metodología de reducción de costos / maximización de beneficios". No creo que el Manifiesto Agile se haya escrito teniendo en cuenta la reducción de costos, algunos ahorros de costos pueden ocurrir como un efecto secundario de la implementación de los valores de Agile, pero nunca fue un motor principal. Mi lectura del Manifiesto Agile me lleva a la opinión de que el manifiesto trata sobre el bienestar y el empoderamiento de las personas, reduciendo el tiempo perdido en tareas que son en última instancia redundantes y mejorando la experiencia del cliente.

Robodebt

Si analizamos el ejemplo de Robodebt, este sistema podría haberse implementado a través de una cascada o un proceso Agile. Agile no posibilitó que este sistema existiera. Los burócratas decidieron implementar algunas coincidencias de datos sueltos y envió cartas de recuperación de deudas. El marco del sistema de bienestar social permite al Departamento de Servicios Humanos llevar la carga de la prueba al beneficiario del beneficio.

Robodebt puede haber usado Agile durante el proceso de implementación, pero incluso entonces, dos de los cuatro valores Agile no fueron respetados.

La colaboración con el cliente no se realizó, o si se realizó, fue ignorada. Si los clientes estuvieran involucrados en la creación del sistema Robodebt, habría habido casos en los que se descubrió que las técnicas de coincidencia de datos eran insuficientes; los clientes habrían destacado las tensiones causadas por las falsas acusaciones de una deuda; las técnicas de coincidencia de datos del sistema habrían sido mejoradas.

El valor de "responder al cambio" también fue ignorado. Desde la implementación del sistema Robodebt, se ha hecho evidente que el departamento responsable de este sistema no ha estado dispuesto a responder a las llamadas de cambio, sino que ha defendido su posición e ignorado tanto la indignación de la comunidad como los efectos secundarios de su sistema. Si el sistema Robodebt fuera Agile, habríamos visto mejoras en los procesos de coincidencia de datos. Tal vez no hubiera sido perfecto, pero sería mejor de lo que es.

Aunque es posible que el sistema Robodebt haya sido desarrollado por algunos equipos que implementaron algunos valores Agile, declaro categóricamente que:

Robodebt no fue habilitado o creado desde Agile; no se ha adherido a los 4 valores en el Manifiesto Agile; y si está vinculado con conceptos y valores Agile, está haciendo daño a Agile.

Boeing

Viendo el ejemplo del Boeing 737Max, Agile es simplemente un chivo expiatorio para una empresa que elige utilizar prácticas de desarrollo baratas, tener un control de calidad inadecuado y no utilizar las mejores prácticas en el desarrollo de software.

Cada marco de desarrollo Agile que he visto (Scrum, SAFe, etc.) trata sobre el ciclo de vida del producto y el empoderamiento y habilitación de los equipos que desarrollan estos productos. Muchos de los marcos están basados en iteraciones, otros no, esto no tiene ningún impacto en el requisito de que una tarea no esté completa hasta que esté "lista para producción".

"Listo para producción" puede tener diferentes significados para diferentes organizaciones. En algunas organizaciones con un proceso de CI/CD ("Compilación e Integración Continua" por sus siglas en inglés) completo, "listo para producción" puede significar que la finalización de la tarea requiere implementación en producción; en otros (como Boeing), puede ser que la tarea se ejecute con éxito en un simulador.

En el caso de Boeing, si hubieran ejecutado el software en un simulador y si hubieran tenido las pruebas adecuadas, los errores que causaron los accidentes del Vuelo 610 de Lion Air Flight y el Vuelo 302 de Ethiopian Airlines podrían haber sido descubiertos. Habrían podido generar un defecto y corregir el software antes del lanzamiento.

Para mí, uno de los mayores problemas con la situación de Boeing es cuánto tiempo les ha tomado rectificar el problema. Tengo entendido que Boeing sabía cómo replicar la falla, sin embargo, les ha tomado meses implementar una solución; Esto destaca que se han producido prácticas de desarrollo de software deficientes.

Ahora, de vuelta a Agile. No sé lo suficiente sobre el proceso de desarrollo de software de Boeing, por lo que confiaré en que los desarrolladores de software formaron equipos Agile. Si este software se desarrolló en un proceso en cascada, creo que las malas prácticas de codificación habrían sido peores ya que los desarrolladores habrían estado presionados por el tiempo para cumplir con un cronograma; todas las pruebas se habrían dejado hasta el final del desarrollo, y es mucho más probable que las pruebas no hubieran cubierto tantos casos de uso. Si se usa Agile sin una envoltura de cascada, se usa personal competente y se realizan pruebas continuas apropiadas, entonces el producto final debe ser de mayor calidad.

Resumen

• Si tu organización culpa a Agile por fallas en los proyectos, está usando Agile como chivo expiatorio.

• Si priorizas el ahorro de costos sobre la calidad, Agile no es la causa de tus problemas.

• Si no pruebas tu producto, Agile no es responsable de tus malas prácticas.

• Si uno (o algunos) de tus equipos están usando Agile pero están sujetos a una línea de tiempo, tu organización no es Agile.

• Si uno (o algunos) de tus equipos están usando Agile pero planificaste el proyecto usando procesos en cascada tradicionales, estás condenando a ese equipo a que fracase.

Es posible que Agile no te ahorre dinero, que no aumente la calidad de tu producto, que no aumente la satisfacción laboral de tus empleados; pero terminará haciendo al menos uno de estas cosas, y si se hace correctamente, probablemente terminará haciendo los tres.

Volviendo a las publicaciones de David:

• Agile no es una medida de ahorro de costos, puede ser un efecto secundario de la implementación adecuada de los valores Agile, pero no está garantizado;

• Agile no es responsable de la muerte de personas debido al ahorro de costos de la organización, la disminución de la calidad o la mala coincidencia de datos;

• Agile no se trata de reducir características, se trata de entregar características en pequeños incrementos para que se puedan recopilar comentarios y hacer ajustes para aumentar el valor para el cliente.

Michael Lambert: Un aspirante a CTO y facilitador de equipos con pasión por la tecnología, Agile, la experiencia del cliente y los resultados centrados en el usuario.

Como siempre, agradezco cualquier observación o comentario sobre este artículo.