Antonio Lorente | ¿Por qué el modelo Spotify se ha hecho tan popular?

25 May ¿Por qué el modelo Spotify se ha hecho tan popular?

Publicado a las 11:05h En Metodologías ágiles by fernando

0 Likes

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.

El modelo de Spotify es un marco autónomo impulsado por las personas para escalar la agilidad en una organización. El modelo enfatiza la importancia de la cultura y la red, y se implementa a través de Squads, Tribus, Capítulos y Gremios. La base del modelo es el escuadrón y actúa como un equipo Scrum.

Historia del Modelo Spotify.

Spotify se ha convertido en el reproductor de música en la nube por excelencia y es conocido por ofrecer colecciones originales e ilimitadas de contenidos musicales. Se lanzó en 2008 y se ha convertido en una gran empresa con 1.600 empleados.

Debe su éxito a su profundo empleo de metodologías ágiles y a la utilización de de un framework de escalado ágil. Este framework se denomina Spotify Tribe.

Al principio, la empresa empezó con la metodología scrum, cuando eran pocos empleados.

Sin embargo, cuando empezaron a crecer, se dieron cuenta de que necesitaban algo más y, es por ello, por lo que implementaron un modelo de escalado ágil.

Con cifras de 2020, cuenta con 30 equipos ágiles repartidos por cuatro ciudades en tres zonas horarias diferentes.

Adoptando un método de escalado ágil único no sólo ha hecho que Spotify alcance sus objetivos más rápidamente, sino que también ha ayudado a desarrollar el mindset de los empleados.

¿Cómo gestionó Spotify el crecimiento a medida que escalaba?

Spotify comenzó con scrum, pero pronto empezó a aplicar los principios ágiles de la siguiente manera:

Squads
Tribus
Capítulo
Gremio
Trío
Alianza
Arquitecto jefe

La unidad básica de desarrollo en Spotify es el squad (escuadrón). Generalmente, un squad es similar a un equipo de scrum y está diseñado para sentirse como una pequeña empresa emergente. En una organización, puede haber varios squads y cada squad está formado por 6-12 personas.

Cada escuadrón se dedica a trabajar en un área específica. Todos los integrantes de un escuadrón suelen sentarse juntos y disponen de todas las habilidades y herramientas necesarias para diseñar, desarrollar, probar y poner en producción.

El escuadrón es autónomo, se autoorganiza y se autogestiona. Cada uno de los miembros del equipo tiene total libertad para elegir su metodología ágil. Así, algunos escuadrones utilizan sprints de Scrum, otros utilizan Kanban y otros utilizan una mezcla de Scrum y Kanban. A veces, para lanzar el producto antes de tiempo, los equipos aplican también la técnica del producto más viable (MVP).

Cada squad tiene una misión a largo plazo, como construir e implementar el producto. Todos los squads tienen siempre un coach ágil, que les ayuda a mejorar su forma de trabajar. Hay un Product Owner que define la visión de las funcionalidades a incorporar.

El Agile Coach dirige las Retros y las Sprint Planning se mantienen opcionales. Cada escuadrón tiene interacciones directas con las partes interesadas y no hay dependencias de bloqueo de otras escuadras.

La mayoría de los escuadrones tienen un espacio de trabajo impresionante que incluye una zona de escritorio, una zona de estar y una sala de «huddle» personal. Casi todas las paredes son pizarras blancas.

Se anima a los squads a dedicar el 10% de su tiempo a los «hack days». Durante los días de hackeo la gente hace lo que quiere, normalmente probando nuevas ideas y compartiéndolas con sus compañeros.

Los días de hackeo no sólo son divertidos, sino que también son una forma estupenda de estar al día de las nuevas herramientas y técnicas, y a veces dan lugar a importantes innovaciones de producto.

Una visión de alto nivel de cada squad:

