Los siete pecados capitales de Agile.

El pasado mes de febrero se cumplieron 20 años desde la publicación del manifiesto ágil, donde se resumen los principios en los que se fundamentan métodos como Scrum o Kanban.

Durante estos años, el uso de estos métodos se ha generalizado hasta convertirse prácticamente en un estándar en el desarrollo de software. Pero la realidad es que no hay muchas empresas en España plenamente satisfechas con su adopción. Las grandes empresas de este país emplean cada vez más dinero en software, pero los resultados obtenidos siguen sin ser los esperados y, todavía, a día de hoy, no son capaces de justificar el retorno de inversión de un proyecto.

Pero tampoco se puede “echar la culpa al arma de lo que hace el asesino”. En general, es la falta de experiencia de algunos equipos y las malas interpretaciones de estos métodos lo que está dañando su reputación.

Y la ironía es que muchos de estos equipos sienten que están aplicando Agile correctamente cuando no hay foco en el valor de negocio entregado, el backlog permanece inamovible o el equipo está formado únicamente por desarrolladores.

Por tanto, creo que está más o menos aceptado que pocas compañías están aplicando los métodos ágiles en todo su potencial. Pero mi pregunta ante esta situación es: ¿Realmente no hay ninguna culpa en los propios métodos?, ¿podemos seguir echando toda la culpa a una mala interpretación? A continuación muestro 7 problemas en los que, a mi juicio, los propios métodos tienen también algo que ver.

Falta de Affordance

El problema, en general, no es de Agile; es de las personas que aplican Agile. Pero ¿qué tiene un método tan sencillo para que sea tan profundamente malinterpretado?

El concepto de ‘affordance’ fue introducido en el contexto del diseño de interacción por Don Norman, que lo define como: "Aquellas propiedades perceptibles del objeto que determinan cómo puede ser usado". Esto significa que el aspecto del objeto no debe dejar lugar a dudas de cómo debería ser utilizado. Esto aplica desde el pomo de una puerta hasta una interfaz Web o el volante de tu coche.

Creo que Scrum carece de este concepto. O, si no, ¿cómo es posible que tras leer la guía cada persona entienda una cosa diferente? ¿Cómo es posible que los equipos tiendan a caer siempre en los mismos errores? Yo, personalmente, vuelvo a la guía Scrum y al manifiesto ágil cada cierto tiempo. Realmente todo está ahí de alguna manera y los principales problemas en los proyectos son debidos a malas interpretaciones de estos documentos, pero ¿no se podría mejorar para evitar estas malas interpretaciones?

Convertirse en un fin en sí mismo

Cualquiera que haya participado en un proyecto con Scrum ha sentido en algún momento la sensación de estar cayendo en una rutina. Planning-review-retrospectiva, planning-review-retrospectiva, planning-review-retrospectiva, y a los 5 sprints te encuentras de repente inmerso en el día de la marmota.

El equipo ha pasado de un equipo motivado a un grupo de monos picacódigo cuyo trabajo es cerrar tickets en Jira. Y el backlog, lejos de ser un elemento vivo que va decreciendo tras cada sprint, se convierte en un cementerio creciente de funcionalidades que sabemos que nunca se van a desarrollar.

Esto es debido, principalmente, a que siguiendo la guía, sin querer, te metes dentro de una rueda, y cuando te quieres dar cuenta estás corriendo en busca de la perfección en el método, descuidando los objetivos del producto.

La propia definición del Scrum Master, como responsable y garante del método, invita también a caer en este error. Y la consecuencia son equipos desmotivados que nunca llegan a ser verdaderos equipos de producto. Este es uno de los argumentos que la gente de Basecamp critica de los métodos ágiles y que le ha llevado a crear su propio método Shape-Up, muy a medida para su contexto concreto.

Se esperan superpoderes de un Product Owner

En mi carrera he tenido la suerte de encontrarme verdaderos Product Owner. Gente que me ha hecho ver la importancia de este rol en el equipo y que han dejado a la altura del betún a otras personas que me he encontrado después intentando desempeñar este rol.

Estos verdaderos Product Owner son capaces de estirar al máximo un presupuesto escaso, añadiendo creatividad para hacer de su debilidad una fortaleza. Y convirtiendo un equipo mediocre en un equipo bueno. Gente con sensibilidad de producto, con una idea clara y siempre pendientes del equipo.

Pero pensar en estos verdaderos Product Owner me hace también recordar que realmente han sido muy pocos, porque son una minoría difícil de encontrar. La realidad es que la mayoría de los Product Owners no están a la altura.

Y creo que el problema en parte está en la definición del propio rol. Es sin duda el rol más complejo de Scrum y se esperan de él casi superpoderes.

