Discussion-Driven Development
Aprendizaje continuo sin debates interminables
Una de las actividades esenciales que ha de hacer un equipo en su día a día es aprender. El aprendizaje continuo es lo que consigue que un equipo progrese y mejore en lo que hace, cosa que mejora la calidad de los productos que es capaz de producir. Sin este aprendizaje el progreso se frena y nos estancamos en el valor que podemos aportar.
Sin embargo, el aprendizaje viene con ciertos problemas que hemos de aprender a gestionar. Uno de ellos es la parálisis por análisis y es de lo que vamos a hablar en este artículo.
El aprendizaje lleva a discusiones
Como hemos comentado, fomentar el aprendizaje continuo en un equipo es esencial y saludable para mejorar la calidad y aumentar el valor que aporta. Sin embargo, el aprendizaje colaborativo en un equipo lleva irremediablemente al debate.
Cuando diferentes miembros del equipo y diferentes perfiles aprenden y se empapan de un tema nuevo, es natural que surjan debates sobre el punto de vista de cada uno. Diferentes personas entienden el mismo tema de maneras diferentes y, aunque en esencia puede que tengan lo mismo en la cabeza, siempre surgen matices que debatir.
Esto lo he visto recientemente en varios equipos a los que formamos en Mercadona Tech. Estamos introduciendo cambios arquitecturales y nuevos conceptos que sin duda mejorarán la forma en la que construimos software. Sin embargo, esto en ocasiones nos está llevando a lo que denomino Discussion-Driven Development. Y es que muchas veces nos pasamos más tiempo filosofando sobre cómo construir software que construyéndolo de verdad.
¿Es malo entonces debatir sobre estos temas?
En absoluto, sin embargo, hay que aprender a gestionar estas situaciones para no bloquearnos a nosotros mismos con debates interminables y hacer foco en lo verdaderamente importante: aportar valor a nuestros usuarios con la mayor calidad posible.
Disclaimer: cada vez que hable de “discutir” me refiero a la semántica inglesa de “discuss”. En español suena más a pegarse uno a uno en un descampado, pero el significado que busco es más parecido a “debatir”.
Cómo gestionar el Discussion-Driven Development
El último año hemos aprendido mucho, nos hemos formado en muchos temas nuevos y, como es de esperar, hemos discutido mucho.
Y para solucionar los posibles problemas hemos probado diferentes aproximaciones y hemos iterado la forma en la que debatimos nuestras dudas y las diferencias que tenemos entre nosotros para no irnos por las ramas. Aquí algunas:
Consensus-Driven Development
Una de las primeras que implementamos fue el aprender a no discutir en medio de un desarrollo. Cuando hacíamos pairing nos pasaba muchas veces que nos poníamos a debatir sobre cuál era mejor forma de implementar una cosa. Debatíamos sobre los matices que cada uno entendía sobre el patrón o diseño de turno y gastábamos el precioso tiempo que debíamos dedicarle a nuestros usuarios en discutir.
Entonces decidimos dejar de hacerlo, cosa que requirió de mucha disciplina y fuerza de voluntad.
Para ayudarnos implementamos una manera de gestionar estos temas: cada vez que nos surge una duda de diseño, y siempre que pueda ser aplazada y no comprometa el medio plazo, dejamos que el que tiene el teclado en el pairing decida la solución y apuntamos la duda como una issue en el repositorio. Así no nos bloqueamos, tiramos para adelante y hacemos un defer commitment de la decisión.
Entonces, cuando se acumulan unas cuantas issues, hacemos una pequeña sesión donde comentamos todas estas dudas y tomamos consensos de equipo sobre cómo gestionar cada una. Como resultado escribimos ADRs (lo más concisos y al grano posible) sobre la decisión y el contexto para que no vuelva a surgir.
De esta forma conseguimos llegar a un acuerdo, pero sin pararnos a discutir cada media hora mientras aportamos valor a nuestros usuarios.
Formación continua
Otra dinámica que aplicamos de forma activa para llegar a consensos son sesiones de formación activa. Esta que hemos implementado recientemente conlleva juntarnos en equipo una vez por semana con un tema que debatir y una parte del código donde aplicarlo.
Por ejemplo, podemos querer tratar el tema de cómo inyectar ciertas partes de la infraestructura en nuestros casos de uso. Entonces, elegimos una serie de contenidos de formación (pueden ser videos, artículos, capítulos de libro) y los consumimos antes de la sesión. Además, un encargado designado de coordinar la sesión elige una zona del código dónde sería interesante debatir y aplicar lo aprendido para refactorizar o implementar la nueva solución.
De esta manera conseguimos varias cosas. La primera es que el equipo se forme sobre algo nuevo, algo que está genial. Después, conseguimos que se debatan diferentes puntos de vista y que en el proceso se llegue a consensos sobre ello. Y finalmente, y más importante, conseguimos que el nuevo aprendizaje se aplique de forma práctica en el proyecto. Aterrizando los conceptos y validando, bajando al barro, los beneficios que aporta. Tres pájaros de un tiro.
Cross pairing
Y finalmente, pero la más recomendable, es el cross pairing (pairing entre equipos). No hay mejor manera de aprender que aprender de tus compañeros. Por eso una de las recomendaciones que hago siempre al elegir stack o tecnología es que elijas lo que usan tus amigos, ante cualquier duda o problema tenerlos a mano siempre te evitará bloqueos y dolores de cabeza.
Con el cross pairing consigues lo mismo, aprendes como trabajan otros equipos, te enseñan los detalles y problemas a los que se han enfrentado y las soluciones a las que han llegado tras mucho iterar. Te ahorras todo el proceso de dolores de cabeza y pegarte contra cosas que no conoces y además a ellos les aportas algo valiosísimo: un punto de vista fresco que pueda hacerles challenge de cómo hacen las cosas, algo súper saludable. Así que todos salimos ganando.
Aprendizajes y consensos
Como ves, aprender cosas nuevas en equipo es vital para seguir avanzando. Y si sabes gestionar ese aprendizaje para que en vez de ralentizarte te dé un impulso hacia adelante seréis capaces de aportar un valor tremendo a vuestro producto y a vuestros usuarios, ofreciendo una calidad contundente.
Así que ya sabéis, a aprender y a discutir (pero solo lo justo y necesario!).