Traducido por Manuel Palacio el 30/11/2012

Agilidad a gran escala en Spotify

con Tribus, Brigadasi, Consejosii & Gremios

Henrik Kniberg & Anders Ivarsson

Octubre 2012

¡Trabajar con múltiples equipos en una organización que desarrolla productos es siempre un desafío!

Uno de los ejemplos más interesantes que hemos observado hasta ahora es Spotify que ha conseguido
mantener una mentalidad ágil a pesar de haber crecido hasta tener más de 30 equipos en 3 ciudades diferentes.

Spotify es una compañía fascinante que está transformando la industria musical. La compañía fue creada hace 6
años y ya tiene más de 15 millones de usuarios de los cuales 4 millones son de pago. El producto se parece a un
“reproductor mágico de música en el cual puedes encontrar y escuchar casi cualquier canción del mundo”.

Alistair Cockburn (uno de los fundadores del movimiento de desarrollo ágil de software) visitó Spotify y dijo “Por
fin encuentro a alquien que ha logrado desarrollar este tipo de organización. Llevo buscando desde 1992”

¿Y cómo se ha llevado esto a cabo?

Hemos hecho presentaciones en conferencias y tenido conversaciones interesantes sobre cómo trabajamos en
Spotify y sobre cómo la compañía maneja proyectos con cientos de desarrolladores de una manera ágil. A mucha
gente le fascina como lo hacemos así que nos decidimos a escribir un artículo sobre el tema.

Limitación de responsabilidad: Spotify está, como cualquier compañía ágil, evolucionando rápido. Este artículo
es sólo un apunte de como son las cosas actualmente, un viaje en curso y no un viaje acabado. Seguramente,
para cuando leáis esto, las cosas ya serán distintas.
Brigadas
La unidad básica de desarrollo en Spotify es la brigada (squad).

Una brigada está diseñada para ser como una especie de mini-empresa (star-tup). Los miembros de la brigada
trabajan juntos y tienen la preparación y las herramientas necesarias para diseñar, desarrollar, probar y hacer el
lanzamiento del producto. Una brigada es como un equipo que se organiza a si mismo y decide cómo trabajar –
algunas usan sprints como en Scrum, algunas Kanban y otras una mezcla de los dos.

Cada brigada tiene una misión a largo plazo como por ejemplo desarrollar y mejorar el cliente de Android, crear la
radio de Spotify, escalar los sistemas backend o proveer soluciones de pago. La imágen inferior muestra como
distintos equipos se responsabilizan de distantas partes de la experiencia del usuario.
Las brigadas aplican principios Lean como PMV (Producto Minimo Viable) y aprendizaje validado. PMV
presupone lanzamientos a menudo y aprendizaje validado presupone realizar mediciones y pruebas con grupos
(A/B) para ver qué funciona y qué no. Esto se resume en el eslogan “Imagina, construye, lanza, retoca”.
Dado que cada brigada tiene una misión y es responsible de una parte del producto durante mucho un periodo
prolongado al final los miembros se convierten en expertos en ese área – por ejemplo en qué se necesita para
crear una experiencia de radio fantástica. La mayoría de las brigadas tienen una zona de trabajo amplia, un
salón y un área privada. Casi todas las paredes tienen whiteboards. ¡Nunca hemos visto un espacio de
colaboración mejor!

Es un tiburón volando. Perfectamente normal.

Para promover el aprendizaje y la innovación se intenta que cada brigada invierta aproximadamente el 10% de
su tiempo en dias de “hack”. Durante este tiempo los miembros de la brigada pueden centrarse en lo que deseen,
normalmente esto será probar nuevas ideas y compartir lo aprendido con los otros miembros. Algunas brigadas
hacen un día de hack cada dos semanas y otras van ahorrando días hasta que tienen una semana entera
disponible. Los días de hack son una oportunidad perfecta para ponerse al día con distintas herramientas y
técnicas. Es normal que durante estos días se produzcan algunas innovaciones importantes relativas al producto
o la manera de trabajar.
Las brigadas no tienen un líder formal pero tienen un propietario del producto (Product Owner). El propietario de
producto es el responsable de crear las prioridades del trabajo que se va a realizar pero no influencia para nada
la manera de trabajar del equipo. Los propietarios de producto de diferentes brigadas colaboran para tener un
documento que contenga información sobre que dirección esta adoptando la compañía y cada propietario es
responsable de mantener la lista de “pedidos” (backlog) con el trabajo a realizar por su equipo. La brigada
también tiene acceso a un “entrenador” o “agile coach” que les ayuda a efectivizar su forma de trabajo. Los
entrenadores son los encargados de organizar las reuniones retrospectivas, planificar los sprint, realizar
preparaciones individuales, etc.

