Sociedad Neo

Agile, la filosofía empresarial de Daniel Ek que ha llevado a Spotify a lo más alto: “Su éxito tiene que ver con el estado mental, la cultura y el liderazgo”

Big Tech

El método de trabajo de Spotify es un ejemplo perfecto de cómo las grandes empresas tecnológicas trabajan en la actualidad

El abusivo sistema laboral 996 se pone de moda en Silicon Valley: “Es la velocidad de trabajo que se necesita para ganar”

Daniel Ek, fundador de Spotify.

Daniel Ek, fundador de Spotify.

Reuters

No es secreto para nadie que la empresa sueca Spotify es responsable de uno de los cambios de paradigma más importantes de las últimas décadas en la industria musical. El servicio de streaming ha moldeado, por completo, la manera en la que escuchamos música y la forma en la que descubrimos artistas.

Pero, más allá de ofrecer un servicio que fue extraordinariamente innovador y rupturista para el momento, gran parte del éxito de Spotify puede tener que ver, también, con su manera de desarrollar la propia aplicación y relacionarse con sus usuarios. La start-up fundada por Daniel Ek y Martin Lorentzon es uno de los ejemplos más exitosos del modelo de desarrollo ágil de software.

El modelo de desarrollo ágil de software —casi siempre llamado modelo o “filosofía agile”— se popularizó a principios de los años 2000, especialmente tras la popularización del Manifiesto por el Desarrollo Ágil de Software, una publicación firmada por más de una decena de profesionales del desarrollo de software que buscaban implementar formas organizativas dentro del entorno de trabajo que fuesen más flexibles que las tradicionales.

Agile, la filosofía empresarial de Daniel Ek que ha llevado a Spotify a lo más alto.
Agile, la filosofía empresarial de Daniel Ek que ha llevado a Spotify a lo más alto.Diseño: Selu Manzano

El agile busca —como indica su nombre— agilizar los procesos de desarrollo para satisfacer a los clientes de una manera más personalizada. En lugar de mantener un control minucioso sobre el progreso de cada parte del desarrollo, se busca separar cada parte del desarrollo en unidades más pequeñas que facilitan la flexibilidad y la adaptación a las nuevas circunstancias o requisitos que vayan surgiendo.

La manera de Spotify de interpretar esos principios es una muy particular, que se traduce en una estructura organizativa específica y sin precedentes para el momento que muchas otras empresas han intentado implementar más tarde.

El agile busca agilizar los procesos de desarrollo para satisfacer a los clientes de una manera más personalizada

Para muchos, esta estructura es precisamente el motivo por el cual la empresa de streaming ha sido capaz de adaptarse a las necesidades de sus usuarios de manera rápida, y lo que le ha facilitado ocupar un lugar tan importante en una industria tan exigente y tan competitiva. 

Hasta el año 2012, Spotify apostaba por un modelo de desarrollo scrum, una rama de la filosofía agile que se centra en la incrementalidad. En lugar de planificar, por ejemplo, el desarrollo completo de una aplicación, se divide la acción en distintas tareas pequeñas que se van creando en paralelo por distintos equipos. Cada equipo se encarga de una parte de la tarea, evitando que se generen “atascos” o que se paralice la producción si alguna de ellas no funciona como debería o requiere cambios.

Pero cuando la plataforma empezó a popularizarse a nivel mundial, y la empresa comenzó a crecer y expandirse rápidamente a varios países y varias sedes, la metodología antigua parecía no estar siendo lo suficientemente eficiente. Así, el consultor Henrik Kniberg planteó una remodelación completa de la estructura de trabajo de la empresa sueca basándose en principios agile que facilitó manejar más de treinta equipos, distribuidos en tres ciudades distintas, y que se ha seguido aplicando de manera progresiva conforme Spotify ha crecido en la última década.

