Cómo funciona la metodología ágil de Spotify

Juan Otálora
Juan Otálora
Scrum Master y estudiante de Ingeniería Informática en la UM
Si os hablo de Spotify, lo único que os sonará es la plataforma de música en streaming líder en la mayor parte del mundo. ¿Y si os dijese que Spotify ha desarrollado una metodología ágil basada en Scrum?
Share on whatsapp
Share on twitter
Share on linkedin

🕐 7 min

Share on whatsapp
Share on twitter
Share on linkedin

🕐 7 min

He dedicado mucho tiempo en esta página a redactar artículos sobre metodologías ágiles y lean. Las dos que más hemos tratado y explicado con Scrum y Kanban, quizás las más reconocidas por sus nombres. Bien, pues hay algunas empresas que han creado y refinado sus propias metodologías de trabajo como es el caso de Spotify.

Para entender bien este caso, creo que es imprescindible que entendáis el funcionamiento de Scrum, ya que la idea de Spotify es heredada de lo que ya propuso Shuterland. No obstante, iré colocando enlaces a todo lo que vea necesario.

Scrum es difícil de escalar

Scrum es una buena metodología ágil para proyectos pequeños y medianos que se encuentran en constante cambio y evolución. Esto la convierte en una candidata perfecta para el Spotify de hace 10 años, pero quizás no tanto para el de 2020.

Al igual que en muchas otras empresas del estilo, Spotify contaba con diversos equipos, cada uno dedicado a una plataforma distinta como Android, iOS, Mac o PC. Cuando se empieza a escalar y a contratar más desarrolladores, uno de los principales problemas que salen a la luz es la falta de comunicación entre (y dentro) los propios equipos. Esto hace que cuando se quiera implementar una nueva característica, sea muy difícil que todos los equipos y todos sus componentes se pongan de acuerdo en algo. Creo que estaréis de acuerdo conmigo en que esto no es nada ágil.

Otro problema que ocurre es la falta de representación en el trabajo que estás realizando. Cuando estás junto con otros 50 desarrolladores diseñando el mismo producto, es muy difícil que estés motivado y muchas veces te sientes irrelevante en el proyecto. Esto puede llegar a causar una crisis de proyecto de las que ya hablamos en otro artículo.

En general, en el modelo Scrum, cuando intentamos escalarlo, acabamos perdiendo velocidad y autorrealización en los trabajadores, y esa fue la razón por la que en Spotify decidieron crear este nuevo modelo.

Nueva metodología, nuevos conceptos

Como he dicho, la metodología se hereda de Scrum y por lo tanto, algunos de los conceptos que ya conocíamos, nos servirán para entender cómo funciona el modelo de Spotify. No obstante, hay algunas nuevas nociones importantes que merecen ser explicadas:

Squad o Escuadrones

Es el nombre con el que se le conoce a los equipos de desarrollo en esta metodología. Al igual que en Scrum, deben ser equipos auto-gestionados y que sean lo más autónomos posibles. Esta autonomía en los equipos es casi total y les permite utilizar internamente la metodología que prefieran, es decir, unos pueden usar Scrum, mientras que otros pueden decantarse por Kanban o por cualquier otra. Los equipos estarán compuestos por:

En total, no se deberían de sobrepasar los 12 integrantes por grupo. La razón es bastante sencilla, y es que a partir de esta cifra, los equipos suelen dividirse psicológicamente en varios sub-equipos y eso no es lo que queremos si todos están trabajando en un mismo proyecto. Además, estos Squads no son estáticos, si no que se van moviendo y van rotando todo el tiempo.

Tribe o Tribu

Las tribus o tribes están formadas por Squads o escuadrones que están trabajando en un mismo producto o servicio. Algunos ejemplos de tribus en Spotify podrían ser:

  • Spotify Playlists Tribe
  • Spotify iOS App Tribe
  • Spotify for Artists Tribe

Aunque el límite de equipos por tribu está definido entre 40 y 150, muy raramente se alcanza la cifra máxima, que está situada más por una cuestión teórica que realmente práctica.

Anteriormente, las tribus estaban dirigidas por una sola figura, pero resultó ser una tarea muy ardua y complicada para una sola persona. De esta manera, a partir del 2012 se confeccionó la idea de líderes de una tribu, cargos (normalmente tres) ocupados por representantes del producto, ingeniería o diseño.

También dejar claro que las tribus a su vez se agrupan bajo Alianzas, las cuales son dirigidas por Chief […] Officer dependiendo de la temática y el trabajo que realicen. Es la estructura más abstracta de todas, justo por debajo del nivel de organización o empresa.

Chapter o División

Los chaptser o divisiones son una especie de agrupación cruzada con los escuadrones donde se intenta reunir a cada uno de los integrantes por competencias.

Esto puede llegar a ser un poco contradictorio, pues en Scrum sabemos que en los equipos deben haber los mínimos especialistas posibles, pero que no tengan especialistas, no significa que no tengan expertos.

