UNIVERSIDAD MAYOR DE SAN SIMÓN

FACULTAD DE CIENCIAS Y TECNOLOGÍA

DIRECCIÓN DE POSTGRADO

“SPOTIFY
FRAMEWORK DE
ESCALABILIDAD”

TRABAJO FINAL PRESENTADO PARA OBTENER EL CERTIFICADO DE

DIPLOMADO EXPERTO EN DESARROLLO DE APLICACIONES
EMPRESARIALES VERSIÓN II

POSTULANTE : MIGUEL ANGEL CLAROS ZEBALLOS

TUTOR : ING. NIBETH MENA MAMANI

Cochabamba – Bolivia
2019
 2

A mi esposa Paola por su

apoyo y soporte
en las desveladas.

A mis padres por su apoyo

incondicional en todo
momento.
 3

TABLA DE CONTENIDOS

Resumen ...................................................................................................... 6

Introducción .................................................................................................. 8

1. Generalidades ..................................................................................... 10

1.1 Antecedentes Generales .................................................................... 10

1.2 Antecedentes Específicos ................................................................... 11

2. Metodología ........................................................................................ 12

3. Frameworks de escalabilidad Ágiles ........................................................ 12

3.1 Modelo Híbrido ................................................................................. 12

3.2 SAFe ............................................................................................... 13

3.3 LeSS ............................................................................................... 15

3.4 Nexus .............................................................................................. 16

3.5 Spotify ............................................................................................ 18

3.6 Riesgos en la selección de un framework ágil ....................................... 20

3.7 Criterios de selección de un framework ágil .......................................... 20

4. Spotify Framework ............................................................................... 22

4.1 Qué es Spotify y dónde nació? ............................................................ 22

4.2 Elementos de Spotify......................................................................... 22

4.2.1 Squads (Equipos, Escuadrones)..................................................... 23

4.2.2 Tribus ........................................................................................ 24

4.2.3 Chapter (División, Departamento, Sección) .................................... 26

4.2.4 Guild (Gremio) ............................................................................ 27

4.3 Roles del Framework Spotify .............................................................. 28

4.4 Proceso de Spotify ............................................................................ 28

 4

4.5 Ventajas del Framework Spotify .......................................................... 29

4.6 Desventajas del Framework Spotify ..................................................... 30

5. Conclusiones ....................................................................................... 31

6. Recomendaciones ................................................................................ 32

Bibliografía .................................................................................................. 33
 5

TABLA DE FIGURAS

Figura 1. Modelo Híbrido ............................................................................... 13

Figura 2. Framework SAFe ............................................................................ 14

Figura 3. Framework LeSS ............................................................................ 16

Figura 4. Framework Nexus ........................................................................... 17

Figura 5. Framework Spotify.......................................................................... 18

Figura 6. Dimensión del modelo Spotify .......................................................... 19

Figura 7. Criterios de Selección de metodologías .............................................. 21

Figura 8. Squad ........................................................................................... 23

Figura 9. Tribes ........................................................................................... 25

Figura 10. Descripción de un chapter .............................................................. 26

Figura 11. Descripción de un guild.................................................................. 27

 6

RESUMEN

Desde su introducción en la década de los noventa, las metodologías ágiles de

desarrollo de software han ganado la atención de las comunidades de software, lo
cual llevó a la elaboración de muchas investigaciones que han contribuido a la
evolución de dichas metodologías, para ayudar a la adaptación de las constantes
exigencias y cambios de la industria.

La presente monografía se centrará en detallar la estructura y funcionamiento del

framework ágil Spotify, que surge por la necesidad de adaptación del método ágil a
un contexto de gran escala.

Empezaremos definiendo que las metodologías ágiles son aquellas que permiten
adaptar la forma de trabajo a las condiciones del proyecto, consiguiendo flexibilidad
e inmediatez en la respuesta para amoldar el proyecto y su desarrollo a las
circunstancias específicas del entorno. Las empresas que apuestan por estas
metodologías consiguen gestionar sus proyectos de forma flexible, autónoma y eficaz
reduciendo los costes e incrementando su productividad, usando un enfoque iterativo
basado en equipo para maximizar la entrega de valor en ciclos de corto tiempo. Con
estos métodos, los productos y servicios evolucionan rápidamente a través del
esfuerzo de colaboración de los equipos auto-organizados.

Los frameworks ágiles más conocidos son:

 Scrum
 Programación Extrema XP
 Kanban

El éxito en hacer desarrollo de software de esta manera llevó a grandes

organizaciones de nivel empresarial a escalar la práctica para satisfacer sus
necesidades. Sin embargo, el tamaño de los equipos de trabajo representa un reto
ya que resulta más difícil colaborar y coordinar esfuerzos con un grupo mayor de
personas. En 2011, Dean Leffingwell codificó SAFe, Scaled Agile Framework, para
ayudar a lograr el éxito que los pequeños equipos han tenido con varias metodologías
ágiles como Scrum o XP, adaptadas a empresas de mayor escala. Pero, las
 7

metodologías ágiles a escala no se limitan a SAFe, aunque es el marco más utilizado

en la mayoría de las organizaciones empresariales grandes. Otros métodos, marcos
y conceptos se han desarrollado e implementado con gran éxito a escala. Éstos
incluyen Spotify.