Demasiada responsabilidad para una persona que suele ser experta en su negocio pero que no conoce los entresijos del desarrollo de software. Que si encima se junta con un equipo que le deja toda la responsabilidad, desastre asegurado.

Autoimportancia

La guía Scrum dice claramente: “funciona bien como contenedor para otras técnicas, metodologías y prácticas”. Sin embargo, como explica Ramón Nogueras en su charla Cuando falla la profecía, tenemos un sesgo como humanos que hace que sigamos buscando balas de plata. Y ese sesgo hace que muchas personas obvien esta frase y entiendan Agile como la enésima bala de plata. Animados por una industria que se ha generado alrededor, que saca partido a las balas de plata: formadores, coaches, conferencistas, escritores, etc.

Los malos agilistas necesitan marcar una línea perfecta entre lo que está explícitamente en la guía y lo que no. Porque todo lo que no está en la guía, es ciudadano de segunda.

Esta situación se ve agravada en primer lugar por el alto grado de endogamia en la comunidad. En mi opinión, hay que dejar de leer libros sobre Agile, hay que dejar de asistir a eventos de Agile y hay que buscar referencias en otros ámbitos. Hay mucho que aprender del conocimiento específico de un negocio vertical o de ámbitos como el diseño estratégico o el product management.

La segunda circunstancia que agrava el problema es que al calor de Agile han entrado muchos perfiles muy poco preocupados por el valor entregado y más por el ‘método’ como fin. Por mucho que los principios del manifiesto ágil especifiquen que esto no debería pasar, está pasando.

No podemos olvidar que el product management, a medio camino entre un arte y una ciencia, es algo muy complicado. Y que hacerlo bien requiere experiencia.

El boom de Agile ha venido asociado con una inflación en los sueldos y con ello muchos profesionales desde ámbitos de lo más diverso han conseguido una certificación relativamente sencilla y se han convertido de la noche a la mañana en “Scrum Masters”. También cualquier “Scrum Master” con un par de años de experiencia se ha convertido en “Agile Coach” de la noche a la mañana.

Y el problema es que este tipo de perfiles, sin la experiencia necesaria, está dañando a los verdaderos profesionales de vocación.

Falta de estrategia

Todo producto necesita una estrategia que siente las bases de lo que se está haciendo. Y esta estrategia se debe revisar a lo largo del tiempo.

Porque Agile no trajo una propuesta para que lanzáramos espaguetis a la pared sin estrategia a ver qué se pega, sino una propuesta para pivotar rápidamente y vencer nuestra resistencia natural a tenerlo todo planificado desde el inicio.

Scrum no rechaza la estrategia, pero tampoco tiene ningún artefacto o evento donde se hable explícitamente de la estrategia o la visión de producto. De hecho, estas dos palabras, “estrategia” y “visión”, no se nombran ni una única vez en la guía Scrum (solo la review habla tímidamente de cierta adaptación del backlog a las nuevas necesidades).

Esto hace que muchos equipos se olviden de la importancia de la estrategia y fracasen por iterar sin ninguna estrategia de base, ayudando a quemar dinero a clientes e inversores guiados por una sobredosis de Lean Startup mal interpretado, e incluso un poco pasado de moda.

Foco en artefactos, roles y eventos

El principal problema de los métodos ágiles, en mi opinión, no está en lo que dicen sino en lo que no dicen. Por ejemplo, XP pone el foco en las prácticas de ingeniería necesarias para poder hacer entregas frecuentes de software de calidad, obviando otros componentes seguramente más importantes para el éxito de un proyecto.

La guía Scrum, por poner otro ejemplo, pone foco principalmente en tres cosas: artefactos, roles y eventos (en las últimas versiones le da también importancia a los valores). Hace referencia puntualmente durante el documento a algún otro aspecto, pero el grueso del documento y la estructura del mismo gira en torno a estas tres cosas.

Esto motiva a que, sin querer, muchos equipos se centren en estas tres cosas y no en otras igual o más importantes para el éxito de un proyecto.

¿Por qué no poner foco en cómo conseguir el Product Market Fit? ¿Por qué no ponerlo en la obtención de métricas de resultados de negocio? ¿Por qué no ponerlo en el proceso de descubrimiento de nuevas funcionalidades? ¿O en la gestión de riesgos?

Los equipos punteros de producto van más allá de los métodos ágiles. Aplican muchos de sus principios pero usan otra nomenclatura, roles y, sobre todo, ponen el foco en otras cosas. Por ejemplo, el libro Inspired (para mí, referencia en el desarrollo de productos de software) nombra tres principios fundamentales de un verdadero equipo de producto:

1. Los riesgos deben abordarse al inicio, no al final (riesgos de cualquier tipo: viabilidad técnica, negocio, etc.).
2. Un producto debe definirse y diseñarse de manera colaborativa y no secuencialmente.
3. Todo va sobre resolver problemas, no sobre implementar funcionalidades (incidiendo en que lo importante son los resultados de negocio).

Estos tres principios son compatibles con los principios ágiles y la guía Scrum, pero hay una diferencia importante si pones el foco en unas cosas u en otras.

Software funcionando como principal medida de progreso

Medir el progreso en términos de software funcionando es un principio que deja claro que no estamos para hacer presentaciones. Que las reviews no son reuniones de status de proyecto donde se enseñan gráficas en powerpoint con semáforos, sino revisiones de cómo se han implementado los objetivos del Sprint, obtener feedback de los stakeholders e inspeccionar el backlog.

El problema es que a veces hay cosas más importantes que software funcionando. Porque los equipos de producto no estamos para “entregar funcionalidades” sino para “resolver problemas de negocio”. Las funcionalidades son la respuesta a problemas ¿Para qué queremos software funcionando si el producto no tiene sentido y nadie lo usa? Por eso, para mí, la verdadera medida de progreso no es solo el software funcionando, sino el impacto en el negocio que produce ese software: cuántos nuevos usuarios me ha ayudado a obtener, cuánto más eficiente soy gracias al producto, cuántos ingresos me está aportando una determinada funcionalidad, etc. Esos son los datos que importan. Por eso tenemos que poner los resultados de negocio al frente de los equipos de desarrollo.

Cuestión aparte serían los entornos de innovación. En entornos con un muy alto grado de incertidumbre son más importantes los aprendizajes validados que el software funcionando. En ocasiones, se emplean literalmente meses en la construcción de un MVP productivo cuando se podría obtener el mismo aprendizaje en semanas con un buen prototipo interactivo y una buena estrategia de research con una muestra representativa del target al que queremos llegar. Nunca será un entorno completamente real, pero puedes obtener una fiabilidad del 90% con un 10% del coste.

Compatibilidad con las restricciones de un negocio real

La mayoría de los proyectos tienen cerrada una o varias de las tres variables del llamado “triángulo de hierro”: alcance, coste o tiempo. Esta es la realidad de un negocio y la metodología de desarrollo de software tiene que saber convivir con estas restricciones.

“Nosotros no estimamos”, “nosotros no damos fecha”... La rigidez de algunos equipos con respecto a estas variables obligan a un modelo en el que Product Owner lleve una doble contabilidad y asuma individualmente parte del riesgo. Es frecuente que el Product Owner, sin contar con el equipo, se invente una respuesta para estas restricciones que le pide su compañía, optando por una solución que solo empeora la situación, ya que se ponen fechas demasiado pronto sin dejar que el equipo realice un descubrimiento.

Sabemos que el contexto del desarrollo del software es cambiante y que cualquier intento de una solución apriorística es un fracaso asegurado, pero tenemos que saber inspeccionar y adaptar dentro de ciertos límites. Siempre por supuesto que estos límites dejen cierto margen de actuación y que sean realmente los mínimos estrictamente necesarios: que tengas la fecha de salida pero seas flexible en alguna funcionalidad, que tengas el alcance claro pero tengas cierta flexibilidad en la fecha, etc.

Porque los negocios reales requieren cierta planificación: tienen campañas de marketing, estrategias de ventas, dependencias con partners, tienen que presentar cuentas anuales, etc. Y los equipos Agile no podemos negar esta realidad. Tenemos que saber adaptarnos a estas restricciones si queremos trabajar en un negocio real y no en negocios imaginarios sin ninguna restricción.

Conclusión

En mi opinión, no podemos seguir afirmando que todos los problemas de Agile se deben a una mala aplicación, eximiendo completamente de culpa a estos métodos. En cualquier caso, sea una cosa o la otra, la realidad es que estos problemas existen.

¿Llevarán estos problemas la muerte de Agile? NO. Los principios ágiles están aquí para quedarse. Pero creo que guiados por estos principios debemos alejarnos de dogmatismos y buscar mejores prácticas que pongan el foco en lo que realmente está impidiendo que los proyectos no tengan éxito en términos de negocio.

Y eso es lo que hacemos en Paradigma. Desde hace años hemos ido añadiendo herramientas y prácticas a nuestra forma de trabajar, que nos han ayudado a aterrizar los métodos ágiles en nuestro contexto, de acuerdo a nuestra experiencia sobre lo que nos ayuda a aportar más valor a nuestros clientes.

“Adopta los principios. Adapta las prácticas”