Cada brigada es totalmente autónoma, tiene contacto directo con las partes interesadas y no depende de otras
brigadas. Básicamente es como una pequeña compañía. Con más de 30 brigadas esto es todo un desafío y
todavía quedan muchas mejoras que realizar.

Para que todo sea más fácil, hacemos una encuesta a cada brigada cada trimestre. Esto nos ayuda a poner
énfasis en las mejoras adecuadas y decidir que tipo de apoyo es el óptimo. A continuación, mostramos un
resumen de una de las encuestas que muestra los resultados de 5 equipos dentro de una de las tribus:

Los círculos muestran el estado actual y las flechas la tendencia. Por ejemplo, se aprecia una tendencia en la que
tres escuadras tienen problemas con la el lanzamiento a producción y eso no parece mejorar – este area necesita
atención urgente! También vemos que la brigada número 4 no tiene una buena situación con su coach pero eso
está mejorando.

● Propietario producto – La brigada tiene un propietario de producto que da prioridad al trabajo desde un
punto del valor que aporta a la empresa pero también teniendo en cuenta aspectos técnicos.

● Agile coach – La brigada tiene un “entrenador” o agile coach que les ayuda a identificar problemas y a
mejorar su forma de trabajo continuamente.

● Influencias en el trabajo – Cada miembro de la brigada puede influenciar su propio trabajo, tomar parte
en la planificación y elegir que tareas a las que dedicarse. Cada miembro puede invertir el 10% de su tiempo en
experimentar con nuevas tecnologías o probar nuevas ideas.

● Fácil de lanzar – La brigada puede hacer lanzamientos a producción de manera sencilla y lo más
independiente posible.

● Proceso en sintonía con el equipo – La brigada es responsable de elegir, mantener y mejorar

continuamente su forma de trabajar.
 ● Misión – La brigada tiene una objectivo que cada miembro conoce, las tareas en la lista de “pedidos” o
backlog están relacionadas con la objetivo/misión.

● Soporte de organización – La brigada sabe a quién dirigirse para resolver problemas, ya sean estos de
carácter técnico o de carácter organizatorio.
Tribus
Una tribu está compuesta de equipos que trabajan en áreas relacionadas – como el reproductor de música o
infraestructura de tipo backend.

La tribu es el incubador de los equipos mini-empresa y, como ya hemos mencionado, tiene bastante libertad y
autonomía. Cada tribu tiene un líder que es responsible de proveer el habitat mejor posible para las brigadas en
esa tribu. Las brigadas de una tribu estan todas localizados en la misma oficina y normalmente cerca unas de
otras. Las áreas comunes (salones) promueven la colaboración entre brigadas.

El tamaño de las tribus está basado en el concepto de “Dunbar number”, que sostiene que la mayoría de los
humanos no pueden mantener una relación social con más de 100 personas más o menos (este número es
mayor si los grupos se encuentran bajo presión para sobrevivir pero este no es el caso en Spotify lo creáis o
no…). Cuando los grupos se hacen demasiado grandes comenzamos a ver comportamientos como la
introducción de restricciones, burocracia, juegos de política, más administración y otros desaprovechamientos.

Por eso, las tribus están diseñadas para tener menos de 100 miembros.
Las tribus se reúnen con regularidad y de manera informal para mostrar a las otras tribus o a quien quiera asistir
lo que están haciendo en ese momento, lo que han lanzado en producción y lo que opinan que otros podrían
aprender de cómo se han hecho las cosas. Esto incluye realizar demostraciones de software, nuevas
herramientas y tecnologías u otros proyectos o ideas interesantes que han surgido durante el tiempo de trabajo
libre (hack days).

Dependencias entre brigadas

Con múltiples brigadas siempre habrá dependencias entre ellas. Las dependencias no son necesariamente algo
negativo – algunas veces varios brigadas tienen que trabajar juntas para desarrollar realmente fantástico. Sin
embargo, nuestro objetivo es tener brigadas lo más autónomas posible y con mínimas dependencias que les
impidan realizar su trabajo con eficiencia.

Para poder hacer esto, realizamos encuestas con regularidad para identificar cuáles son las dependencias entre
brigadas y hasta que punto esto supone un problema o una manera menos efectiva de trabajar. Aquí tenemos un
ejemplo:
A continuación discutimos maneras de eliminar las dependencias problemáticas, especialmente si son entre
tribus. Esto trae como resultado una re-evaluación de prioridades, reorganización y cambios en la arquitectura o
soluciones técnicas.
La encuesta nos ayuda a ver dónde están localizadas las dependencias entre brigadas – por ejemplo como el
trabajo de varias brigadas está siendo retrasado por el equipo de operaciones. Usamos un diagrama muy simple
para visualizar si las dependencias aumentan o disminuyen con el paso del tiempo.