Spotify es conocido por dar un servicio de ‘streaming’ de música, podcast e incluso

vídeos. Para el desarrollo de las aplicaciones y sistemas que dan soporte a su modelo
de negocio, Spotify desarrolló su propio modelo ágil, principalmente basado en su
propia experiencia, en lo que funcionaba bien para sus equipos y sin tener un juego
de reglas claramente definido para su ejecución.

Spotify es conocido también por su estructura organizativa única, esta estructura

organizativa no está basada en pirámides jerárquicas llenas de burocracia. Spotify
usa conceptos y estructuras llamadas Squads, Tribes (tribus), Chapters y
Guilds (gremios) que son pequeños grupos interdisciplinarios auto-organizados para
administrar sus grupos de personas.
 8

INTRODUCCIÓN

En un proceso de desarrollo de software clásico, un equipo reúne esfuerzos para

diseñar el software de acuerdo a requerimientos del usuario, implementar el
software, realizar pruebas para detectar errores y realizar el mantenimiento, en el
que se pueden hacer mejoras o solucionar errores que vayan surgiendo a medida
que el producto es utilizado.

El desarrollo ágil es un marco conceptual que reconoce las distintas interacciones y

cambios que ocurren en todo proceso de desarrollo de software. Evolucionó a partir
de varios métodos que están basados en desarrollo iterativo e incremental y está
caracterizado por cuatro puntos principales que son: la planeación adaptativa,
desarrollo iterativo y evolucionario, respuesta rápida y flexible al cambio, y
comunicación. El Término "Ágil" fue definido por el "Manifiesto Ágil" en 2001.

A continuación, se presentan los principales eventos más sobresalientes en la historia

del movimiento ágil:

 En 1995 el método Scrum fue ideado por Ken Schwaber y Jeff Sutherland,
quienes lo presentaron en la conferencia OOPSLA (Object-Oriented
Programming, Systems, Languages & Applications). Como se sabe, Scrum es
prácticamente el estándar de facto para el desarrollo ágil, y consiste en dividir
los proyectos en secciones de trabajo compactas, denominadas “sprints”, que
normalmente tienen dos o tres semanas de duración, al final de las cuales, el
equipo se reúne para revisar el progreso, y planificar los siguientes pasos.
 En 1999 la Programación Extrema (XP) fue desarrollada por Kent Beck, quien
publicó el método en un libro titulado "Extreme Programming Explained".
Como parte de la Programación Extrema, también formuló los conceptos
de Historias de Usuario y Planificación de Releases. La metodología especifica
buenas prácticas para la planificación, gestión, diseño, codificación y pruebas.
 En 2001 Bob Martin, reúne a otros 16 líderes del movimiento ágil, para escribir
el "Manifiesto Ágil", que engloba las metodologías que hasta ese momento se
les conocía como "Metodologías de Desarrollo de Software de peso liviano".
 9

 En 2006 Dan North presenta su obra "Behavior Driven Development", un

método que combina las principales ideas y técnicas del TDD (Test Driven
Development) con las ideas del Diseño guiado por dominio y el Análisis y
Diseño orientado a objetivos. “El método se enfoca en proporcionar
herramientas y procesos colaborativos entre desarrolladores de software y
analistas funcionales, buscando acercar a los técnicos de software con las
necesidades que impulsan al área de negocio” (Derby & Larsen, 2007).
 En 2007 David Anderson presenta su obra "Kanban", adaptando el Kanban
para el desarrollo de software. El método se enfoca en la entrega "justo a
tiempo" y en no sobrecargar a los desarrolladores de software, tal como su
precursor el Kanban para manufactura perfeccionado por Toyota. Bajo este
enfoque, todas las tareas necesarias para entregar una funcionalidad al cliente
se muestran a los desarrolladores, quienes toman la tarea a realizar de una
cola, de forma similar al backlog definido en Scrum. El Kanban no prescribe
una serie de pasos o métodos, no existe algo como "el método de Gestión de
Proyectos Kanban", en su lugar, la intención es iniciar con los roles y procesos
que se tienen actualmente y partir de allí estimular cambios continuos,
incrementales y evolucionarios sobre el método de trabajo (PMOinformatica,
2013).

Muchos modelos de desarrollo de software implementados en distintas empresas

utilizan las metodologías ágiles para gestionar sus proyectos con el fin de gobernar
sus actividades corporativas y así dar respuesta a las necesidades cambiantes y
crecientes de sus clientes. Pero, la implementación de metodologías ágiles representa
un desafío a nivel organizativo, especialmente para grandes organizaciones ya que
estos métodos son orientados hacia las personas y centrados en la comunicación.
Entonces, ¿cómo es posible extender esta filosofía a grandes organizaciones con un
gran número de personas? Para responder a esta necesidad, se ha pensado en
frameworks para ‘escalar’ las metodologías ágiles y propagarlas de los tradicionales
equipos reducidos a equipos de trabajo más grandes. Entre los frameworks de
trabajo más utilizados se encuentran SAFe, Less y Spotify que es en el que esta
monografía se enfocará.
 10

1. GENERALIDADES

