Estamos en 2023 y Agile ya lleva a sus espaldas más de 20 años en los que ha supuesto una revolución tanto en empresas de tecnología como en empresas, que no siento de base tecnológicas, han necesitado de la misma para sus procesos o para tener un canal web de venta.
Sea como fuere, Agile sigue siendo un manifiesto con principios y valores sobre los que hemos construído prácticas, métodos y marcos a los que etiquetamos de ágiles cuando son canónicos. Aquí se abre un intenso debate sobre si Scrum es menos Agile que eXtreme Programming, o que un Scrum “Adaptado” quizás sea un fake Agile.
Hoy en día, el argumento clave es que debemos irnos a la “esencia” de Agile. ¿Cuál es su esencia?
Scrum in a nutshell
En Inglés existe una expresión que dice “in a nutshell” cuya traducción es “en una cáscara de nuez”. En el mundo de las formaciones, utilizamos la expresión in a nutshell para referirnos a un resumen o conceptos esenciales para entender un determinado conocimiento. Por ejemplo, existen libros del estilo “Java in a nutshell” o “Cooking in a nutshell” que serían la esencia de esas disciplinas.
En la última actualización de la Scrum Guide añadieron el concepto in a nutshell, lo que podemos entender como la esencia de Scrum, que sería así:
“Scrum necesita de un Scrum Master que genera un entorno donde:
- Un Product Owner ordena el trabajo para un problema complejo dentro de un Product Backlog
- El Scrum Team convierte una parte de ese trabajo en incremento de valor durante el Sprint
- El Scrum Team e interesados inspeccionan el resultado y se ajustan para el siguiente Sprint
- Repetimos”
Por tanto, esta definición será Scrum en su esencia mínima donde nos basamos en la idea de resolver un problema complejo construyendo pequeñas partes sobre las que validar con nuestros interesados.
En Agile todo vale
Si preguntamos qué valores o principios de Agile son la esencia, sería similar a preguntarnos qué rueda del coche podemos quitar. Todos tienen su importancia dentro de Agile y generan un ecosistema con una idea de encontrar mejores maneras de desarrollar software (recordemos que Agile nace del desarrollo software aunque hoy día se aplique en más ámbitos).
Sin embargo, se ha creado un “caldo de cultivo” en torno a Agile donde “todo vale” y cualquier propuesta es válida simplemente porque es una adaptación de la idea original de Agile. Argumentos como “me estoy adaptando a mi empresa, justo lo que propone Agile”, generan versiones de Agile o de Scrum muy cuestionables.
Cualquier adaptación ventajista no se considera Agile si no tiene foco en la entrega de valor.
Scrum Zombie uno de los grandes errores
Existe una corriente negativa sobre Scrum en muchas empresas por su dureza. Scrum se define como un marco incompleto pero, para muchos equipos, el seguir una serie de eventos de una forma determinada les lleva a chocar contínuamente con el know-how de su empresa, lo que genera tensiones.
Esta tensión se está resolviendo huyendo de Scrum con multitud de argumentos: “no hay que ser puristas”, “hay que adaptar Scrum a mi empresa”, “Scrum funciona en un laboratorio pero no en la vida real”. Argumentos hay muchos para no querer seguir Scrum como si fuéramos Zombies sin cerebro. Por un lado, tiene sentido, nadie quiere sentirse así, pero por otro lado, dejamos de lado uno de los beneficios más potentes de Scrum: su capacidad para levantar problemas organizativos.
Cuando sigues Scrum de manera profesional, descubres que tu empresa no está preparada para entregar valor en menos de 30 días y esto es debido a multitud de impedimentos organizativos que, en caso de cambiar, nos harán menos competitivos para crear productos de valor. Por tanto, no tenemos que ser Zombies pero tampoco renunciar porque “es difícil”. Sino usar la esencia de Scrum añadiendo todas aquellas prácticas que consideremos que nos son útiles para entregar valor.
La esencia de Agile no son cambios gratis
Las empresas o equipos que han decidido abandonar Scrum o, al menos, su dureza, se justifican usando la expresión “la esencia de Agile”. Es una manera de autoengaño en la que tratas de justificar que tu empresa no quiere pagar el precio del cambio y, en vez de eso, prefiere quedarse con todo aquello que le interese.
A pesar de que pueda tener sentido hacer esto, la esencia de la que muchas empresas hablan es, en resumen, “cambios gratis”. Es decir, entienden Agile como una planificación algo abierta con fecha cerrada y un alcance abierto para el cliente que puede proponer cambias en cualquier momento. De esta manera, nuestro cliente percibe que nos “adaptamos a sus necesidades”.
Estos equipos no miden valor, no se centran en el impacto que su software produce, solo se centran en el construirlo y en que el cliente esté satisfecho porque sus cambios se van incorporando.
Obviamente, esta situación genera frustración porque los cambios gratis son muy problemáticos. A los Developers les frustra porque sienten que su trabajo es contínuamente alterado. Los clientes pueden ser “felices” pero un día, hay que parar los cambios y ahí empiezan los problemas. Las empresas necesitan alguien que ponga freno y acaban por nombrar “gestores” que controlen estos cambios. Además, nadie está mirando el valor obtenido… ¿Dónde está el cambio de Agile si estamos usando su esencia?
La esencia de XP
EXtreme Programming es, de todas las propuestas Agile, la más centrada en desarrollo software. Es verdad que, a diferencia de Scrum, propone mejoras técnicas de alta calidad y prácticas avanzadas de desarrollo como TDD o Pair Programming. Para muchos, la esencia de XP es negativa porque parece que solo se centra en el ego del programador o programadora que solo quiere “hacer las cosas bien”.
Sin embargo, la esencia de XP es otra, conseguir productos de calidad donde el servicio que preste sea positivo y donde los costes de mantenimiento sean bajos. Además, un código bien hecho es más fácil de controlar que un código hecho corriendo y mal. Cuando programas de manera robusta sabes perfectamente cómo está tu producto. Sin embargo, muchos equipos al preguntarles cómo van, tienen dificultades para contestar porque aún no han hecho pruebas o han integrado el código.
Por tanto, con XP podemos hacer mejores productos, ¿estamos dispuestos a pagar el precio?
La esencia de todo es cambiar
La auténtica esencia de Agile, XP, Scrum o incluso Kanban es cambiar porque proponen un enfoque distinto que nos llevan a nuevos paradigmas sobre cómo orientar nuestros productos. Seguir como “bobos” una guía o un libro es verdad que parece absurdo pero más absurdo es dedicar tiempo a reinventar Agile para ajustarlo a lo que queremos (que es no cambiar).
Si queremos cambiar, será un camino duro pero nos llevará a mejores lugares. Y tú, ¿sigues la esencia de Agile?
