¿Has estado en alguna empresa donde se haya adoptado Scrum y comienzan las rigideces de los rituales, reuniones y forma de hacer las cosas sin posibilidad de cambiar nada? ¿Te parece ágil? Pues eso le pasó a Spotify.
En 2010 topé con un libro llamado Scrum y XP desde las trincheras escrito por Henrik Kniberg, en aquél momento no me preocupé por saber quién era esta persona y por qué se le había propagado tanto el libro. Di por hecho la calidad intrínseca del libro. Pero parece que esa era solo una de las partes de la receta del éxito.
Henrik estuvo trabajando para la Agile Alliance durante esos años y posteriormente como Agile/Lean Coach en Spotify. El caso es que Henrik hizo sus tareas, su nombre y sus charlas se popularizaron hasta tal punto que cuando presentó el famoso documento de la organización ágil de Spotify, el Modelo Spotify, todos dieron por hecho que Spotify se organizaba de esta forma.
Pero no.
La propuesta de Henrik ha sido tomada como caso de éxito de Spotify por muchos otros y ha resonado en grandes empresas pero no por su éxito, sino por su fracaso. Empresas como:
ING en los Países Bajos adoptaron el modelo pero pronto tuvieron que evolucionar a otra forma más adecuada para ellos manteniendo algunos nombres y cambiando la forma del funcionamiento del modelo.
Zalando tuvo un gran problema de autonomía de sus empleados y mantener estándares de calidad así que finalmente lo desecharon en pro de una centralización progresiva.
Lego también experimentó problemas de claridad en la implementación y terminó volviendo a un modelo más tradicional.
Avanza Bank en Suecia tuvo problemas con la implementación de los chapters y tribes terminando por desecharlo y cambiarlo por un modelo más centralizado.
Patreon también tuvo problemas y al igual que ING evolucionaron a una forma de trabajar y organizarse propia.
Etsy experimentó problemas de duplicidad de esfuerzos y decidieron cambiar a una arquitectura más centralizada y gobernada.
En definitiva, todas estas empresas probaron el Modelo Spotify y se encontraron la cruda realidad. No se puede imponer una forma de trabajar tan grande y estricta a un grupo de personas y esperar que todo funcione bien.
De hecho, tal y como decía al principio, el principal problema del Modelo Spotify es no haber sido probado siquiera dentro de Spotify, era una propuesta y un modelo teórico que no terminó siendo aceptado y tras ver su fracaso en estas empresas que creyeron en él, se confirma el buen criterio de Spotify al no aceptarlo.
Pero me quería centrar en la frase del título del artículo. Para mi el problema con estos modelos y estas propuestas es la completa rigidez. Quien postula cada una de las ideas las detalla rigurosamente e intenta imponer esas formas, sin opciones ni personalizaciones, un dogma difícil de implementar, seguir y que genera fricciones.
Por este mismo motivo no solo el Modelo Spotify sino también Scrum y otras metodologías ágiles han experimentado fracasos, porque la implementación en las empresas donde se usan es tan rígida que de ágil ya solo queda el nombre. Y para colmo incluso en inglés en empresas de habla española, supongo para evitar que se entienda como agilidad en lugar del framework rígido que usan.
Algunos apuntes importantes:
No hagas retrospectivas si las inquietudes y problemas del equipo van a ser escuchados, anotados y olvidados. Recuerda que si prometes una reunión para compartir opiniones sobre lo que funciona, lo que no funciona y lo que hay que mejorar, esto debe accionar cambios en el proceso.
No hagas reuniones diarias (perdón, stand-up meetings) si cada uno va a soltar lo que hizo como un loro y nadie va a prestar atención. Las reuniones diarias en teoría es un punto de encuentro, un momento en el que hablar con el equipo y asegurarnos de que todos estamos alineados, sin bloqueos y con trabajo suficiente para continuar el día.
No hagas sprints de dos semanas. La mayoría toma esta métrica porque no tienen ni idea de cuándo poner la retrospectiva, la demo y la siguiente planificación. Los sprints son en teoría momento de enfocarse en el trabajo. Si tu proyecto está en una etapa muy inicial y no hay stakeholders, podéis permitíos hacer un sprint de un mes. Si tu proyecto es muy cambiante y los clientes quieren ver cosas y ya, hay que reducir a una semana esos sprints. E incluso si tu formato es más multi-disciplinar y una misma tarea tiene varias fases y cada característica va directamente a producción, pasa de Scrum y adopta algo más como Kanban.
No tomes los puntos como horas, ni como días. Los puntos de la historia identifican dificultad y no tiempo. El hecho de tener una tarea de 2 puntos y otra de 7 puntos permite hacer saber a los principiantes qué tareas tomar basada en su dificultad. Medir tiempos no tiene mucho sentido porque hay que saber lidiar con la incertidumbre y no hay muchos gestores de proyectos que lo sepan hacer bien.
Pero sobre todo, ¡no me hagas caso! Es decir, al final la idea de la agilidad es acomodar los rituales, la forma de trabajar y el sistema organizativo al equipo. ¿Quieres implementar un proceso ágil? No sigas pautas, prueba formas de organizar y ve cambiando hasta llegar a una forma de organización natural, intuitiva y sin fricciones para el equipo.