Versión en español del artículo "Scaling  Agile  @  Spotify with  Tribes,  Squads,  Chapters  &  Guilds" de Henrik Kniberg, disponible en http://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

1. Traducido por Manuel Palacio el 30/11/2012
Corregido por Agustín Villena 18/05/2015
Agilidadagranescalaen Spotify
con Tribus, Escuadrones, Capítulos y Gremios
Henrik Kniberg & Anders Ivarsson
Octubre2012
¡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 alguien que ha logrado desarrollar este tipo de organización. Llevo buscando desde 1992”
¿Y cómo se ha llevado esto acabo?
Hemos hecho presentaciones en conferencias y tenido conversaciones interesantes sobre cómotrabajamos en
Spotify y sobre cómola compañía maneja proyectos con cientos de desarrolladores de una maneraágil. Amucha
gente le fascina como lo hacemos asíque nos decidimos a escribir un artículo sobre el tema.
Limitación de responsabilidad:Spotify está,comocualquiercompañía ágil, evolucionando rápido. Esteartículo
es sólo un apunte de cómoson las cosas actualmente, un viaje en cursoy no un viaje acabado. Seguramente,
para cuando leáis esto, las cosas ya serán distintas.

2. Escuadrones
La unidad básicade desarrollo en Spotify es el escuadrón (squad).
Un escuadrón está diseñada para ser como una especie de mini-empresa (start-up). Los miembros del
escuadrón trabajan juntos y tienen la preparación y las herramientas necesarias para diseñar, desarrollar,
probar y hacer el lanzamiento del producto. Una escuadrón es como un equipo que se organiza a sí mismo y
decide cómo trabajar – algunas usan sprints como en Scrum, algunas Kanban y otras una mezcla de los dos.
Cada escuadrón tiene una misióna largo plazo comopor ejemplo desarrollar y mejorar el cliente de Android,
crear la radio de Spotify, escalar los sistemas backend o proveer soluciones de pago. La imagen inferior muestra
como distintos equipos se responsabilizan de distintas partes de la experiencia del usuario.