Product Owner – El equipo tiene un propietario del producto dedicado que prioriza el trabajo y tiene en cuenta tanto el valor del negocio como los aspectos técnicos.
Agile Coach – Les ayuda a identificar los impedimentos y les entrena para mejorar continuamente su proceso.
Influencia en el trabajo: cada miembro del equipo puede influir en su trabajo, participar activamente en la planificación y elegir en qué tareas trabajar. Cada miembro de la brigada puede dedicar el 10% de su tiempo a los «hack days».
Facilidad de “releases” – El equipo puede (y lo hace) poner en marcha las cosas con un mínimo de molestias y sincronización.
El proceso se adapta al equipo – El equipo se siente dueño de su proceso y lo mejora continuamente.
Misión – El equipo tiene una misión que todo el mundo conoce y se preocupa por ella, y las historias del backlog están relacionadas con la misión.
Apoyo organizativo – El equipo sabe a quién dirigirse para resolver problemas, tanto técnicos como «blandos».

Representación gráfica de un Squad

Tribu
Varios escuadrones que trabajan en unas “features” relacionadas forman una Tribu. La Tribu puede ser vista como una incubadora para las mini-startups del escuadrón. La tribu tiene un buen grado de libertad y autonomía.
Una tribu puede estar formada por 42-150 personas, pero lo ideal es que tenga un máximo de 100 individuos. Cada una de las tribus tiene un líder que es responsable de crear un entorno productivo e innovador para los escuadrones.
Los squads de una tribu están físicamente en la misma oficina y el líder de la tribu puede formar parte también de los squads.
Las tribus se reúnen con regularidad, tal vez una reunión informal en la que representan su trabajo al resto de la tribu sobre lo que han entregado y discuten las lecciones aprendidas.
Los líderes de la tribu prestan mucha atención a las dependencias de los squads y analizan hasta qué punto esas dependencias están bloqueando o ralentizando a los squads. A continuación, los líderes de la tribu discuten las formas de eliminar las dependencias problemáticas, especialmente las de bloqueo y las inter-tribales.
Algunos ejemplos de tribus en Spotify podrían ser:

Spotify Playlists Tribe
Spotify iOS App Tribe
Spotify for Artists Tribe

Representación gráfica de una Tribu

Capítulo

El capítulo es una pequeña familia de personas con habilidades similares y que trabajan en la misma área de competencia general, dentro de la misma tribu. El capítulo es una especie de pegamento que mantiene unida a la empresa, proporciona algunas economías de escala sin sacrificar demasiada autonomía.

Un capítulo se compone de individuos de diferentes squads que se agrupan en una sola y se forman dentro de una tribu. El líder de un capítulo es también un manager de los miembros del capítulo y les apoya en su crecimiento personal y en sus retos específicos.

Cada capítulo se reúne regularmente para discutir su área de expertise y sus retos específicos. El líder del capítulo también forma parte del squad y de la tribu y participa en el trabajo diario.

Algunos ejemplos de capítulos podrían ser:

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

Representación gráfica de un Capítulo

Gremio

Grupo informal constituido por personas de diferentes tribus. Un gremio es una «comunidad de intereses» más orgánica y de mayor alcance. Un gremio es un grupo de personas que comparten conocimientos, herramientas, código y prácticas. Una persona de cualquier escuadrón, capítulo o tribu puede formar parte de un gremio.

El propósito de tener un capítulo y un gremio es el mismo; asegurar la transparencia al resolver problemas y mantener a los equipos alineados y enfocados. Mientras que los capítulos son siempre locales a una tribu, un gremio suele ser transversal a toda la organización.

Un gremio suele incluir a todos los capítulos que trabajan en esa área y a sus miembros, por ejemplo, el gremio de desarrolladores web incluye a todos los desarrolladores web de todos los capítulos de desarrollo web, pero las ventajas de tener un gremio son que cualquiera que esté interesado puede unirse a cualquier gremio.

Vamos con un ejemplo para entender cómo funciona un gremio. Hay un tester de un squad concreto, digamos del escuadrón A, que está luchando con un problema.

