El Corazón de Agile
Agile es probablemente el término más controvertido en el ámbito del Desarrollo de Producto en el siglo XXI. Todos los profesionales del sector IT (y de otros) quieren trabajar en entornos Agile y al mismo tiempo casi ninguno está contento con la implementación de Agile en su empresa. Se trata, bajo múltiples aspectos, de un término devaluado y mercantilizado que para muchos ha incumplido su promesa.
La promesa, quizá la utopía, está ahí: Entregar Valor de manera Frecuente y con Calidad, con Feedback constante del Usuario y Capacidad de Respuesta al Cambio. Da igual si construimos un Servicio o un Producto o una parte de uno. ¿Suena bien verdad?
¿Cuál es el incentivo para una empresa para adoptar Agile? El State of Agile Report 2019 nos da algunas respuestas:
Los principales motivos por los que una empresa desea adoptar Agile son:
- Acelerar la Entrega de Software
- Mejorar la Capacidad de Gestión de las Prioridades Cambiantes
- Aumentar la Productividad
- Mejorar el alineamiento entre IT y Negocio
¿Y cuál es el nivel de madurez de la implementación de Agile percibida por los profesionales en sus empresas? Según este informe:
El 83% no está satisfecho con el nivel de implementación y considera que debe mejorar, en la mayor parte de empresas IT se aplica de alguna manera pero no con la madurez necesaria para ser realmente efectiva.
Y aún así, como siempre, el Diablo está en los detalles. No hablamos de blancos o negros, sino de escala de grises. El 48% de los encuestados consideran que Agile (aún inmaduramente implementado) ha resultado beneficioso para la mayoría de sus proyectos de un modo u otro.
Entre la Gestión y el Desarrollo
Agile se mueve en arenas movedizas. En sus inicios (que veremos más adelante) surgió desde los Desarrolladores como una necesidad ante las ineficaces metodologías existentes pero rápidamente se trasladó a las áreas de Gestión de Proyectos y Productos donde se mueven perfiles de todo tipo, muchos de ellos ajenos a la parte técnica.
Esto ha ido conllevando una evolución en gran medida segregada entre un Agile de Gestión y un Agile Técnico, que se plasma en toda una realidad de eventos, libros, charlas y corrientes de opinión, en gran parte con un teléfono roto entre quienes abogan por una mayor presencia de la Transformación Técnica y las prácticas Agile más vinculadas con marcos como Extreme Programming o la filosofía DevOps y quienes monopolizan gran parte del negocio Agile orientado a la gestión con hincapié en marcos como Scrum, SAFe (escalado de Agile) y todo tipo de técnicas de definición de tareas y procesos.
Es obvio para muchos de los que ahora abogamos por un reencuentro en un único Agile orientado a resultados medibles que no tiene el más mínimo sentido esta división de facto entre la Gestión y la Técnica, en muchos casos agravada con la total ausencia de interés por la transformación técnica de quienes se venden como Agile Coaches y sólo se centran en procesos.
¿Qué sentido tiene pues la actual brecha existente entre quienes venden Agile y los Desarrolladores que lo necesitan?¿Por qué hemos promovido muchas vertientes de Agile sin una orientación clara a resultados?¿Cómo hemos generado un negocio que no parece cumplir las expectativas creadas?
El Negocio de Agile
Esta postura es tremendamente lucrativa. Crear una brecha entre quienes son los prescriptores de un conocimiento certificado y quienes lo necesitan es el paso necesario para poder crear un mercado de ingentes proporciones, que mueve grandes cantidades de dinero, genera miles de cursos y certificaciones y publica centenares de libros en todo el mundo.
Es completamente normal que se genere negocio a partir de un problema y una solución. Generalmente el precio de la solución va asociado a su escasez o a la complejidad de su implementación. Dicho de otro modo, existe un incentivo comercial en complejizar las soluciones, no sólo en la formación e implementación de Agile sino en la propia construcción de Software. En un modelo que gira en torno al precio/hora imaginad el incentivo que existe de dar soluciones simples, rápidas y eficientes.
¿Cómo escapamos de esta perversión?
Con divulgación. La comunicación del conocimiento es clave para que quienes compran soluciones exijan la más sencilla y efectiva. Con la mayor democratización de la información de la que seamos capaces.
Con incentivos para la consultoría honesta. ¿Qué ocurriría si premiásemos (pagásemos) como clientes la sencillez, el Valor aportado independientemente de su implementación (tiempo) y orientásemos del todo la evaluación de Agile a métricas significativas?
Con medición. Las métricas principales de Producto, en áreas como el Delivery (Deployment Frequency, Lead Time), la Calidad (Change Failure Rate, Error-free Users, Bug Density), la Seguridad (PenTest Vulnerabilities, Incidents), las Ventas (Net Revenue, MRR), la Customer Experience (Stores Rating, Survey Valuation) o el Crecimiento (Users, Retention) son las que nos indicarán si estamos haciendo las cosas bien, no las opiniones. Y el humo se disipa rápido ante los datos.
El Origen de Agile
Pero vayamos a sus inicios para entender mejor de lo que hablamos. A pesar de que el modelo Scrum existía desde los 80 en el ámbito de la manufactura tecnológica (Xerox, Canon, Honda, Epson, etc) fue en 1995 cuando Ken Schwaber presentó Scrum Development Process en una conferencia de programación como marco para el Desarrollo de Software.
En Octubre de 1999 Kent Beck publica Extreme Programming Explained donde presenta al mundo la metodología XP basada en su trabajo en el gran proyecto C3 de gestión de nóminas para Chrysler.
Posteriormente, el 12 de Febrero de 2001, diecisiete programadores ya míticos entre quienes se encontraban Martin Fowler, Ron Jeffries, Robert C. Martin o el propio Ken Schwaber, fueron convocados por Kent Beck en una reunión en Snowbird (Utah) para tratar técnicas y procesos de Desarrollo de Software. Allí se acuñó el término Metodología Ágil para referirse a las alternativas que nacían en contraposición a las pesadas metodologías formales CMMI o SPICE (a las que consideraban rígidas, normativas y dependientes de la planificación).
De aquella reunión surgió el Manifiesto Ágil, cuyos valores se resumen en:
- 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
Es decir, Agile se creó porque la forma de hacer Software no funcionaba, se alejaba de entornos con requisitos cambiantes y con planificaciones imposibles a largo plazo, por lo que surgió una necesidad evidente de adaptabilidad, cercanía al cliente y foco en el equipo humano que desarrollaba la solución.
La Distribución de Agile
Actualmente este es, según el State of Agile 2019 la distribución de metodologías y frameworks Agile en uso:
Como se puede ver el uso de Scrum y sus variantes supera el 70% del total y éste puede ser uno de los problemas de las implementaciones fallidas ya que el mero uso de Scrum (a menos que sea complementado con XP) no implica todas las prácticas de Transformación Técnica necesarias para alcanzar todos los objetivos que nos plantea Agile.
El Fracaso de Agile
¿Pero cuáles son los motivos más habituales de fracaso de las implementaciones Agile? Tenemos algunas respuestas:
Es crucial observar que en la mayor parte de los casos el problema reside en el Desalineamiento de la Cultura Organizacional con los Valores Agile y con la Resistencia de la Organización al Cambio. Esto es esencial porque nos da la dimensión adecuada para hablar de implementaciones. Si no hay un cambio profundo en la cultura de toda la organización Agile no funcionará. Un error tremendamente habitual es creer que Agile sólo aplica al departamento de Desarrollo de Producto y no al resto de la organización. Éste, recordemos, es el motivo principal del fracaso de Agile en una empresa.
Por otro lado también subyacen la falta de apoyo a las diferentes capas de management involucradas en esta transformación y la ausencia de formación adecuada.
La Revolución DevOps
Volviendo a tiempos más modernos, en la actualidad nos encontramos según todas las fuentes en el auge de la filosofía DevOps con un foco claro en la Entrega Continua, la Integración Continua y el Despliegue Continuo, como muestra el 2019 Accelerate State of DevOps Report del DevOps Research and Assessment (DORA) donde la presencia de equipos de Alto Rendimiento con filosofía DevOps se ha triplicado en el último año hasta el 20% con técnicas como Arquitecturas de Bajo Acoplamiento, Trunk-based Development, Automatización de la Calidad y el Despliegue, Monitorización y clara orientación al Cloud para la Escalabilidad y Fiabilidad, dentro de una Cultura de Seguridad Psicológica.
Esta misma tendencia por la filosofía DevOps la encontramos también en el State of Agile 2019 y se confirma como una reacción ante un Agile centrado en la Gestión (de Tickets, de mediciones sin sentido como la Velocidad basada en Puntos de Esfuerzo, de Sprints que se alargan meses para coincidir con Releases monstruosas, etc) que no ha funcionado. De alguna manera el área técnica ha retomado el protagonismo que nunca debió perder para poder cumplir la promesa de Agile.
Libros como Accelerate de Nicole Forsgren, Jez Humble y Gene Kim nos hablan de poner en el centro de las organizaciones tecnológicas de alto rendimiento la transformación cultural y técnica necesarias para alcanzar la excelencia Agile efectiva.
De nuevo surgen en el área de Desarrollo los valores de Extreme Programming más vigentes que nunca, más necesarios que nunca para recuperar la eficiencia técnica perdida.
El Corazón de Agile
En el Corazón de Agile están la Automatización de la Calidad y el Despliegue, la ejecución programática de Tests Unitarios, de Integración y Funcionales que permitan los sistemas de Integración Continua, Entrega Continua y, en el mejor de los casos, Despliegue Continuo que por ende harán posible la Entrega de Valor de manera Frecuente y con Calidad, con Feedback constante del Usuario y Capacidad de Respuesta al Cambio que mencionábamos al principio como definición de Agile.
En el Corazón de Agile está la Cultura de Mejora Continua y Colaboración, ya que es la base necesaria para llevar a cabo cualquier práctica Agile dentro de los equipos. La búsqueda de la Excelencia lleva siempre a la introspección y a los cambios necesarios para acercarnos a ella. La Colaboración como herramienta de cohesión y superación es característica de Agile, ya que un equipo unido puede afrontar cualquier reto.
En el Corazón de Agile están el Liderazgo Transformacional y la Gestión Lean, a nivel de toda la organización, no sólo aplicable a los equipos de Desarrollo, en conjunción con los Valores Agile promulgados por el Agile Manifesto. La mayor barrera de Agile siempre está en la resistencia al cambio de aquellas estructuras organizacionales que no lo entienden. Ante esto, siempre, la formación y la transformación cultural para obtener una Learning Organization.
Y por último y más importante:
En el Corazón de Agile están las personas, no son las metodologías ni los procesos los que definen Agile, sino cada uno de los nombres y apellidos que componen los equipos que realizan Desarrollo de Producto en cualquiera de sus formas. En un paradigma cambiante en el que los antiguos modelos de gestión ya no son válidos, debemos entender que son las personas y sus interacciones, sus valores del día a día, su formación continua, el modo en el que la organización los cuide y valore en un entorno de seguridad psicológica y fomento de la experimentación lo que hará triunfar a Agile en cualquiera de sus formas.
En el Corazón de Agile estamos tú y yo.
P.D. Si te ha gustado el artículo te agradezco que lo comentes y compartas y creemos una conversación en torno a él.