Traducido por Manuel Palacio el 30/11/2012
Corregido por Agustín Villena 18/05/2015
Agilidad a gran escala en Spotify
con Tribus, Escuadrones, Capítulos y 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 alguien 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 cómo 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.
Escuadrones
La unidad básica de 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ó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 imagen inferior muestra
como distintos equipos se responsabilizan de distintas partes de la experiencia del usuario.
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.
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 centrarse en 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ásicamente es como una pequeña compañía. Con más de 30
escuadrones 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 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 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 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.
Propietario de producto (Product Owner) – El escuadrón 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.
Coach Ágil – La escuadrón 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 del escuadrón 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 escuadrón puede hacer lanzamientos a producción de manera sencilla y lo más
independiente posible.
Proceso en sintonía con el equipo – La escuadrón es responsable de elegir, mantener y mejorar
continuamente su forma de trabajar.
Misión – La escuadrón tiene un objetivo que cada miembro conoce, las tareas en la lista de
“pedidos” o backlog están relacionadas con la objetivo/misión.
Soporte organizacional – El escuadrón sabe a quién dirigirse para resolver problemas, ya sean estos
de carácter técnico o de carácter organizacional.
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 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
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 escuadrones
Con múltiples escuadrones siempre habrá dependencias entre ellas. Las dependencias no son
necesariamente algo 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:
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 escuadrones – por
ejemplo como el 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
grande que requería el trabajo coordinado de varias escuadrones durante unos
meses.
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”.
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
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 el
escuadrón A podrí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 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 líder 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 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 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 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.
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.
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 del escuadrón 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 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
[Link]@[Link] [Link]/[Link]
[Link]@[Link]