Las últimas décadas se han caracterizado por un gran crecimiento de las empresas,
tanto a nivel estructural como operacional que surge para satisfacer las demandas
de los clientes y así permanecer competitivos en el mercado. Debido a este
crecimiento, la complejidad de la gestión de los proyectos dentro de las
organizaciones ha aumentado, obligando a éstas a utilizar nuevas herramientas y
tecnologías. Es por esto que expertos en el área, han desarrollado metodologías en
la gestión de equipos y proyectos dando lugar a las metodologías ágiles que
rápidamente han ganado gran aceptación como el modelo de gestión utilizado en las
empresas.

1.1 Antecedentes Generales

Las metodologías ágiles son aquellas metodologías de gestión que nacen como
respuesta a los mercados actuales, ya que permiten adaptar la forma de trabajo al
contexto y naturaleza de un proyecto, basándose en la flexibilidad y la inmediatez y
teniendo en cuenta la evolución de los requerimientos y las circunstancias cambiantes
del mercado y los clientes. Los pilares fundamentales de las metodologías ágiles son
el trabajo colaborativo y en equipo.

El crecimiento de las organizaciones a nivel estructural implica un reto diferente al

momento de avanzar hacia métodos más ágiles debido a que involucran a un gran
número de actores y un gran número de sistemas e interdependencias que tienen
más de dos equipos de trabajo. Los métodos que les interesan a las empresas deben
ser capaces de ampliar las metodologías originales para incluir equipos más grandes,
facilitando la coordinación y supervisión de los mismos, aún si se tienen equipos que
estén trabajando en diferentes lugares físicos. Las organizaciones más grandes
normalmente quieren un acoplamiento flexible, y autonomía para que los equipos
tengan la libertad de innovar sin dejar de lado las expectativas compartidas que les
permitan cumplir con las demandas y requerimientos de los proyectos.
 11

Al igual que muchas empresas, Spotify, la gigante organización de reproducción de

música, fue creciendo y añadiendo a su equipo más y más desarrolladores para sus
diferentes plataformas de Android, iOS, web, backend. De esta ampliación fueron
emergiendo problemas de sincronización y velocidad de entrega de sus productos.
Es por eso que Spotify crea su modelo de framework ágil escalado basado en la
adaptabilidad, velocidad y escalabilidad.

1.2 Antecedentes Específicos

Scrum es la metodología más usada en los últimos años para gestionar información
y proyectos dentro de las empresas, por lo que es la metodología ágil principal y la
más destacada. Sin embargo, Scrum fue pensada para proyectos pequeños y tiene
las siguientes limitaciones:

 Funciona sobre todo con equipos reducidos. Los equipos más grandes, deben
ser divididos en grupos más pequeños con objetivos específicos, para evitar
perder el efecto de la técnica.

 Requiere definir claramente tareas y plazos. La falta de definición de estos dos

aspectos conlleva al mal funcionamiento de Scrum ya que son la esencia de
esta metodología.

 Requiere un alto nivel de formación. El éxito de esta metodología se debe a los

años de experiencia que aportan los profesionales. Por lo que equipos con
personal junior no estarían calificados para sacar adelante los proyectos.

Para organizaciones con proyectos grandes donde se requieren equipos de equipos

ubicados en diferentes zonas geográficas se presentan retos particulares ya que estos
equipos deben trabajar juntos para entregar un producto de software haciendo que
grandes grupos de personas tengan que colaborar y coordinar. De esta manera
surgen los frameworks ágiles a escala, entre los cuales el método de ingeniería de
Spotify está atrayendo a los practicantes. La noción substancial del método es la
creación de Squads autónomos pero colaborativos.
 12

Como en cualquier modelo ágil, en Spotify hay roles y agrupaciones de estos. Al

contrario que en Scrum, las agrupaciones de éstos tienen diferentes dimensiones que
se detallarán en los subtemas de Spotify.

 Squads (Equipos, Escuadrones)

 Tribus
 Chapter (División, Departamento, Sección)
 Guild (Gremio)

2. METODOLOGÍA

Las metodologías que se van a usar para esta monografía son las siguientes:

 Método Bibliográfico, debido a que se realizará la lectura y compilación de

libros y artículos relacionados al tema de estudio.
 Método Analítico, debido a que se procederá a revisar y analizar
ordenadamente los documentos relacionados al tema de estudio.

3. FRAMEWORKS DE ESCALABILIDAD ÁGILES

Ágil es un término general para usar un enfoque iterativo basado en equipos para
maximizar la entrega de valor en ciclos de tiempo rápido. Con estos marcos de
trabajo, los productos y servicios evolucionan rápidamente a través del esfuerzo y
colaboración de equipos auto organizados y multifuncionales.

Fomenta la planificación adaptativa, el desarrollo exploratorio, la entrega rápida y la

mejora continua. La respuesta rápida y flexible al cambio es el corazón del sistema.

3.1 Modelo Híbrido

Las organizaciones empresariales necesitan flexibilidad para adaptar su modelo

basándose en un conjunto de mejores prácticas organizativas que cambian con el
tiempo. Al hacer esto, es importante verificar algunas reglas clave de protección para
cumplir con los requisitos de cumplimiento y de proceso. A veces esto implica la
 13

fusión de las prácticas tradicionales de Waterfall con una metodología Ágil o fusionar
dos o más metodologías Ágiles Escaladas.

Figura 1. Modelo Híbrido

Fuente: Scaled Agile Frameworks in a Nutshell, (Elliot, 2018)

El resultado final es un marco de trabajo personalizado para satisfacer las

