En la búsqueda por transformarse, muchas empresas han entendido la importancia de la cultura como pilar fundamental, y abrazan al agilismo como una alternativa en su proceso de transformación digital y la vez terminan creando tribus y squads.. pero los necesitan?
De esta corriente de pensamiento, surge ahora la tendencia por implementar en las compañías las tribus y los squads (modelo Spotify) como si fueran recetas, olvidando muchas veces el propósito detrás, y que las prácticas que funcionan en un entorno no tienen porqué funcionar tal cual en otro.
El modelo Spotify, por ejemplo, ha sido creado desde cero, en base a prueba y error, por una empresa de producto con unas necesidades concretas. Han ido tomando decisiones, como, por ejemplo, usar el nombre de Squads en lugar de “scrum teams”.
El nombre Squad enfatiza que los equipos son completamente autónomos para decidir entre scrum y kanban, además de sonar más cool (no es broma). Estos Squads cuentan también con bastante autonomía a la hora de elegir herramientas y tecnologías, sin fijar en exceso convenciones comunes.
Y aunque Spotify es una empresa digna de admirar, su modelo no es de ninguna manera una panacea. Ha habido muchos comentarios de quienes trabajaron en Spotify explicando las deficiencias de su modelo y, al parecer, la realidad no ha seguido el ritmo del mito del nirvana ágil.
“Me preocupa cuando la gente mira lo que hacemos y piensa que es un marco que pueden copiar e implementar. … Realmente nos estamos esforzando ahora por enfatizar que también tenemos problemas. No todo es ‘brillante y todo funciona bien y todos nuestros equipos son súper increíbles».
Anders Ivarsson, coautor del whitepaper de Spotify.
Scaling Agile @ Spotify
Los Squads son simplemente equipos multifuncionales que constan de alrededor de 6 a 12 personas, muy similar a un equipo de Scrum. Cada equipo está formado por diseñadores, desarrolladores y analistas de negocios, es decir, todos los roles necesarios para trabajar de principio a fin en un área de funciones, sin tener que depender de otro equipo para el éxito.
Un grupo de equipos organizados en un departamento se llama Tribu. Una Tribu puede estar formada por 50-150 personas pero, idealmente, no debería tener más de 100 personas. Este es simplemente un mecanismo de escala para permitir que un mayor número de personas trabaje en una función grande.
Los capítulos se crearon para reunir a todos los especialistas funcionales de diferentes equipos en una comunidad. Esto les permitiría discutir su área de especialización y sus desafíos específicos. El líder del capítulo actúa como gerente de línea para todos los miembros del capítulo.
Los gremios son muy similares a los capítulos en que se organizan en torno a una especialidad, como ingeniería o arquitectura. La diferencia es que un capítulo está abierto a cualquiera que tenga interés en el tema. Este es casi el mismo concepto que las “comunidades de práctica” en Agile, ¡solo que con un nombre diferente!
En esencia, el modelo equivalía a un reetiquetado de una estructura matricial. Cada «capítulo» era en realidad solo un área funcional (por ejemplo, pruebas, programación, diseño) con su propio administrador de personas. Un «squad» es simplemente un equipo multifuncional, por cierto. ¿Por qué no llamarlo simplemente equipo? Cada «Tribu» era en realidad un «Departamento». Nada cambió en estas estructuras, por lo que los nuevos nombres simplemente crearon confusión y llevaron al mito del cambio significativo.
En consonancia con la autonomía, Spotify le dio a cada equipo el control sobre sus propios procesos y prácticas. Pero no tenían suficientes entrenadores para ayudar a todos los equipos, y muchos equipos no tenían suficiente conocimiento de los principios y prácticas ágiles para implementarlos de manera efectiva. Según Lee, “No fue realmente ágil. Simplemente no era una cascada «.
Cuando Spotify lanzó su libro blanco, fue en parte ambición y en parte realidad. Estaban estableciendo una visión para el futuro.
“Incluso en el momento en que lo escribimos, no lo estábamos haciendo. Fue en parte ambición, en parte aproximación. A la gente le ha costado mucho copiar algo que en realidad no existía «.
Joakim Sundén, entrenador ágil en Spotify 2011-2017
A medida que crecía el tamaño de los equipos, Spotify no definió un proceso común para la colaboración entre equipos. Cuando cada equipo tenía una forma única de trabajar y no había pautas sobre las opciones, la productividad general de la organización se resintió.
A medida que crecía el número de equipos, se reconoció que se necesitaba un apoyo dedicado para guiar y estructurar la colaboración entre equipos. Se requieren estructuras o procesos dedicados para permitir que los equipos que no están necesariamente vinculados colaboren juntos.
«En artículos o charlas como esta, puede parecer que Spotify es una especie de nirvana ágil donde todo simplemente funciona y eso simplemente no es cierto».
Henrik Kniberg, creador del modelo de Spotify
Recuerda, el modelo de Spotify se creó hace más de 10 años, por lo que es muy poco probable que, a la luz de los problemas identificados anteriormente, y quizás otros, este sea el modelo exacto que están usando ahora. Spotify es una empresa que está en constante aprendizaje y crecimiento, por lo que habrá evolucionado este modelo muchas veces desde el documento técnico original. Sin embargo, todavía hay mucho que podemos aprender, incluso si no debe aplicar el modelo directamente.
La verdadera magia del modelo de Spotify estaba en la cultura de ingeniería y desarrollo de productos que crearon para equipos ágiles, rápidos, motivados y desacoplados. Con el tiempo, desarrollaron algunos poderosos principios de trabajo básicos que sustentaron su alto desempeño:
Como puede ver, hay algunos conceptos geniales incorporados en el modelo, pero no es un plan para el diseño organizacional ágil por sí mismo.
Descubre nuestras soluciones y cómo podemos ayudar a tu empresa alcanzar sus objetivos de transformación digital.