3. Las escuadrones aplican principios Lean como PMV (Producto Mínimo 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 escuadrón tiene una misión y es responsable de una parte del producto durante mucho un
periodo prolongado al final los miembros se convierten en expertos en esa área – por ejemplo en qué se
necesita para crear una experiencia de radio fantástica. La mayoría de las escuadrones tienen una zona de
trabajo amplia,un salón y un área privada. Casi todas las paredes tienen pizarras. ¡Nunca hemos visto un
espacio de colaboración mejor!
Es un tiburón volando. Perfectamente normal.

4. Para promover el aprendizaje y la innovación se intenta que cada escuadrón invierta
aproximadamente el 10% de su tiempo en días de “hacking”. Durante este tiempo los miembros
del escuadrón pueden centrarseen lo que deseen, normalmente esto será probar nuevas ideas y
compartir lo aprendido con los otros miembros.Algunas escuadrones hacen un día de hacking
cada dos semanas y otras van ahorrando días hasta que tienen una semana entera disponible.
Los días de hacking 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.
Los escuadrones 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 escuadrones colaboran para tener un documento que contenga
información sobre qué dirección está 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 escuadrón
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 escuadrón es totalmente autónoma, tiene contacto directo con las partes interesadas y no
depende de otros escuadrones. Básicamentees como una pequeña compañía. Con más de 30
escuadrones esto es todo un desafío y todavía quedan muchas mejoras querealizar.
Para que todo sea más fácil, hacemos una encuesta a cada escuadrón cada trimestre. Esto nos
ayuda a poner énfasis en las mejoras adecuadas y decidir qué tipo de apoyo es el óptimo. A
continuación, mostramos un resumende una de las encuestas que muestra los resultados de 5
equipos dentro de una de las tribus:
Los círculos muestranel estado actual y las flechas la tendencia. Por ejemplo, se aprecia una
tendencia en la que tres escuadrones tienen problemas con el lanzamiento a producción y eso no
parece mejorar – ¡esta área necesita atención urgente! También vemos que el escuadrón número
4 no tiene una buena situación con su coach pero eso estámejorando.
 Propietariode producto (ProductOwner) –El escuadróntiene unpropietariode productoque da
prioridadal trabajodesde unpuntodel valorque aporta a la empresaperotambiénteniendoen
cuentaaspectostécnicos.
 Coach Ágil – La escuadróntiene un“entrenador”oagile coachque lesayudaa identificar
problemasya mejorarsu formade trabajo continuamente.

5.  Influenciasenel trabajo – Cada miembro del escuadrónpuede influenciarsupropiotrabajo,tomar
parte en laplanificaciónyelegirque tareasalas que dedicarse. Cadamiembropuedeinvertirel 10%
de su tiempoenexperimentarconnuevastecnologíasoprobarnuevasideas.
 Fácil de lanzar – La escuadrónpuede hacerlanzamientosaproducciónde manerasencillaylomás
independienteposible.
 Proceso ensintoníacon el equipo– La escuadrónesresponsable de elegir,mantenerymejorar
continuamente suformade trabajar.
 Misión– La escuadróntiene unobjetivoque cadamiembroconoce,lastareasenla listade
“pedidos”obacklogestánrelacionadasconlaobjetivo/misión.
 Soporte organizacional – El escuadrónsabe a quiéndirigirsepararesolverproblemas,yaseanestos
de carácter técnicoode carácter organizacional.
Tribus
Una tribu está compuesta de equipos que trabajan en áreas relacionadas – como el reproductor
de músicao infraestructura de tipo backend.
La tribu es la incubadora de los equipos mini-empresa y, como ya hemos mencionado, tiene
bastante libertad y autonomía. Cada tribu tiene un líder que es responsable de proveer el hábitat
mejor posible para las escuadrones en esa tribu. Los escuadrones de una tribu están todas
localizados en la misma oficina y normalmente cerca unas de otras. Las áreas comunes (salones)
promueven la colaboración entre escuadrones.
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

6. o menos (este número es mayor si los grupos se encuentran bajo presión para sobrevivir pero
este no es el casoen 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óny 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 quieraasistir 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 escuadrones
Con múltiples escuadrones siempre habrá dependencias entre ellas. Las dependencias no son
necesariamentealgo negativo – algunas veces varios escuadrones tienen que trabajar juntas
para desarrollar realmente fantástico.Sin embargo, nuestro objetivo es tener escuadrones 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 escuadrones y hasta qué punto esto supone un problema o una manera
menos efectiva de trabajar. Aquí tenemos un ejemplo:

7. A continuación discutimos maneras de eliminar las dependencias problemáticas, especialmente si
sonentre tribus. Esto trae como resultado una re-evaluación de prioridades, reorganización y
cambios en la arquitecturao soluciones técnicas.
La encuesta nos ayuda a ver dónde están localizadas las dependencias entre escuadrones – por
ejemplo comoel trabajo de varios escuadrones 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 (escuadrones) 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

8. Para que esto funcione, los escuadrones 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 los diferentes escuadrones 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”.
grande que requería el trabajo coordinado de varias escuadrones durante unos
meses.

9. Es una manera informal de colaboración basada en la comunicación personal en vez de
intercambiar documentos detallados describiendo el proceso.
Capítulos y gremios
Todotiene 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 el
escuadrón Apodría tener un problema que otro ingeniero en el escuadrón 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 escuadrón es totalmente autónomo 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 capítulos y gremios. Este es el pegamento que mantiene a la
compañía unida y nos da la posibilidad de escalar el número de escuadrones sin sacrificar
demasiado la autonomía.
El consejo es la pequeña familia donde los miembros poseen competencias similares.A su vez,
los capítulos (chapters) pertenecen a una tribu con el mismoperfil global de competencia.

10. 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 líder del consejo es responsable de los miembros. Entre sus responsabilidades se incluyen
asignar salarios y asegurarse de que cada miembrose desarrolla adecuadamente dentro de la
asociación. Sin embargo, el líder del consejo está también involucrado en el trabajo diario. Esto
se hace para que no pierda el contacto con la realidad como suele suceder en otrascompañías.
La realidad es siempremás complicadaque bonitas imágenes como la de arriba. Por ejemplo,
los miembros del consejo no están distribuidos de forma uniforme en las escuadrones; algunas
escuadrones 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 capítulos 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.

11. Un gremio suele incluir a todas los capítulos trabajando en esa área y a sus miembros. Por
ejemplo el gremio de test incluye a todos los ingenieros de pruebas en todos los capítulos 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.

12. Unmomento, ¿no esestounaorganizació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. Esaes 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 del escuadrón sepa qué hacer y cómo hacerlo
bien.

13. 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.
¿Yquéocurreconlaarquitectura?
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.

14. 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 aproducció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énhace
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 sistemasiempre la toma el escuadrón.
¿Cómo 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 escuadrones, tribus, capítulos 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. Estén atentos, esta historia no ha terminado :o)
/Henrik &Anders
henrik.kniberg@spotify.com www.crisp.se/henrik.kniberg
anders.ivarsson@spotify.com