¿Qué es la agilidad? Cuando empecé a pensar en escribir este artículo, alguien me sugirió que proporcionara una guía sobre qué marco ágil utilizar en diferentes contextos. Sin embargo, cuanto más lo pensaba, más me daba cuenta de que sería una guía artificial, con pocos usos prácticos. En su lugar, quiero contar mi historia de descubrimiento de la agilidad, desde los primeros experimentos con eXtreme Programming, hasta el aprendizaje de Scrum y Kanban, pasando por el redescubrimiento de mi sentido de propósito con la agilidad.
Coqueteando con eXtreme Programming
Mi carrera comenzó en 2001, cuando me enamoré de Smalltalk, mientras trabajaba en un proyecto de investigación del ejército. Smalltalk es un entorno de programación orientado a objetos que nos permitía desarrollar con elegancia utilizando algo muy cercano al lenguaje natural. Fue una época de descubrimientos, pasión por el aprendizaje, metodologías y patrones de diseño. Junto con otros investigadores, leíamos todos los artículos escritos por los pioneros del universo Smalltalk, como Kent Beck. Así es como nuestro amor por Smalltalk nos llevó al eXtreme Programming (XP)
Antes de empezar un nuevo feature nos juntábamos a discutirlo y hacer un diseño preliminar usando algo parecido a lo que XP describe como CRC (class, responsibilities, and collaboration) cards. Eso nos daba una idea, a quienes formábamos parte del equipo, de hacia dónde íbamos y de ahí nos sentábamos a programar en pares. Recuerdo que trabajar de a dos nos daba mucha velocidad y pocos errores: una persona veía el bosque y la otra el árbol, y nos íbamos turnando.
Incluso hicimos pares con personas que no programaban en Smalltalk, pero tenían mucho conocimiento del dominio sobre el cual estábamos construyendo. Era poderosísimo. En algún momento descubrimos que daba buenos resultados crear un script que describiera un caso de cómo debía comportarse nuestro sistema una vez implementado el feature para luego ir programando hasta que ese script funcionara: un TDD muy incipiente y rudimentario. Nuestro sistema era también muy complejo: un simulador que tenía que recibir información y luego procesarla y mostrarla en un mapa teniendo en cuenta una serie de variables. Las spike solutions se habían convertido en la norma. Lo que me gustaba de XP era que había que hacer estimaciones en términos de días ideales de programación. Me parecía un enfoque sensato, pero todavía no era muy consciente de por qué era tan relevante. No entendía de plazos de entrega.
Si miraste el mapa de XP te habrás dado cuenta que en realidad aplicamos muy poco de XP. Usamos algunas de sus prácticas, que fueron increíblemente útiles, pero ahora, mirando hacia atrás, me doy cuenta de que había algunos elementos de los valores y la esencia de XP que no había logrado captar.
Scrum queda bien en tu CV
Scrum fue apareciendo en mi camino laboral por destellos. El poder de la daily meeting para sincronizar nuestro trabajo con nuestro equipo remoto; el software que crecía de forma iterativa e incremental a través de un backlog de características y bugs; mi papel como una especie de facilitadora mientras también ordenaba el backlog del que hablaba con los clientes. Destellos. Recuerdo que, por aquel entonces, un colega me recomendó que añadiera mi papel de scrum master a mi currículum. Me dijeron que “quedaría bien” y que en cualquier caso “eso era lo que hacía aunque la gente no me llamara por ese nombre”. No sabíamos que no sabíamos.
El último gran encuentro con Scrum de esta serie de trabajos fue mi participación como analista funcional en los proyectos de una empresa de software que hacía productos para EE.UU. Terminé siendo una proxy sustituto del product owner. Me invitaban a las reuniones de planificación y me hacían preguntas cuando había dudas. Todo lo demás para mí no era más que una caja negra porque en su versión de Scrum, mi rol no existía. Me decía que quizás mi rol no existía en Scrum, pero mis habilidades definitivamente sí, sobre todo teniendo en cuenta todo lo que aportaba a la construcción del backlog y al desarrollo de las funcionalidades. Estaba aprendiendo cómo funcionan los equipos multifuncionales sin ser consciente de ello.
Agilidad Orgánica: amor a primera vista
A mediados de 2013, me contrataron para coordinar el área de desarrollo de una pequeña empresa de software. Me contrataron porque esa área específica era caótica, y yo era “buena para ordenar las cosas”. Cuando llegué, realizaban reuniones diarias, pero el teléfono gobernaba todo lo que allí ocurría. O desgobernaba, en realidad. No había foco.
Después de aproximadamente un año de trabajar para dar sentido al caos con las herramientas que había adquirido hasta entonces, entendí que mi formación y experiencia como ingeniera no era suficiente. Esto me llevó a las Jornadas Argentinas de Agilidad de 2014. Allí escuché a Alan Cyment hablar sobre la agilidad orgánica y, de repente, todo lo que había aprendido sobre la agilidad empezó a encajar en mi mente como las piezas de un rompecabezas: todo tenía sentido si colocábamos una retrospectiva en el centro, como espacio de reflexión que abre las puertas a la mejora. Las reuniones de retrospectiva ayudan a identificar los dolores, a encontrar prácticas para afrontarlos, a experimentar y a iterar. De más está decir que volví a la oficina y convoqué una reunión de retrospectiva inmediatamente. Ese fue un punto de inflexión en mi vida.
Créditos: Ernesto Cárdenas
Kanban y otras yerbas: la inocencia perdida
Una vez que se te quita la venda de los ojos, no hay vuelta atrás. ¿A qué me refiero con esto? Empiezas a saber que no sabes. Te das cuenta de que crear un tablero para gestionar tu trabajo no te hace experto implementador de Kanban. Aplicar algunas prácticas técnicas no significa necesariamente que estés usando XP. Tener roles y eventos de Scrum no es por sí mismo un indicador de que estás desarrollando un producto o servicio de forma ágil.
¿Por qué elegí contarles una parte de mi historia con la agilidad? Porque creo que demuestra que el aprendizaje es un camino muy personal. La agilidad es un camino que no tiene línea de llegada. Siempre se puede ser un poco más ágil que ayer.
También comparto mi historia para que sepas que yo también tengo dudas y que a veces pierdo mi norte. Y cuando eso ocurre, siempre vuelvo a esta brújula que encontré hace un par de años: el corazón de la agilidad. Los valores ágiles son los que importan, independientemente de las prácticas y las técnicas. A veces las técnicas, los roles y las definiciones acaban complicando las cosas y nos hacen perder el rumbo. Colaborar. Entregar. Reflexionar. Mejorar. Repetir.
Lo prometido es deuda
Como mencioné al principio, la idea original de este artículo era escribir sobre qué marco de trabajo deberíamos utilizar en cada contexto. Supongo que ya te habrás dado cuenta de que desde mi mirada no hay recetas. Sin embargo, de algún lado hay que partir. Hay que encontrar la punta del ovillo hacia la agilidad. Y, al principio, hay que tirar de esa punta religiosamente (y si es con la ayuda de un facilitador/a con experiencia, mejor) para estar seguro de que, si las cosas no funcionan, no tiene que ver con una implementación deficiente. Algo como no culpar a mi nutricionista por no ayudarme a perder peso si no he seguido sus consejos.
En esta historia, la punta del ovillo fue XP. Les dejo aquí algunas “puntas del ovillo”:
- Si estás trabajando en un equipo y hay algunos temas que no estáis discutiendo, hazlo en una reunión retrospectiva. Hay miles de técnicas y cada una de ellas requiere diferentes habilidades. Para que te resulte más fácil seguir esta miga en el camino, aquí tienes una sencilla técnica de inicio que me gusta mucho: W3 de estructuras liberadoras.
- Si estás arrancando con el equipo y vas a desarrollar un producto o servicio desde cero, recomiendo aplicar Scrum.
- Si estás haciendo un desarrollo de software, adoptar técnicas de XP seguramente te ayude a aumentar la calidad, el time to market y la colaboración.
- Si hay cuellos de botella, no hay claridad sobre el estado de lo que se está construyendo y tampoco visibilidad del time to market, entonces abrazar Kanban puede funcionar como punta de ovillo.
Pero de nuevo, no puedo enfatizar suficientemente que no hay recetas y que una vez que comienzas a tirar del ovillo, una cosa lleva a la otra. Terminas combinando cosas de Scrum con XP, Kanban y más hasta que tu blend ya no tiene nombre: es simplemente agilidad.
Ojalá escribas tu propia historia de #agilidadenprimerapersona y te decidas a compartirla. Nos leemos!
