Digital Foundations

¿Tu empresa realmente necesita tribus y squads?

11 Jan 2022
5 min read

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.

El modelo Spotify

Scaling Agile @ Spotify

Squads

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.

Tribus

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.

Capítulos (o Chapters)

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.

Gremios (Guilds)

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!

¿Cuáles son los problemas de este modelo?

Reetiquetado

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.

Competencia ágil

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 «.

El modelo era una ambición y no se adoptó por completo

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

El modelo optimizado para una autonomía completa del equipo

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ó.

La colaboración entre equipos era una competencia asumida

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.

El poder del modelo de Spotify está en sus principios de ingeniería más que en el diseño de su organización.

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:

  • Equilibrar la alineación y la autonomía: Spotify se esfuerza por lograr un equilibrio entre la alineación (dirección central) y la autonomía (autoorganización del equipo). Los gerentes pintan el panorama general, pero no le dicen a la gente cómo llegar allí o cómo resolver los problemas.
  • Lanzamientos desacoplados para reducir el tiempo de ciclo: Spotify cambió su arquitectura para desacoplar dependencias y hacer los lanzamientos más fáciles y rápidos. Esto permitió lanzamientos de producción más frecuentes que pueden ser independientes entre equipos.
  • Confía en tu gente: Spotify confía en su gente y la apoya sin intentar controlarla porque cree que la mayoría de la gente está haciendo lo mejor para la organización.
  • Los gerentes como líderes de servicio: es mejor que los gerentes pregunten a los equipos cómo pueden ayudar, en lugar de preguntar a las personas en qué están trabajando o cuándo terminarán.
  • Maximice el valor sobre el ajetreo: los equipos generan ideas, realizan experimentos rápidos y luego miden los resultados. A partir de esto, modifican su enfoque para maximizar el valor. Es importante destacar que optimizan para maximizar el valor y no solo la producción.

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.

¡Inscribe a tu equipo ahora!

Descubre nuestras soluciones y cómo podemos ayudar a tu empresa alcanzar sus objetivos de transformación digital.

Comparte este post