necesidades específicas del equipo de entrega de productos de una empresa. Al igual
que con la selección de cualquier nuevo framework o metodología, el ajuste al
propósito es importante.

3.2 SAFe

El framework SAFe (Scaled Agile Framework – Framework ágil escalado) fue

introducido en 2011 por el experto en industria de software Dean Leffingwell para
ayudar a las grandes empresas a iniciar su transformación a modelos ágiles
manteniendo su estructura organizacional. Su modelo de trabajo, facilita la
 14

obtención de una misión compartida, la coordinación efectiva y la retroalimentación

hacia niveles directivos para maximizar la probabilidad de éxito.

SAFe opera a cuatro distintos niveles (Elliot, 2018):

 Nivel Equipo: El punto inicial para la implementación de SAFe. Describe la

estructura y actividades de los equipos ágiles que construyen la solución.

 Nivel Programa: Es el corazón de SAFe para desarrollar soluciones

complejas que requieren un equipo de equipos ágiles, auto-organizados, que
planifican, se comprometen, y ejecutan juntos compartiendo una misión
común.

 Nivel Portafolio: este nivel alinea al equipo alrededor de un flujo de valor.

 Nivel Flujo de Valor: la versión más completa del framework que soporta
empresas que construyen y mantienen soluciones altamente integradas.

Figura 2. Framework SAFe

Fuente: Scaled Agile Frameworks in a Nutshell, (Elliot, 2018)
 15

Algunas ventajas de SAFe incluyen:

 Ayuda a equipos interdisciplinarios a colaborar más efectivamente.

 Ayuda a las organizaciones a lograr más transparencia.

 Alinea los aspectos del proyecto a los objetivos más generales del negocio.

Algunas de sus desventajas:

 Se cree que el framework no es puramente ágil pues requiere demasiada

planeación y definición de procesos.

 Tiene un enfoque de arriba abajo en vez de un enfoque basado en equipo.

3.3 LeSS

LeSS (Large Scale Scrum – Scrum a gran escala), es Scrum aplicado al desarrollo a
gran escala. Basado en la idea de que proporcionar demasiadas reglas, roles y
artefactos, mientras se le pide a la organización que los adapte, es fundamentalmente
defectuoso. LeSS sugiere que los marcos de escalamiento deben ser minimalistas
para impulsar el éxito.

Se divide en dos niveles (Elliot, 2018):

 LeSS regular para 2 a 8 equipos

 LeSS-Huge para 8 o más equipos. Estos niveles se construyen utilizando
equipos como el bloque de construcción de la organización.
 16

Figura 3. Framework LeSS

Fuente: Scaled Agile Frameworks in a Nutshell, (Elliot, 2018)

3.4 Nexus

El framework Nexus fue creado por el co-autor de Scrum Ken Schwaber en 2015 y
está basado en el framework de Scrum extendiéndolo mínimamente. Permite que
múltiples equipos Scrum trabajen colaborativamente en una sola cartera de
productos para entregar por lo menos un incremento integrado completo cada
sprint. Nexus recomienda entre tres y nueve equipos para mejorar la cohesión y
reducir la complejidad. El límite mayor puede ser ligeramente mayor, lo cual no
impide el buen funcionamiento de la metodología dependiendo de las circunstancias.
 17

Figura 4. Framework Nexus

Fuente: The NexusTM Guide, (Bourk & Kong, 2016)

Las adiciones principales de Nexus a Scrum son (Bourk & Kong, 2016):

 Un artefacto adicional: El backlog de sprint de Nexus que es el plan de

Nexus para el sprint para saber en qué trabajan los equipos y hace que las
dependencias entre equipos sean transparentes.

 Cinco eventos adicionales: Refinación, Planeación de sprint Nexus, Scrum

diario de Nexus, Revisión de sprint de Nexus y el Retrospectivo de sprint de
Nexus. Estos eventos extendidos ayudan a asegurar que el trabajo se divida
y coordine a través de los equipos Scrum de la manera más efectiva.

 Remueve la revisión de sprint de equipo de Scrum reemplazándola por la

Revisión de sprint de Nexus ya que los equipos trabajan en un sólo incremento
integrado que debe ser revisado como un todo.

 Añade un nuevo rol: El Equipo de Integración de Nexus o Nexus Integration

Team (NIT) que promueve la responsabilidad transparente para la integración
en un Nexus. El NIT está conformado por el dueño del producto, el Scrum
Master y otros miembros NIT que pueden ser miembros temporales de otras
 18

áreas funcionales como operaciones, seguridad, arquitectura, etc. que pueden

ayudar a que el Nexus entregue el incremento integrado.

3.5 Spotify

Spotify es un marco de trabajo autónomo orientado hacia las personas para escalar
metodologías ágiles. Destaca la importancia de la cultura y de las redes
(comunicación entre equipos).

Figura 5. Framework Spotify

Fuente: Scaled Agile Frameworks in a Nutshell, (Elliot, 2018)

Spotify utiliza Tribus (Tribes), Escuadrones (Squads), Capítulos (Chapters) y Gremios

