Hyper Agile

El manifiesto para el desarrollo ágil de software^[1] en 2001 fue un hito en la producción de sistemas de información.

Como reflejo de la creciente preocupación por el mal servicio que brindaba el software a sus clientes, algunas de las voces más conscientes de la tecnología de la información formularon, en cuatro líneas, proposiciones que invirtieron todo lo que antes se consideraba irrefutable y decidieron elegir:

• Personas e interacciones en lugar de procesos y herramientas.
• Software funcional en lugar de documentación detallada.
• Colaboración con el cliente en lugar de negociación de contrato.
• Respuesta al cambio en lugar del cumplimiento de un plan.

Varios principios adicionales pronosticaron claramente las consecuencias de esta perspectiva.

Después de dos décadas, los resultados son variables. Hay muchas experiencias positivas, pero el desarrollo ágil todavía no se aplica ampliamente. El proceso interactivo todavía no es más común que la alternativa, clásica waterfall. “Ya somos Agile” a menudo significa tener un pequeño proyecto Agile, mientras que la mayoría de los proyectos siguen la descomposición lineal y secuencial de la waterfall: requisitos> diseño> desarrollo> pruebas> instalación. Cuando las cosas no funcionan como se espera, es común que los equipos (y clientes) se refugien en las prácticas de waterfall. Si las promesas del Agile no se cumplen, la tendencia es recurrir a las técnicas antiguas.

Sin embargo, estas están claramente desactualizadas. Debido a la rapidez con la que cambian los paradigmas hoy en día, hemos visto casos en los que el software ya está obsoleto antes de que se finalice y ya no responderá a las necesidades del cliente. La realidad y las necesidades cambian más rápido que el desarrollo de software cuando se realiza con la metodología de waterfall.

Por otro lado, el desarrollo ágil se convirtió en la metodología Agilel y, hasta cierto punto, fue burocratizado. La noción de la meta a menudo se pierde; con ser identificado como el objetivo final^[2]. Alistair Cockburn, uno de los suscriptores del manifiesto se quejó de este efecto en el ScrumDay, celebrado en Lisboa^[3] 2017. La certificación de dos días de scrum masters y la identificación de los product-owners no garantiza el éxito de los proyectos.

El éxito del software no es solo una cuestión de metodología. Seguir una metodología ágil, como muestra^[4] el caso reciente con Lidl, puede llevar a un desastre. Puede ser incluso más difícil y más lento (y, por lo tanto, más caro) declarar un proyecto ágil como fallido. Es esencial que la agilidad ya sea una característica técnica del software utilizado para desarrollar, lo que, para Lidl, no fue el caso.

El software inspira otras áreas de gestión. Hay que seguir de cerca del proyecto BBVA para cambiar su organización, estrategia y (aún más difícil) su cultura con el objetivo “More than 30,000 people working “agile” in 2018”^[5].

La contribución de Quidgest

Después de 2 décadas es el momento de exigir más de Agile. El desarrollo de software no se volverá más ágil (más rápido) mientras los humanos aún escriban el código a una velocidad de 2 caracteres por segundo y sean propensos a errores humanos difíciles de detectar, incluso con peer-reviewing.

Tampoco se vuelve más ágil o rápido si se aplica una configuración de software standard tradicional. Estas configuraciones se mantienen por el componente standard (una black box intocable), que tienen una agilidad semejante al hormigón. En este caso, hablar de conciliar Agile y un ERP standard tradicional, por ejemplo, es solo engañar al cliente^[6].

Las ganancias obtenidas solo para reorganizar equipos y tareas (Agile no es compatible con la automatización de generación de código) son limitadas y se limitan a proyectos pequeños, cortos y simples, desarrollados por equipos muy pequeños.

En realidad, Agile es limitado^[7] y, para superar esas fragilidades que aplican las lecciones aprendidas, se originó Scaled Agile^[8] (ahora en la versión SAFe 4.5). Esta metodología incorpora un conjunto de inquietudes relacionadas con niveles más elevados de complejidad y carteras de proyectos simultáneos, al mismo tiempo que incorpora conceptos de Lean IT.

Quidgest es un orgulloso defensor de Agile y Scaled Agile, y ha contribuido a elevar esas metodologías a un nivel más alto de eficiencia.

Las contribuciones decisivas de Quidgest a Hyper Agile son

• La automatización (saltando de 2 caracteres por segundo a 1 millón de caracteres escritos por segundo, sin errores).
• El modelado (control a un nivel de abstracción aún más elevado, representación de alto nivel y haciendo explícito el sistema arquitectura).
• La eficiencia del equipo (la integración de habilidades con Genio permite equipos mucho más pequeños, reutilización de patrones y menos trabajo directo para cada proyecto).
• La reducción de los ciclos de producción de software (solo unas pocas horas)
• La comunicación e interacción con las empresas, (facilitando la comunicación y reflexión a nivel de modelo, tarea difícil a nivel de código; los lenguajes de programación no son la forma correcta de concebir soluciones de software o hablar con el CEO o los usuarios clave).

___________________

[1] http://agilemanifesto.org/
[2] Uma posição interessante https://www.lambdacambridge.com/blog/2018-05-how-scrum-destroyed-agile
[3] Em 2018, vai organizar-se o Experience Agile https://www.experienceagile.org/
[4] https://www.consultancy.uk/news/18243/lidl-cancels-sap-introduction-having-sunk-500-million-into-it notando-se que a metodologia proposta se pretendia ágil: https://www.kps.com/en.kps-transformation.html/article-2203-unternehmen-der-unterschied
[5] https://www.bbva.com/en/bbvas-journey-becoming-agile-organization/
[6] http://www.scmfocus.com/sap/2018/08/kps-continues-to-keep-promote-hana-for-retail-for-lidl-after-failure/ A este respeito, aconselhamos vivamente a opinião fundamentada e corajosa de Shaun Snapp.
[7] Por exemplo, as limitações da aplicação do Scrum estavam bem patentes no primeiro artigo sobre o tema, “The New New Product Development Game”, de Hirotaka Takeuchi e de Ikujiro Nonaka, Harvard Business Review, January 1986, muito antes de o termo ser aproveitado pela produção ágil de software.
[8] https://www.scaledagileframework.com/