Hay otro tester en el escuadrón B que puede resolver fácilmente el mismo problema porque ya lo ha hecho, así que si ambos están en el mismo capítulo pueden compartir su problema y encontrar una solución.

Pero si ambos no están en el mismo capítulo, entonces tendrían un gremio, es decir, un gremio de probadores, por lo que ambos probadores pueden compartir sus conocimientos y ayudarse mutuamente.

Cada capítulo se reúne regularmente para discutir su área de experiencia y discutir sus desafíos. Pero un gremio suele realizar talleres, y éstos son como un hackathon, son una actividad muy crítica para los miembros del gremio.

Representación gráfica de un Gremio

Trío

Se forma un trío cuando para cada tribu hay un diseño, un área de producto y un jefe de tribu.

Alianza

Una combinación de tres tríos forma una alianza. Está liderada por producto, diseño y un líder de tribu.

Representación gráfica de Alianza

Arquitecto Jefe

Es un miembro crítico de una organización el cual define la visión arquitectónica, guía en el diseño y se ocupa de los problemas de dependencias de la arquitectura del sistema.

Ejemplo elaborado por Deloitte

Tomemos por ejemplo a un banco como ejemplo y veamos como sus equipos podrían estar organizados.

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 raíles 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.

Distribución sobre Delegación:

Este modelo cambia en gran medida la estructura de liderazgo dentro de la empresa, especialmente porque los equipos no tienen jerarquía.

Esto puede ser una perspectiva desalentadora para todas las empresas tradicionales, ya que el modelo de Spotify requiere tener Agile Coaches para ayudar a las organizaciones a establecerlo.

Por lo general, al implantar el modelo ágil surgen las siguientes preocupaciones: ¿cómo se garantiza que los empleados no se desentiendan de sus responsabilidades? ¿Quién se encarga de delegar las tareas?

Antes de hacerse esas preguntas, hay que recordar que la adopción de procesos ágiles aumenta la productividad en un enorme 87%, por lo que la cifra en sí misma lo responde todo.

Si la productividad aumentó en un 87%, entonces es obvio que se relaciona con el equipo y sus miembros, y sólo ocurrió porque cuando se sienten motivados. Se sienten motivados porque todo el mundo está en el mismo campo de juego, trabajando por un objetivo común. Además, los procesos serán más rápidos y eficaces, y a cambio los empleados se beneficiarán de una cultura empresarial más inclusiva y dinámica.

SAFe vs Spotify

El marco SAFe es un marco lean-agile para trabajar para varios equipos scrum juntos dentro de la misma estructura. Ofrece un conjunto completo de herramientas que van desde los equipos de scrum hasta las carteras. También ofrece cursos para su implementación y certificaciones para crear coaches del marco. SAFe ofrece un marco completo y detallado que tranquiliza a sus interlocutores.

Algunos expertos lo consideran un marco demasiado detallado. SAFe te dice cómo trabajar, cómo coordinar, cómo formar y cómo ponerlo en práctica. Nos guste o no, debemos admitir que es increíblemente completo. Hay un pequeño lado lean para querer definir todo y optimizar. En general, SAFe es un marco pesado.

Spotify creó un modelo ágil a gran escala que luego se hizo muy famoso con el nombre de modelo Spotify. Sin embargo, este modelo se ha convertido en una referencia y muchas empresas se inspiran en él desde 2012. El modelo Spotify no quiere ser una gran caja de herramientas. El modelo Spotify hace hincapié en la necesidad de crear muchas interacciones para limitar la creación de silos dentro de la organización.

Por lo tanto, sólo será esencial definir cómo tiene que trabajar cada equipo de forma general, luego serán autonomos al 100%, el modelo Spotify no detalla nada a este nivel. Además, tampoco aporta ninguna solución para gestionar la cartera a diferencia de SAFe. Spotify ofrece total libertad y el equipo tiene que definirlo todo. En general, Spotify es un marco de trabajo ligero.

