Framework Escalado Spotify

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. 

3.3

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

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 ministartup. 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-websiteprod.s3.amazonaws.com/drupal/201606/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/agilescale-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-elementsspotifys-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-tuorganizaci%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-atLEGO-and-Spotify.pdf Kniberg, H., & Ivarsson, A. (Octubre de 2012). Scaling Agile @ Spotify. Obtenido de Crisp's Blog: https://blog.crisp.se/wpcontent/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-lasmetodologias.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/introduccionmodelo-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-unacultura-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-ylimitaciones-de-la-metodologia-scrum/ Wikipedia. (s.f.). Spotify. https://en.wikipedia.org/wiki/Spotify

Obtenido

de

Wikipedia:

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-agilepatterns-work-and-why-you-shouldnt-copy-them/