¿Agile?
Reconozco que no tengo mucha idea de lo que es esto del Agile, he leído el manifiesto y parecen cosas bastante lógicas, no obstante mi crítica no va tanto al agile sino más bien a cómo está implementado.
En primer lugar, estoy más que harto de la mezcolanza de términos en inglés y en español, el sprint, la daily, la planning, la retro, el refinamiento, la tribu, el townhall, os juro que me entran ganas de matar a alguien cuando me dicen -tengo una call para hablar del kickoff de la próxima semana-. ¡Arghh, que me den un cuchillo por favor!. Otro de los temas es la duración de las “ceremonias”, es bastante común que la reunión diaria se convierta en una especie de reporte al propietaria del producto, PO para los amantes de las abreviaturas, dónde se te puede ir media mañana en charlas que se salen fuera del objetivo de simplemente explicar qué hice ayer, qué voy a hacer hoy y qué puñetas me tiene amargado porque no lo saco y mira qué es fácil. Un cuarto de lo mismo pasa con las reuniones de planificación o de refinamiento, la mayoría de las veces vas a esas reuniones pensando que ese día es posible que hagas más bien poco.
Fuera bromas, hay una cosa que todavía no he acabado de entender, entiendo que este tipo de metodologías surgieron en proyectos de desarrollo de software dónde hacer una serie de tareas a,b,c llevan irremediablemente a d si se hacen correctamente. Sin embargo, en los proyectos de ciencia de datos tú puedes hacer correctamente a, b y c y sin embargo no llegas a d sino que vuelves a a o peor aún, se desecha completamente todo lo que has hecho, por lo que parece que no has avanzado nada. Lo que quiero transmitir es que en los procesos de ciencia de datos, las tareas están menos detalladas, son más amplias y están sujetas a una mayor incertidumbre que las propias de desarrollo de software y, que por tanto, parece que estas metodologías ágiles no sean las más adecuadas.
A lo largo de mi escasa experiencia en esto de currar en organizaciones ágiles lo que me he encontrado es que la implementación de estas metodologías no es más que un barniz de apariencia lleno de postits. En realidad, detrás de esta apariencia de modernización de la estructura organizativa se suelen esconder los mismos demonios, a saber: fechas de entrega inamovibles, jefes de proyecto tradicionales reconvertidos a “bussiness owners” o a “product owners”, burocracia infernal o competitividad extrema disfrazada de “juego”.
Pero no todo es malo, tengo que decir que una vez vi bien aplicado esto de las metodologías agile y fue en un proyecto con la gente de un conocido retail de venta de ropa y accesorios deportivos. El “propietario del producto” tenía muy claro a dónde queríamos llegar, trabajó con nosotros día a día y cuando los problemas de los datos salieron a la luz (los datos siempre están regular o mal en todos sitios) se cambió el alcance del proyecto y se enfocó en solucionar en la medida de lo posible dichos problemas, para acabar dando una herramienta útil a la gente de negocio. Todos salimos contentos a pesar de que lo proyectado y lo conseguido no se parecían en nada.
Lo dicho, no acabo de entender muy bien toda la obsesión con las metodologías ágiles en proyectos de ciencia de datos, pero quizá tenga que ver con qué sólo nos quedamos con la forma y no con el fondo. Seguro que alguno de mis lectores sabría explicarme las bondades del agile más allá de los tableros llenos de postits, las mil herramientas de software para gestionar las tareas y las agotadoras ceremonias llenas de palabrejas en inglés.
Nada más, solo desearos feliz sprint a todos, que vuestras plannings se cumplan en al menos un 25%, que no os digáis muchas burradas en las retrospectivas, que los inceptions sean provechosos, que la tribu os acompañe y que el dios de los postit os proteja.