Beneficios y desafíos

Las bases de la Tribu Spotify es la autonomía y la confianza. Cuando hay confianza, hay propiedad y responsabilidad del trabajo realizado. La confianza ayuda a crear un entorno en el que el fracaso se toma como una oportunidad para aprender, innovar y cambiar en consecuencia. Esto también eleva la moral individual y el crecimiento. El resultado es que se obtienen los siguientes beneficios:

Beneficio 1: Autonomía

Los resultados de muchas empresas hablan por sí mismos: el trabajo autónomo es el futuro del desarrollo ágil de productos. La principal ventaja del modelo de Spotify es que los equipos pueden tomar sus propias decisiones y trabajar de la forma que más les convenga. Esto fomenta la transparencia, la confianza, la colaboración y la experimentación, lo que da lugar a mejores productos.

Beneficio 2: Menos cuellos de botella

Cuando los equipos se autogestionan y toman sus propias decisiones, pueden trabajar más rápido y evitar los cuellos de botella que hacen perder tiempo. El modelo fomenta la reunión informal y el intercambio de información, sin demasiada ceremonia ni proceso formal.

Otros beneficios:

Mayor velocidad
Los procesos se reducen al mínimo
Se abordan los retos a corto plazo
Se minimizan las dependencias
La falta de una estructura firme facilita la resolución de problemas
Control mínimo
Promueve la claridad y la transparencia
Se adapta mejor a su entorno de trabajo

Desafío: Riesgo para la arquitectura del sistema

Spotify tiene 100 sistemas distintos que forman el producto global. Cuando los equipos actualizan uno, suelen tener que actualizar varios para aplicar los cambios en los que han estado trabajando. El riesgo es que la arquitectura se puede estropear si todo el mundo se centra en una pequeña parte a la vez. Tener un System Owner, alguien (o un par de alguien) que sea dueño de la integridad de la arquitectura, mitiga este riesgo.

Desafío 2: No tiene porqué funcionar para cualquier compañía

El modelo parece fantástico desde fuera, pero optar por aplicarlo simplemente porque ha funcionado en Spotify es un error. El modelo se ajusta a la cultura de la empresa, que es mucho más difícil de cambiar que el marco que se sigue. Reorganizar la estructura de tu empresa es un gran riesgo y una gran inversión, y como el modelo de Spotify no fue diseñado para ser copiado por otras empresas, puede que no se adapte bien al tuyo.

Problemas que conlleva

Como el resto de las 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, aún 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. 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.

Conclusión

No hay perdedores ni ganadores, tanto el marco SAFe como el modelo Spotify tienen sus ventajas y desventajas. El modelo Spotify ofrece algunos conceptos interesantes que puedes utilizar.

Sin embargo, será imprescindible contar con un Agile Coach que te ayude a ponerlo en marcha. Mientras que SAFe ofrece formación y certificación para entender su marco de trabajo y para crear entrenadores que puedan guiar al equipo en el marco de trabajo.

Por un lado, Spotify ofrece total libertad al equipo para que decida su forma de trabajar y, por otro, SAFe te pedirá que sigas una serie de recomendaciones para su aplicación, lo que resulta mucho más tranquilizador por su lado de marco estricto.

La mejor opción sería utilizar una mezcla de SAFe y el modelo Spotify y puede producir un resultado muy interesante cuando mezclamos el modelo Spotify con las herramientas SAFe.

El modelo Spotify me parece diferente e innovador. Es fácil seguir un marco de trabajo o una metodología que ya está definida, pero utilizar los principios y el manifiesto ágiles para crear algo propio y que el resto empiece a seguirlo es bastante impresionante.

No existe el traje a medida, está es la solución a la que Spotify llegó tras recorrer un camino lleno de aprendizajes, cada organización debería ser capaz de recorrer el suyo propio.

Enlaces de referencia:

¿Por qué el modelo Spotify se ha hecho tan popular?