(Guild). El fundamento del framework es el Squad, que actúa como un equipo Scrum.
El Squad se auto-organiza, y determina la mejor manera de trabajar, desde Scrum
Sprints a Kanban o un enfoque híbrido (Kniberg & Ivarsson, Scaling Agile @ Spotify,
2012). El Squad se enfoca en un solo producto y un solo proyecto. Un Product Owner
prioriza y gestiona el trabajo atrasado de la plantilla mientras un entrenador ágil
trabaja con ellos para acelerar la transformación. Una Tribu es un grupo de Squads
que están trabajando en un área común. La Tribu está conformada por Squads y es
 19

limitada a 100 personas. Los Chapters forman parte de un Squad y son un grupo de
miembros de equipos que trabajan juntos. Por último, está el Guild, que son un grupo
de personas con intereses comunes.

Mientras más alineados estén, mayor autonomía tendrán. El trabajo del líder es
comunicar cuál es el problema a resolver y explicar el por qué los miembros del
equipo deben colaborar entre sí para encontrar la solución. Nadie está fuera, todos
participan.

Figura 6. Dimensión del modelo Spotify

Fuente: Spotify: Una cultura AGILE, (Sanchez, 2017)

Uno de los beneficios de trabajar así es un tipo de estandarización (creada por ellos),
al que llaman CROSS-POLLINATION (Como las abejas cuando polinizan las flores).
Cuando un Squad usa una herramienta o una buena práctica, ésta se transmite a
otros y así se convierte en algo estandarizado. Esta “polinización” genera un balance
entre consistencia y flexibilidad.
 20

3.6 Riesgos en la selección de un framework ágil

A pesar que cada metodología ágil escalada tiene excelentes características, ninguna
compañía puede elegir cualquiera sin correr riesgos que pongan en peligro la
consecución de sus objetivos. Cada empresa es diferente, y una metodología que
funcione bien en una empresa, no garantiza que es la metodología correcta para otra
empresa. Es por eso, que cada empresa debe evaluar las necesidades únicas para
implementar la metodología correcta, o adecuar una para satisfacer los
requerimientos.

Existen principalmente dos riesgos que las organizaciones pueden correr si eligen una
metodología inadecuada que son:

- Alta complejidad en la sincronización entre equipos: la implementación de

metodologías ágiles escaladas puede crear capas adicionales de administración
y coordinación. Éstas se implementan para resolver problemas que los equipos
con diferentes cadencias y dependencias puedan tener, sin embargo, podrían
ocasionar que los procesos se retrasen y se limite la flexibilidad que las
metodologías ágiles proveen.

- Reducción de tiempo para refactorización e innovación: de igual manera,

los tiempos requeridos para coordinación y administración de los equipos,
pueden significar la reducción de tiempo que los equipos pueden utilizar para
refactorizar código y/o implementar nuevas ideas.

3.7 Criterios de selección de un framework ágil

Al momento de decidir qué metodología funciona mejor para cada caso, la selección
dependerá de muchas variables, pero hay una serie de pautas que se pueden seguir
para ayudar a elegir:

- Existen muchas dependencias internas? Sin importar cómo se organicen los

equipos, siempre existirán dependencias y es esencial saber manejarlas.
 21

- Existen muchas dependencias externas? Las condiciones externas a las que

se pueda someter un proyecto también deben considerarse.

- Existe una necesidad alta de creatividad en innovación en el desarrollo? La

metodología debe tomar en cuenta cuán importante es dar flexibilidad para
crear e implementar nuevas ideas.

Responder a estas preguntas puede ayudar a elegir un framework que ayude a

reducir los riesgos anteriormente mencionados.

Figura 7. Criterios de Selección de metodologías

Fuente: Agile at Scale: Frameworks to Use (& When to Use Them), (Karlsson,
2017)

En base a estos criterios, podemos implementar SAFe y Spotify de la siguiente

manera:

- SAFe – Altas dependencias, baja necesidad de innovación.

 22

SAFe prioriza la coordinación y alineación entre equipos adicionando de esta

manera más tiempo y recursos para coordinar el trabajo, lo cual ayuda a
manejar las dependencias, pero reduce el tiempo para innovar.

- Spotify - Alta necesidad de innovación, bajas dependencias.

Los squads de Spotify son autónomos y son capaces de manejar todo desde el
diseño, desarrollo y testing hasta la entrega a producción
independientemente. El modelo Spotify les da el poder a los equipos para que
los desarrolladores puedan dar rienda suelta a su creatividad y así poder
innovar.

4. SPOTIFY FRAMEWORK

A continuación, se desarrollará a detalle Spotify como framework de escalabilidad.

4.1 Qué es Spotify y dónde nació?

Spotify es un servicio de música, podcasts y vídeos digitales en streaming que da

acceso a millones de canciones y otros contenidos de artistas de todo el mundo.

Originada por su fundador Daniel Ek, quien lanzó la aplicación el 23 de abril de 2006,
es una compañía que está transformando la industria de la música. La compañía tiene
más de 217 millones de usuarios activos, de los cuales, más de 100 millones usan el
servicio de pago (Wikipedia, n.d.).

La compaña fue creciendo, por lo que lidiar con múltiples equipos en el desarrollo de
su producto se convirtió en un reto, pero Spotify como compañía siempre ha
mantenido una mentalidad ágil a pesar de haber escalado a más de 30 equipos en 3
ciudades.

4.2 Elementos de Spotify

Los elementos de Spotify son los siguientes:

 23

4.2.1 Squads (Equipos, Escuadrones)

La unidad básica de desarrollo en Spotify es el Squad.