Scrum tiene una práctica llamada “scrum of scrums”, una manera de sincronización entre grupos para identificar
dependencias. Normalmente esta práctica no se usa mucho en Spotify ya que la mayoría de los grupos
(brigadas) son bastante independientes.

Pero lo que si puede ocurrir es que se use si alguien lo pide. Por ejemplo hace poco tuvimos un proyecto muy
grande que requería el trabajo coordinado de varias brigadas durante unos meses.

Para que esto funcione, las brigadas tenían una reunión diaria donde se identificaban y resolvían estas
dependencias entre ellas.
El típico ejemplo de dependencias entre distintos grupos es desarrollo con operaciones. En la mayoría de
compañías en las que hemos trabajado lo común es tener algún tipo de traspaso entre desarrollo y operaciones
lo que normalmente implica retrasos en el lanzamiento a producción.

En Spotify tenemos un equipo de operaciones pero su trabajo no es realizar lanzamientos en producción sino dar
el soporte que necesitan a las diferentes brigadas para que el lanzamiento lo realicen ellas; soporte en forma de
infraestructura, scripts, y rutinas. Su misión es “asfaltar la carretera que lleva al lanzamiento”.

Es una manera informal de colaboración basada en la comunicación personal en vez de intercambiar

documentos detallados describiendo el proceso.
Consejos y gremios
Todo tiene desventajas y uno de los mayores inconvenientes de tener autonomía total es tener más dificultad a la
hora de escalar la comunicación entre grupos. Un ingeniero de pruebas en la brigada A podría tener un problema
que otro ingeniero en la brigada B resolvió la semana pasada. Si todos los ingenieros de pruebas de todos los
equipos pudieran reunirse podrían compartir sus conocimientos y crear herramientas y soluciones a problemas
comunes para beneficio de todos.

Por otro lado, si cada brigada es totalmente autónoma y no se comunica con otras para qué queremos una
compañía? Se podría dividir Spotify en 30 compañías pequeñas.

Esta es la razón de la existencia de consejos y gremios. Este es el pegamento que mantiene a la compañía unida
y nos da la posibilidad de escalar el número de brigadas sin sacrificar demasiado la autonomía.

El consejo es la pequeña familia donde los miembros poseen competencias similares. A su vez, los consejos
(chapters) pertenecen a una tribu con el mismo perfil global de competencia.

Cada consejo se reúne regularmente para discutir sobre su área de competencia y sobre los desafíos que se
presentan – por ejemplo, el consejo de test, el consejo de desarrollo web o el de sistemas backend.

El lider del consejo es responsable de los miembros. Entre sus responsabilidades se incluyen asignar salarios y
asegurarse de que cada miembro se desarrolla adecuadamente dentro de la asociación. Sin embargo, el lider del
consejo está también involucrado en el trabajo diario. Esto se hace para que no pierda el contacto con la realidad
como suele sueceder en otras compañías.

La realidad es siempre más complicada que bonitas imágenes como la de arriba. Por ejemplo, los miembros del
consejo no están distribuidos de forma uniforme en las brigadas; algunas brigadas tienen bastantes
desarrolladores web y otras ninguno. El gráfico sólo da una idea general.
Un gremio es una comunidad de interés orgánica, un grupo de personas que quieren compartir conocimientos,
código, herramientas o maneras de hacer las cosas. Los consejos son siempre son parte de una tribu mientras
que los gremios se extienden por toda la organización. Algunos ejemplos son: el gremio de tecnología web, el
gremio de test, el gremio de coaching, etc.

Un gremio suele incluir a todas los consejos trabajando en ese área y a sus miembros. Por ejemplo el gremio de
test incluye a todos los ingenieros de pruebas en todas los consejos de test pero cualquiera que tenga interés
puede unirse a un gremio.

Cada gremio tiene un coordinador. Como ejemplo de lo que suele hacer un gremio, hace poco hicimos una “No
conferencia de gremio web”, un espacio abierto para que todos los desarrolladores web de Spotify se pudieran
reunir en Estocolmo para discutir soluciones y desafíos en esta área.
Otro ejemplo es el gremio de “coaching”. Los “entrenadores” o “coaches” están esparcidos por toda la
organización pero se reúnen a menudo para colaborar en las mejoras de organización las cuales reflejamos
visualmente.

Un momento, ¿no es esto una organización

matricial?
Sí. Más o menos pero es un poco distinta de lo que se suele ver en otras compañías.

En muchas organizaciones matriciales a la gente con similares competencias se les suele poner en la misma
bolsa, todos juntos en departamentos funcionales, los llamados silos, reflejando una manera de pensar analítica.

