Caso Spotify

Caso Spotify

Uno de los factores clave de éxito en Spotify es la cultura de ingeniería ágil. La cultura tiene que ser invisible, no la notamos porque está ahí siempre. Pero si todo el mundo entiende la cultura, es más fácil de mantener y fortalecerla a medida que crecemos. Ese es el propósito del video.

Cuando se lanzó el primer reproductor de música en 2008, la empresa era Scrum. Scrum es un enfoque de desarrollo ágil bien conocido y establecido, lo que dio una buena cultura de equipo. Sin embargo, en algunos años después, crecieron en muchos equipos y algunas de las practicas de Scrum se volvieron impedimentos, así que se decidieron por hacerlas opciones.

Las reglas son un buen comienzo, pero tenemos que romperlas si es necesario. Decidieron que la agilidad es más importante que scrum y que los principios agiles son más importantes que cualquier practica específica. Así que cambiaron el nombre de “Scrum Master” a “Coach Ágil” poque querían ser lideres servidores mas que maestros del proceso. También empezaron a utilizar el termino “escuadrón” en lugar de “equipo de scrum” y la autonomía se convirtió en su fuerza motriz.

¿Qué es un escuadrón autónomo?

Es un equipo pequeño autoorganizado y multifuncional de 8 personas que se sientan juntos y tienen responsabilidad de punta a cabo por lo que hacen: diseños, compromisos, despliegues, mantenimiento, operaciones, todo. Cada equipo tiene una misión a largo plazo, por ejemplo “hacer de Spotify el mejor lugar para descubrir la música” o temas internos como “infraestructura para pruebas A/B”.

Autonomía significa que el escuadrón decide que hacer, como hacerlo y como trabajar juntos. Por supuesto hay algunos limites tales como la misión del escuadrón, la estrategia general del producto según sea el área en que este trabajando y las metas de corto plazo, que son renegociadas cada trimestre.

La oficina se esta optimizando para la colaboración.

En una zona típica de escuadrón, los miembros trabajan cercanamente con mesas ajustables y un fácil acceso a las pantallas de cada uno. Después hay un espacio para cosas como sesiones de planificación y retrospectiva. Y hay una sala pequeña de reuniones o simplemente para un momento de tranquilidad. Casi todas las paredes son pizarras.

¿Por qué la autonomía es tan importante?

Porque es motivante y la gente motivada hace cosas mejor. También la autonomía nos hace más rápidos permitiendo que las decisiones se produzcan en forma local en el escuadrón en vez de ir a través de una gran cantidad de gerentes, comités, etc. Ayuda a minimizar los traspasos y esperas, entonces se puede escalar sin empantanarse en dependencias y coordinación.

Si bien cada escuadrón tiene su propia misión, necesitan estar alineados con la estrategia de producto, las prioridades de negocio y otros escuadrones. Básicamente ser bueno ciudadanos en el ecosistema de Spotify.

La misión general de Spotify es mas importante que la misión de un equipo en particular. Así que, el principio clave es “ser autónomo” pero no “sub-optimizar”. Es como una banda de jazz, si bien cada musico es autónomo y toca su propio instrumento, escuchan el uno al otro y se centran en la música como un todo. Así es como se crea la buena música.

Así que el objetivo es tener escuadrones leventemente acoplados, pero altamente alineados. Todavía no llegaron allí, pero se experimentan distintas formas de estar mas cerca.

Lo que se muestra en el video es una mezcla de lo que son hoy y lo que quieren llegar a ser en el futuro.

Alineamiento y autonomía pueden parecer polos opuestos de una misma escala, como si más autonomía implicase menos alineamiento. Sin embargo, se cree que son dos dimensiones diferentes.

[pic 1]

Abajo se tiene bajo alineamiento y baja autonomía, una cultura miserable, sin metas de alto nivel, solo “cállate y sigue las órdenes”.

En el cuadrante alto rendimiento y baja autonomía, los lideres son buenos para comunicar cual es el problema que hay que resolver, pero también dicen a la gente como resolverlos.

Alta autonomía y alto alineamiento significa que los lideres se centran en cuales son los problemas que deben ser resueltos, pero dejan que el equipo decida como resolverlos.

En el cuadrante bajo alineamiento y alta autonomía implica que los equipos hacen lo que quieren y van en diferentes direcciones. Los lideres son imponentes y nuestro producto se convierte en un “Frankenstein”.

La idea es llegar a una alta autonomía y un alto alineamiento, una autonomía alineada y se siguen probando diferentes maneras de llegar a eso.

Entonces el alineamiento permite autonomía, cuanto más alineamiento tenemos, más autonomía se puede otorgar. Eso significa que el trabajo del líder es comunicar que problema hay que resolver y por qué. Y los escuadrones trabajan entre si para encontrar la mejor solución.

Una consecuencia de la autonomía es que tenemos muy poca estandarización. Cuando las personas preguntan cosas como ¿Qué editor utilizar? O ¿ como planificar? La respuesta suele depender del escuadrón, algunos usan Sprint (scrum), otros Kanban, algunos estiman user stories y miden velocidad y otros no lo hacen. Es el escuadrón quien decide. En lugar de normas formales tiene una fuerte cultura de inter-polinizacion. Cuando suficientes escuadrones utilizan una práctica o herramienta en particular, como Git, ella se convierte en el camino de menor resistencia y otros equipos tienden a adoptarla. Los escuadrones comienzan a apoyar la herramienta y a ayudarse entre si, y se convierte en un estándar de facto. Este enfoque informal nos ofrece un sano equilibrio entre consistencia y flexibilidad.

La arquitectura se compone de un centenar de sistemas separados, codificados y desplazado de forma independiente. Interactúan, pero cada sistema se centra en una necesidad específica, como gestionar las listas de reproducción, búsqueda o monitoreo. Se trata de mantenerlos pequeños y desacoplados, con interfaces y protocolos bien definidos. Técnicamente cada sistema es propiedad de un escuadrón especifico, pero, de hecho, la mayoría de los escuadrones tienen varios. Pero internamente tienen un modelo de código abierto y su cultura es más sobre compartir que poseer. Supongamos que el escuadrón 1 necesita algo que se hace en el sistema B y el escuadrón 2 conoce ese código bien, normalmente 1 le pide a 2 que lo haga. Pero si el equipo 2 no tiene tiempo o tiene otras prioridades, entonces el escuadrón 1 no necesita esperar, en su lugar dedican el código ellos mismos y luego piden al equipo 2 que revisen los cambios. Por eso tienen una cultura de revisión de código por pares. Esto mejora la calidad y lo más importante, expande el conocimiento. Con el tiempo evolucionamos guías para diseño, estándares de codificación, y otras cosas para reducir fricción en la ingeniería, pero solo cuando es realmente necesario. Así, es una escala de autoridad a liberal y definitivamente estamos en el lado liberal.

...