Figura 8. Squad

Fuente: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, (Kniberg &
Ivarsson, Scaling Agile @ Spotify, 2012)

Un squad es similar a un equipo Scrum, y está diseñado para sentirse como un mini-
startup. Se sientan juntos, y ellos tienen todas las habilidades y herramientas
necesarias para diseñar, desarrollar, probar y lanzar un producto a producción. Son
un equipo auto-organizado y deciden su propia manera de trabajar, algunos usan
Scrum sprints, Kanban, otros utilizan una combinación de estos enfoques.

Cada squad tiene una misión a largo plazo, por ejemplo, construir y mejorar el cliente
Android, crear la experiencia en radio de Spotify, escalar los sistemas backend o
proporcionar soluciones de pago. Lo ideal es que cada equipo sea totalmente
autónomo, con contacto directo con las partes interesadas sin dependencias que
bloqueen a otros escuadrones.

Debido a que cada equipo se adhiere a una parte del producto con una misión durante
mucho tiempo, ellos pueden convertirse en expertos en esa área. La mayoría de los
 24

escuadrones tienen un espacio de trabajo que incluye un área de escritorio y un área

de reunión personal.

Un squad no tiene un líder de squad nombrado formalmente, pero sí tiene un product

owner. El product owner es responsable de priorizar el trabajo a realizar por el
equipo, pero no está involucrado en la forma en que el equipo hace su trabajo. Los
product owners de los diferentes equipos colaboran entre sí para mantener un
documento de planeación que muestra hacia dónde se dirige Spotify en su conjunto,
y cada product owner es responsable de mantener una cartera de productos
adecuada para su squad.

Un equipo también tiene acceso a un entrenador, que le ayuda a evolucionar y a

mejorar su forma de trabajar. Los entrenadores realizan retrospectivas, reuniones de
planificación de sprint, entrenamientos individuales, etc.

Un squad podría equivaler a un equipo de scrum de menos de 10 personas, el equipo

puede seguir un framework kanban, Scrum sprint, XP o una mezcla de ellos para
llevar a cabo sus deberes, con el fin de tener releases lo más antes y más a menudo
posible.
A pesar de contar con autonomía, es necesario tener a los squads alineados mediante
la misión, la estrategia de producto y usar metas a corto plazo.

4.2.2 Tribus

Una tribu es un conjunto de escuadrones que trabajan en áreas relacionadas, como

el reproductor de música o la infraestructura de backend.
 25

Figura 9. Tribes

Fuente: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, (Kniberg &
Ivarsson, Scaling Agile @ Spotify, 2012)

Las tribus son una estructura matricial bastante ligera que agrupan a los squads y
pretenden mantenerlos bajo el foco de un producto. Se puede decir que agrupan a
los squads bajo un paraguas de negocio, por ejemplo, el desarrollo de funcionalidades
relativas a la aplicación móvil que la compañía ofrece a sus clientes.

Los escuadrones de una tribu están todos físicamente en la misma oficina,

normalmente uno al lado del otro para fomentar la colaboración entre las escuadras,
y la metodología sugiere tener las zonas de descanso cerca.

El tamaño de las tribus se basa en el concepto del "número Dunbar", que dice que la
mayoría de la gente no puede mantener una relación social con más de 100 personas.
En realidad, el número es mayor para los grupos que están bajo una intensa presión
de supervivencia, lo que no es el caso en Spotify. Cuando los grupos se hacen
demasiado grandes, empezamos a ver más cosas como reglas restrictivas y
 26

burocracia. Así que las tribus están diseñadas para tener un número menor a 100
personas.

Las tribus celebran reuniones con regularidad, una reunión informal donde muestran
al resto de la tribu en lo que están trabajando, lo que han entregado o algo que otros
pueden aprender. Esto incluye demostraciones en vivo de software de trabajo,
nuevas herramientas y técnicas, etc.

4.2.3 Chapter (División, Departamento, Sección)

Al nivel horizontal de la organización funcional existen los chapters también conocidos

como especialistas. Un chapter consiste de individuos de la misma área pero de
diferentes squads que se agrupan y se forman dentro de una tribu.

Figura 10. Descripción de un chapter

Fuente: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, (Kniberg &
Ivarsson, Scaling Agile @ Spotify, 2012)
 27

Cada chapter se reúne regularmente para discutir su experiencia y sus retos

específicos. Los chapters están dirigidos por un chapter lead, que es también un
gerente en línea de los miembros de un chapter y tiene las responsabilidades clásicas
como ser el desarrollo profesional, apoyo en crecimiento personal grupal, soporte
para superar retos específicos, establecimiento de salarios, etc. Pero, el líder
también es parte de una escuadra y, por lo tanto, está involucrado en las actividades
diarias de la misma.

4.2.4 Guild (Gremio)

Un guild es un grupo informal constituido por personas de diferentes tribus quienes

tienen un interés común.

Figura 11. Descripción de un guild

Fuente: Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds, (Kniberg &
Ivarsson, Scaling Agile @ Spotify, 2012)
 28

Esta organización, que es más parecida a una comunidad de interés, agrupa personas
de toda la compañía que quieren compartir conocimiento en un área específica. Es
una comunidad abierta, cualquiera puede unirse al gremio o salir de él en cualquier
momento y cada persona puede decidir cuán activo o inactivo es en cada uno de los
gremios a los que está adscrito. Cada guild tiene un coordinador que se encarga de
organizar actividades de intercambio de conocimiento, discusiones, y los famosos
talleres de guilds como hackatons, etc.

El propósito de tener chapters y guilds es el mismo, asegurar la transparencia a

través de la resolución de problemas y mantener a los equipos alineados y enfocados.

4.3 Roles del Framework Spotify

Spotify promueve que los empleados muestren liderazgo personal. Sin embargo, hay
algunas personas que tienen roles de liderazgo más formales. Estos son:

- Chapter lead: es responsable por el ciclo de rendimiento y el desarrollo

personal de los miembros del chapter. El chapter lead también lleva a cabo sus
tareas diarias del squad.

- Tribe lead: es responsable de crear un ambiente productivo e innovador

para los squads, y también puede ser parte de un squad.

- Agile coach: tiene una posición especial, dirige las sesiones de

retrospección, stand-ups, demostraciones y planeación de sprints. Apoya a
varios equipos para que colaboren y apliquen las reglas. Se encarga de
entrenar, monitorear, estimular y motivar a los miembros del equipo.

4.4 Proceso de Spotify

El proceso de Spotify carece de estandarización, es decir que no tiene un standard

formal. Utilizan un modelo de trabajo llamado polinización cruzada que, de acuerdo
a ellos, es mejor que la estandarización. La polinización cruzada se refiere a que
cuando un squad encuentra una herramienta, y la usa de manera eficiente en su
 29

equipo, esa herramienta puede transmitirse a los demás squads. Una vez que los
otros equipos usan la herramienta y, en colaboración, encuentran la mejor forma de
implementarla, es cuando la herramienta se convierte en un estándar por defecto
otorgando así el balance entre consistencia y flexibilidad.

Spotify emplea un modelo interno de código abierto, su cultura es más compartir que
poseer. Basado en el respeto mutuo y poco ego, Spotify tiene un sistema de revisión
de código de pares, en el que cualquiera puede añadir cualquier código en cualquier
momento. Entonces un compañero de equipo puede revisar el código y hacer ajustes,
es decir que todos colaboran y difunden el conocimiento. También tienen una cultura
que se centra en la motivación, lo que les ha ayudado a construir una muy buena
reputación como lugar de trabajo.

4.5 Ventajas del Framework Spotify

La base fundamental de Spotify como framework ágil es la autonomía y la

confianza. Cuando existe confianza, existe responsabilidad de hacer el trabajo,
además la confianza ayuda a crear un ambiente en el cual una falla se vea como una
oportunidad de aprender, innovar y cambiar, incrementando el crecimiento personal
y elevando la moral del equipo. Esto resulta en los siguientes beneficios:

- Velocidad mejorada

- Reducción de procesos

- Resolución de retos de corto plazo

- Dependencias mínimas

- La falta de una estructura firme hace que se puedan resolver los problemas
más fácilmente

- Control mínimo

- Promueve la claridad y la transparencia

- Se adapta al ambiente de trabajo

 30

4.6 Desventajas del Framework Spotify

La noción substancial del método es la creación de squads autónomas pero

colaborativas, pero debido a que éste carece de una investigación científica es difícil
determinar cómo las organizaciones pueden mantener un balance que permita tener
squads poco acopladas pero muy alineadas.

Además, la metodología cambia todo el tiempo ya que la gente en Spotify aprende y

descubre nuevas cosas a medida que la compañía crece y surge la necesidad de
adaptar la forma de trabajo continuamente.

Spotify nació en Suecia alineándose a la cultura local que se basa en el bienestar de

las personas y el deseo de autonomía de las funciones. Ésta se diferencia a la de
otros lugares, lo que significa que la metodología puede no funcionar adecuadamente
debido a la falta de alineación con la cultura del lugar (Zen Ex Machina, 2017).
 31

5. CONCLUSIONES

Las empresas necesitan optimizar sus procesos al máximo y así garantizar su posición
en el mercado para lo cual las metodologías ágiles escaladas van tomando cada vez
más protagonismo.

En esta monografía hemos explorado la evolución de las metodologías ágiles a

frameworks escalados que se adapten a las necesidades de las empresas de mayor
tamaño. El análisis reveló una serie de factores que influyen en la manera en que
las empresas deben adaptar las metodologías ágiles para que funcionen en
estructuras organizativas más complejas. Principalmente, el framewok ágil Spotify
fue detallado demostrando que puede ser aplicado a empresas con una estructura
organizada y con objetivos claros para mejorar la coordinación y el trabajo en equipo.

Entre las diferentes metodologías ágiles escaladas, destaca Spotify que propone una
solución en la cual los equipos se organizan por squads (escuadrones) que son
pequeños grupos que tienen autonomía para desarrollar el software sin interferir con
otros equipos. Todos los squads están caracterizados por tener una alineación hacia
un fin común.

Las compañías pueden ganar mucho si adoptan el modelo de Spotify en términos de

rendimiento y de organización gracias a la cultura positiva y a la forma en que
enfocan el trabajo. Sin embargo, cada compañía debe tener su propio enfoque para
adaptar una metodología a sus necesidades, ya que la selección de un framework
ágil inadecuado, tiene riesgos que pueden poner en peligro la consecución de los
objetivos.

Con el entendimiento claro de los riesgos de sincronización de equipos y tiempo de

innovación, las empresas pueden prepararse para implementar un enfoque ágil
escalado que les ayude a maximizar los beneficios de la metodología, sin importar el
tamaño del equipo, del proyecto o la complejidad del mismo.
 32

6. RECOMENDACIONES

 Las empresas deben implementar metodologías de gestión de proyectos que

garanticen la satisfacción de las demandas cambiantes de los requerimientos
de los clientes y la necesidad de entregar el producto rápidamente.

 Cada empresa debe ver la metodología que mejor se adapte a sus necesidades.

 Las metodologías ágiles escaladas son las que se sugieren para empresas de
mayor tamaño, pero éstas deben ver cuál metodología se adapta mejor a sus
necesidades.

 Para la implementación del modelo Spotify, cada empresa debe analizar el

mismo para adaptarlo a su forma de trabajo, caso contrario la implementación
podría resultar en un fracaso.
 33

BIBLIOGRAFÍA

Bahadur, B. (7 de Septiembre de 2017). Scaling Agile@Spotify. Obtenido de

Temenos+Agility: https://www.visiontemenos.com/blog/what-is-scaling-agile

Bourk, S., & Kong, P. (Junio de 2016). An Introduction to the Nexus™ Framework.
Obtenido de ScrumOrg: https://scrumorg-website-
prod.s3.amazonaws.com/drupal/2016-
06/An%20Introduction%20to%20the%20Nexus%20Framework%20-
%20June%202016_0.pdf

Curso en Madrid. (s.f.). Ventajas y debilidades de Scrum. Obtenido de Curso en

Madrid: http://curso-madrid.es/ventajas-y-debilidades-de-scrum/

Derby, E., & Larsen, D. (2007). Agile Retrospectives: Making Good Teams Great.
Pragmatic Bookshelf.

Elliot, S. (2018). Scaled Agile Frameworks in a Nutshell. AgileCraft. Obtenido de

https://cdn2.hubspot.net/hubfs/534906/AgileCraft%20eBook%20-
%20Scaled%20Agile%20Frameworks%20in%20a%20nutshell.pdf

Karlsson, J. (2 de Abril de 2017). Agile at Scale: Frameworks to Use (& When to Use
Them). Obtenido de Perforce: https://www.perforce.com/blog/hns/agile-
scale-frameworks-use-when-use-them

Kendis. (23 de Julio de 2018). Exploring Key Elements of Spotify’s Agile Scaling
Model. Obtenido de Kendis: https://kendis.io/spotify/exploring-key-elements-
spotifys-agile-scaling-model/

Kezmo. (20 de Marzo de 2017). ¿Qué son las metodologías ágiles y por qué debes
implementarlas en tu organización? Obtenido de Kezmo:
https://blog.kezmo.com/qu%C3%A9-son-las-metodolog%C3%ADas-
%C3%A1giles-y-por-qu%C3%A9-debes-implementarlas-en-tu-
organizaci%C3%B3n-484a510e5b0

Kniberg, H. (Octubre de 2017). Scaling Agile @ Lego & Spotify. Obtenido de Crisp's
Blog: https://blog.crisp.se/wp-content/uploads/2017/10/Scaling-Agile-at-
LEGO-and-Spotify.pdf

Kniberg, H., & Ivarsson, A. (Octubre de 2012). Scaling Agile @ Spotify. Obtenido de
Crisp's Blog: https://blog.crisp.se/wp-
content/uploads/2012/11/SpotifyScaling.pdf

PMOinformatica. (2013 de Junio de 2013). Una breve historia de las metodologías

ágiles. Obtenido de PMOinformatica:
http://www.pmoinformatica.com/2013/06/una-breve-historia-de-las-
metodologias.html
 34

Roche, J. (s.f.). Introducción al modelo 'agile' de Spotify. Obtenido de Deloitte:

https://www2.deloitte.com/es/es/pages/technology/articles/introduccion-
modelo-agile-spotify.html

Roldan Arellano, U. (2015). TRABAJO FIN DE MASTER: AGILE IT PROJECT

MANAGEMENT PROFESSIONAL. Madrid: UNIVERSIDAD POLITECNICA DE
MADRID.

Salemeh, A., & Bass, J. (2018). Influential factors of aligning Spotify squads in
missioncritical and offshore projects - a longitudinal embedded case study.
Conference or Workshop Item. Manchester: University of Salford.

Sanchez, L. (11 de Octubre de 2017). Spotify: Una cultura AGILE. Obtenido de

Comunicador Millenial:
http://comunicadormillennialpro.com/index.php/2017/10/11/spotify-una-
cultura-agile/

Secarranta, M. (6 de Agosto de 2018). Usos y limitaciones de la metodología Scrum.

Obtenido de EAE Business School: https://retos-directivos.eae.es/usos-y-
limitaciones-de-la-metodologia-scrum/

Wikipedia. (s.f.). Spotify. Obtenido de Wikipedia:

https://en.wikipedia.org/wiki/Spotify

Zen Ex Machina. (2017). Why Spotify’s agile patterns work and why you shouldn’t
copy them. Obtenido de Zen Ex Machina – The blog:
https://zenexmachina.wordpress.com/2017/07/25/why-spotifys-agile-
patterns-work-and-why-you-shouldnt-copy-them/