¿Cómo se cruzó Agile en mi camino? (una batallita y algunos recursos para empezar)

A veces las cosas ocurren de casualidad y te cogen por sorpresa. Otras veces pasan cuando necesitas que pasen.

Voy a contaros una batallita de cómo Agile se cruzó en mi camino, y para amenizarlo os traigo a uno de mis grupos favoritos de power metal: UNLEASH THE ARCHERS. Esta banda canadiense está capitaneada por la que para mí es una de las mejores voces del metal actual: Brittney Slayes. Y para muestra, un temazo 🤘

En Youtube:

En Spotify, por si no os queréis distraer con el video:

Bueno, al lío.

Corría el año 2008 y estaba pasado una de las etapas más divertidas de mi (aún corta) carrera, aprendiendo de dos monstruos como Jose Miguel (aka @alegrebandolero) y Santi (@SantiBalboa). Estábamos en MRW montado un sistema distribuido con .NET basado en el patrón CQRS y mensajería con Service Broker (no os preocupéis si no lo conocéis, no lo usa nadie ya…). Fueron unos meses increíbles, aprendiendo un montón y profundizando en cosas realmente interesantes. Y de repente, por un motivo que nunca supe, todo se paró en seco. Dejamos de hacer ese nuevo sistema y nos pusimos a dar mantenimiento a las aplicaciones legacy de la compañía.

Podéis imaginaros mi decepción. Yo quería seguir con el otro proyecto. Quería seguir aprendiendo. Y en vez de eso, tenía que solucionar bugs en stored procedures que había escrito alguien hace meses o años. A mi ego de 27 años y a mis ganas de ser bueno en algo no les sentó muy bien esta situación. Tengo que reconocer que hice algunas tonterías y recibí algunas más que merecidas broncas por ello. Diría que tuve suerte que no me despidiesen un par de veces.

Pasaba el tiempo resolviendo bugs, haciendo pequeñas mejoras y hablando mucho con el equipo de soporte. [Nota al margen: sin ninguna duda, la mejor forma de saber cómo de bien o de mal está un sistema, es pasar tiempo con el equipo de soporte.]

Fueron unos meses bastante malos para mí. Creo que lo que peor llevaba es que a nadie le importase que la mayoría del tiempo no tenía nada que hacer. Así que decidí seguir aprendiendo por mi cuenta. Y eso es lo peor que te puede pasar si no sabes sobre qué aprender. Di bastantes tumbos entre lenguajes, patrones y tecnología que nunca más usé.

Y aquí es donde apareció Agile y me pilló preparado para aprender. Creo que fue en un foro de MS o incluso diría que en geeks.ms cuando oí por primera vez hablar de desarollo ágil y Scrum. Juraría, aunque no estoy seguro, que un post de Rodrigo Corral (@r_corral) me llevó a profundizar en el tema. Y como tengo la mala costumbre de intentar entender de dónde vienen las cosas para entenderlas bien, me dediqué a investigar.

Así que empecé leyendo el Agile manifesto… y lo vi demasiado simple. «Ya está, pero si esto cabe en un folio». Pensaba, inocente de mí. Leí la guía de Scrum y no entendía nada de esos ciclos de feedback de los que hablaba . No conseguí atar cabos hasta que encontré uno de los orígenes de todo esto: The New New Product Development Game. Un estudio de Takeuchi y Nonaka del año 1986, donde ya escriben perlas como esta:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done.

Takeuchi and Nonaka

1986 y ya había gente que lo tenía así de claro. El desarrollo de software siguiendo el paradigma industrial (aplicar en secuencia el flujo de análisis, diseño, desarrollo, pruebas y despligue) no se adaptaba al «mundo vertiginoso y ferozmente competitivo del desarrollo de nuevos productos comerciales». Así que se pusieron a escudriñar en las empresas que lo hacían mejor y encontraron una serie de similitudes que resumen en estos puntos:

1. Inestabilidad inherente
2. Equipos de proyectos autoorganizados
3. Fases de desarrollo superpuestas
4. «Aprendizaje múltiple»
5. Control sutil
6. Transferencia del conocimiento en la organización

¡¡BOOM!! 🤯

Os vuelvo a copiar el link para que lo leáis completo, porque es una maravilla 😍

Creo que este artículo fue lo que me cambió la forma de ver las cosas. Empecé a entender qué era esa «nueva» forma de trabajar que era diferente al típico sistema ASMX^tm (A Salto de Mata eXtremo) al que estaba (mal) acostumbrado.

Quería saber más y lo siguiente que hice fue comprar un libro de Ken Schwaber que no os voy a recomendar porque me resultó soporífero. El que sí recomiendo es el Scrum and XP from the Trenches de Henrik Kniberg. Libro corto, conciso y que se puede aprovechar mucho.

Me empapé de todo lo que pude sobre el tema. Pero no fue hasta unos años después que lo puse en práctica en un proyecto para Telefónica I+D. Fue una pasada coincidir con Inés Vidal (@inesvidal) y otras personas increíbles en ese proyecto, que me ayudaron a poner en práctica toda esa teoría que había recopilado. Y también puedo considerar que fue suerte participar en un proyecto en el que ves cómo tienen que hacerse las cosas para que salgan bien. Esto hace que todos los «es que aquí eso no funciona» te suenen a ñiñiñí 😜 Pero de los motivos por lo que no funciona realmente en algunas organizaciones… ya escribiré otro día.

Para cerrar, os dejo dos recomendaciones más: el Scrum: A smart travel companion de Gunther Verheyen y sobre todo The nature of software Development de Ron Jeffries. Aunque estos dos no los descubrí hasta años después.