Según el propio Kniberg, la prioridad en aquel momento era “que los equipos se movieran con rapidez, que enviaran el software lo más rápido posible, con el mínimo de dolor y gastos generales”. Así, se reorganizó a los trabajadores en “escuadrones”: equipos autoliderados y, en principio, autosuficientes, capaces de idear y desarrollar ideas sin necesidad de apoyos externos. 

Toma aérea de parques de viviendas y oficinas en Redwood City al amanecer.
Toma aérea de parques de viviendas y oficinas en Redwood City al amanecer.Getty Images

“Cada escuadrón funciona como una ministartup. Se sientan juntos y tienen todas las habilidades y las herramientas necesarias para desarrollar, probar y lanzar funcionalidades. Cada escuadrón tiene la libertad de decidir su propio modelo de trabajar”. Por ejemplo, un escuadrón se encargaría de mejorar el cliente de Android y otro, de gestionar la interfaz, o las pasarelas de pago de la plataforma.

Aunque los escuadrones no tendrían un líder explícito, sí habría un “responsable de producto” en cada uno de ellos, que sería la persona encargada de priorizar tareas y de reportar a sus superiores sobre el progreso de cada funcionalidad.

Los escuadrones están, a su vez, agrupados en “tribus”. Las tribus se componen de escuadrones que se encargan de tareas y funcionalidades de áreas similares, o que funcionan en conjunto. Cada tribu debería tener “menos de 100 personas”, porque “cuando los grupos se hacen demasiado grandes, aumentan las reglas restrictivas, la burocracia, la política y el desorden”. El líder de cada tribu tiene la responsabilidad de comprobar y dirigir el progreso de cada escuadrón.

A partir de este punto, la dificultad que se planteaba era evidente: si cada equipo funcionaba de manera autónoma, era más difícil mantener una serie de valores, ideas y consistencia en los desarrollos. Además, había un problema con las redundancias: “podría haber un tester en el equipo A que está peleándose con resolver un problema que otro tester, en el equipo B, ya resolvió la semana pasada”.

Los capítulos están conformados por personas con las mismas áreas de competencias, y que pertenecen a la misma tribu, pero que trabajan en distintos escuadrones

Para evitar este tipo de dinámicas, Kniberg creó un tipo extra de organización: los capítulos. Los capítulos están conformados por personas con las mismas áreas de competencias, y que pertenecen a la misma tribu, pero que trabajan en distintos escuadrones. Por ejemplo: todos los desarrolladores web de una tribu, o todos los programadores de esta conformarían un capítulo.

Cada capítulo tendría, a su vez, un líder. El grupo realizaría reuniones frecuentes para ponerse al día sobre los desafíos y progresos a los que se están enfrentando en el presente. “El líder de cada capítulo es un mánager para sus miembros, con todas las responsabilidades tradicionales, como motivar a la gente o establecer los salarios. Pero, a su vez, también es parte de un escuadrón, y se involucra en el trabajo del día a día, lo que le mantiene en contacto con la realidad”.

Esta compleja estructura es la que permitió a la empresa sueca pasar de tener apenas 100 empleados a los más de 7.000 que tiene hoy en día. Aun así, e incluso si el modelo de Kniberg parecía perfectamente funcional en papel, muchos de los involucrados en esta transformación reconocen que, con los años, se han hecho muchos cambios para adaptarse a las nuevas necesidades.

Al mismo tiempo, cientos de empresas han intentado adoptar modelos similares con resultados variados; en ocasiones, fracasando de manera drástica. En palabras de Joakim Sunden, uno de los expertos que trabajó en Spotify y ayudó a implementar el modelo: “en la práctica, su éxito tiene mucho más que ver con el estado mental, la cultura y el liderazgo de la empresa. Esas cosas la hacen diferente y hacen que funcione, pero es difícil de observar y entender”.

Periodista graduada en la Universidad de Zaragoza y especializada en videojuegos, tecnología retro, y tener demasiadas plumas estilográficas. También me podéis ver en Eurogamer.