Spotify hace esto muy raramente. Nuestra matriz está orientada a algo muy práctico: el lanzamiento a
producción.

Esto significa que la gente está agrupada en equipos estables y localizados en el mismo lugar. En ellos, gente
con distintas competencias puede colaborar y auto-organizarse para crear un gran producto. Esa es la dimensión
vertical de la matriz y es la primaria ya que es donde se pasa la mayor parte del tiempo.

La dimensión horizontal es para compartir conocimientos, herramientas y código. La misión del líder de la
asociación es facilitar esto.
En términos de matriz, se considera a la dimensión vertical como el “qué” y la horizontal como el “cómo”. La
matriz hace posible que cada miembro de la brigada sepa qué hacer y cómo hacerlo bien.

Esto es la idea del “profesor y del emprendedor” que recomiendan Mary and Tom Poppendieck. El PO (Product
Owner) es el emprendedor, cuyo interés es lanzar un gran producto mientras que el líder del consejo es el
profesor o líder de competencia, con un enfoque de excelencia técnica.

Hay una tensión saludable entre estos dos roles: el emprendedor quiere darse prisa y ahorrar lo más posible
mientras que el profesor quiere tomarse su tiempo y hacer las cosas correctamente. Estos dos aspectos son
necesarios.
¿Y qué ocurre con la arquitectura?
La tecnología de Spotify está orientada a servicios. Tenemos más de 100 sistemas distintos y cada uno de ellos
puede ser mantenido y lanzado a producción de manera separada. Esto incluye servicios como el de las listas de
reproducción o el de búsquedas o pagos y clientes como el reproductor del iPad y componentes específicos
como la radio o la sección de “novedades” del reproductor.

En la práctica, cualquiera tiene permiso para hacer cambios en cualquier sistema. Normalmente en el desarrollo
de una nueva función un equipo va a tener que hacer cambios en varios sistemas. El riesgo con este modelo es
que la arquitectura de un sistema sufra si nadie se ocupa de la integridad de ese sistema y de que los múltiples
cambios empeoren la organización interna del sistema en cuestión.

Para disminuir ese riesgo tenemos un rol que es el de “system owner” o “propietario de sistema”. Todos los
sistemas tienen un propietario o una pareja de propietarios (mejor). Para sistemas críticos el propietario del
mismo es un pareja dev-ops, es decir, una persona con la visión de desarrollo y otra con la de operaciones.

El propietario del sistema es la persona que puede contestar a las preguntas técnicas o de arquitectura del
sistema en cuestión. Es el coordinador y guía los cambios para que no se produzcan errores. Su prioridad es
pues, calidad, documentación, disminuir deuda técnica, estabilidad, escalabilidad y mejorar el proceso de
lanzamiento a producción.

El propietario del sistema no es un cuello de botella ni un arquitecto aislado de la realidad. No hace todos los
cambios personalmente ni tiene que tomar todas las decisiones ni ocuparse de cada lanzamiento a producción.
El típico propietario de sistema es un miembro de un equipo o un líder de asociación que tiene otras
responsabilidades aparte de esa. Sin embargo, de vez en cuando se tomará un día de “propietario” para hacer
limpieza en el sistema. Normalmente esto no debe llevar más de una décima parte del tiempo de esa persona
pero puede variar.

Por último, también tenemos el rol del arquitecto jefe, que es la persona que coordina el trabajo en cuestiones de
arquitectura de alto nivel que afectan a varios sistemas. También hace revisiones de sistemas nuevos para
asegurarse que no se repiten antiguos errores y que están alineados con la visión arquitectónica. De todas
formas, al final, todo son sugerencias. La decisión final de como diseñar el sistema siempre la toma la brigada.
¿Qué tal está funcionando todo esto?
Spotify ha crecido muy rápido – en 3 años hemos crecido de 30 a 250 personas en el área de tecnología – ¡y
esto tiene su complejidad! Este modelo – con brigadas, tribus, consejos y gremios – es algo que hemos
introducido gradualmente durante el pasado año así que todavía nos estamos acostumbrando. Hasta ahora, y
basándonos en encuestas parece que está funcionando bastante bien ya que a pesar del crecimiento tan rápido
la satisfacción de los empleados sigue aumentando: en abril del 2012 era 4.4 de 5.

Sin embargo, como ocurre en cualquier organización en crecimiento las soluciones de hoy dan lugar a
obstáculos el día de mañana. Estad atentos, esta historia no ha terminado :o)

/Henrik & Anders

henrik.kniberg@spotify.com www.crisp.se/henrik.kniberg
anders.ivarsson@spotify.com
i
En el documento original el término usado es “Squad”.
ii
En el documento original el término usado es “Chapter”.