Cada una de estas divisiones tienen un manager llamado Chapter Lead encargado de que su personal asociado se encuentre bien formado y en el equipo de correcto. Algunos ejemplos de chapters podrían ser:

  • Front-end developer
  • Back-end developer
  • Data analyst
  • Quality assurance

Guild o Gremio

Los gremios son grupos de interés donde cualquier persona de la compañía puede adherirse. No hay que confundir a los gremios con las divisiones, ya que las divisiones intentan agrupar a los trabajadores por competencias y en los gremios por gustos e intereses.

Los gremios se pueden crear al rededor de cualquier temática o interés que tengan en común como mínimo dos trabajadores, esté relacionada con el negocio o no. De esta forma, cualquiera puede unirse a cuantos gremios quiera y podrá elegir lo activo que quiere estar en cada uno de ellos.

Los gremios no son «obligaciones empresariales», son más bien puntos de reunión o foros donde se comparten ideas, conocimiento y opiniones. Permites a los empleados sentirse a gusto en la empresa, a la misma vez que se desarrollan, comparten experiencias y se relacionan.

Cómo funciona la propuesta de Spotify

Spotify comenzó siendo una empresa que utilizaba Scrum como framework de desarrollo ágil en sus proyectos. Aunque Scrum es un marco de trabajo que permite cierta variabilidad, Spotify decidió en 2012 salirse de los railes para crear una nueva forma de trabajar basada en:

  • Respeto a las personas y a la cultura. Las herramientas y los procesos importan, pero las personas están por encima de todo. Esto recuerda a una de las valoraciones que se propusieron en el manifiesto del desarrollo ágil: «Individuos e interacciones sobre procesos y herramientas».
  • Transparencia, comunicación y confianza como pilares fundamentales para el trabajo en la compañía.
  • Quitar limitaciones y asumir el fracaso como parte del proceso. Esto permite a sus empleados experimentar en la manera de hacer su trabajo sin miedo a ser penalizados.
  • Conseguir el equilibrio perfecto entre la autonomía y el control. Un exceso de control impide que florezca la originalidad y una falta de control puede llevar a los equipos a alejarse de la misión de la empresa.
  • Responsabilidad colectiva y confianza. Debemos ayudar en aquello en lo que podamos al resto de compañeros que se hayan quedado estancados, porque el producto es de todos y lo único que importa es que finalmente salga adelante.
La comunicación entre equipos y la colaboración es crucial

Al igual que en Scrum, los proyectos se van entregando de forma incremental, donde cada 1, 2 o 3 semanas se entrega un nuevo incremento del resultado, es decir, partes del producto final totalmente funcionales y listas para probar. Estos incrementos se mandan a través de los conocidos Release Trains que os sonarán del framework SAFe.

Antes os he dicho que solamente era importante conocer Scrum para entender la forma de trabajar de Spotify. No obstante, me gustaría aclarar que Scrum escala muy mal cuando tenemos a muchos equipos trabajando sobre un mismo producto, y eso es uno de los problemas que viene a solucionar SAFe.

Problemas que conlleva

Como el resto de filosofías basadas en Lean, la mejora continua es parte de los ideales que componen esta metodología o forma de trabajar que han adoptado en Spotify. Aunque ya se lleva usando durante muchos años, aun existen algunos problemas que esperemos que los ingenieros vayan solucionando con el paso del tiempo:

Los proyectos grandes 👨‍👩‍👦‍👦. Cuando necesitas involucrar a muchos escuadrones para un solo proyecto, la comunicación entre ellos se hace bastante complicada. Una forma de paliar este problema es comunicar todo, dejar todo bien claro y repetirlo las veces que haga falta para no desencadenar en una desincronización que puede resultar fatal.

Una mala comunicación en proyectos con varios escuadrones involucrados puede llevar al fracaso

Falta de reutilización ♻️. Reutilizar no solo te permite ahorrar tiempo, sino también importantes costes que se podrían haber evitado. Cuando hay tantos equipos y estos equipos son tan autónomos, no se comparten las mismas ideas que cuando estamos hablando de un pequeño equipo Scrum. Para intentar solucionarlo, se crearon los gremios, una especie de foro de discusión y formación que permite tener controlada esa compenetración y esa comunicación de empresa que es tan importante.

Poca eficiencia de los recursos 💎. Como ya comentamos unos párrafos antes, los equipos deben ser full-stack, por lo que para cada equipo necesitamos un desarrollador de back-end, otro de front-end, un analista, uno de QA, uno de pruebas unitarias, uno de sistemas, … Se necesita mucho personal para poner a funcionar un solo escuadrón, por lo que imaginaros si tenemos tribus, tribus y tribus de ellos.

Más información sobre Agile en Spotify

Además de todos los enlaces que he ido dejando a lo largo del artículo, os voy a recomendar algo de material adicional:

Conferencia de empleado de Spotify sobre el uso de metodologías ágiles en la empresa

Hemos hablado del framework SAFe, por lo que si quieres conocer algunas nociones, aquí dejo una presentación perfecta para introducirte en él:

Funcionamiento del framework SAFe

🔥 Otro artículo

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *