1/22/2013

Organización de equipos en Spotify: implementación del modelo "profesor y emprendedor"


En Octubre del año pasado salió en prensa un artículo que hizo algo de ruido en la comunidad de empresas de tecnología. En él se explicaba con cierto detalle la forma en la que Spotify, la empresa que ofrece el servicio de música por internet mediante subscripción, organizaba sus equipos de desarrollo. En su momento me lo leí rápidamente, pero tras repasarlo, creo que merece la pena, para aquellos que no se lo hayan leído todavía, ver un resumen de lo que hacen. Como siempre, recomiendo leer la fuente original. Pero oye, son catorce páginas algo densas, y a mí me ha costado 4 meses leerlas con algo de detalle, así que no juzgo a nadie :D

Spotify es un buen ejemplo de empresa con crecimiento a toda velocidad y que tiene que transformar la teoría del agilismo en una realidad. 

La unidad básica de desarrollo en Spotify es el "Pelotón". Básicamente es un cambio de nombre a lo que desde hace tiempo se conoce como un equipo Scrum. Se organizan de manera independiente, tienen objetivos comunes, y son los responsables de que un proyecto salga bien. En el caso de Spotify, puede ser un pelotón que desarrolle la primera versión del cliente Android. Pero pueden centrarse aún más: implementación de la radio en Spotify, escalado del back-end, etc. Lo que es importante, sobre todo para ver cómo resuelven los desafíos relacionados después, es que se consideran equipos independientes, con sus áreas trabajo independientes. 

Cada pelotón tiene, tal y como ocurre con Scrum, un propietario de producto. Esto no difiere mucho de Scrum. El propietario prioriza el roadmap de su producto, mantiene un listado de tareas pendientes, pero, lo que es más importante, es quien habla con otros propietarios de producto de otros pelotones. Esto permite que exista una hoja de ruta acordada entre los diferentes grupos. 

Hasta ahora, todo bastante estándar si habéis leído algo de metodologías ágiles. 

Spotify crea una superestructura de pelotones, denominada Tribus. Una tribu es un conjunto de pelotones que trabajan en áreas relacionadas: el reproductor de música, o la infraestructura de sistemas de back-end. Imagino que cómo se relacionan es una cuestión peliaguda: ¿qué nivel de funcionalidad? ¿qué nivel de abstracción? Pero siguiendo una metodología ágil, podemos equivocarnos unas cuantas iteraciones hasta encajar lo que queremos.

Aunque cada pelotón está en un área de trabajo independiente, cada tribu tiene que estar físicamente en el mismo sitio. Hay un líder de la tribu que es quien se encarga de que esto se cumpla. No puede haber más de 100 personas en una tribu.

Primer punto, a mi juicio, interesante. Las dependencias entre pelotones de una misma tribu se analizan. Es decir, como al final todo pelotón depende de otros (por ejemplo porque ha de utilizar sus interfaces de entrada, o porque se requieren unas pruebas compartidas, o porque sistemas tiene que instalar algo), se crea un documento de dependencias para saber si esas relaciones funcionan bien o hay algún problema. Me hace gracia ver en el documento que uno de los ejemplos que se ponen sobre dependencias complicadas es entre un pelotón de desarrollo del reproductor de música y... el departamento de operaciones (sí, el que provee máquinas, conexiones, etc., y que siempre está hasta arriba, da igual que hablemos de IBM o de Spotify). Hay cosas que son complicadas de cambiar.


Segundo punto, que vuelve a afirmar mi convicción de que en cuestiones organizativas hace tiempo que está todo dicho, sólo cambia la dinámica de implantación. Obviamente no tiene sentido crear tribus independientes si no hablan entre sí. Para ello, se crean estructuras horizontales, o capítulos, que aglutinan a todos los miembros de pelotones de una tribu que trabajan en la misma área de competencia: la gente de pruebas, la de desarrollo en HTML5, ... Sí me ha parecido atractivo que el líder de cada capítulo es, en nomenclatura "pre-web", el responsable de línea: es decir, el que se ocupa de recursos humanos, salarios, carreras profesionales, etc. Es curioso cómo en un documento organizativo como éste, la primera vez que aparece este rol es hacia la mitad del texto. Aquí sí que parece que las cosas han cambiado. El proyecto es lo primero, y la asignación funcional, después. Sí parece que la tribu, en Spotify, es el elemento más independiente de todos. Con 100 personas por tribu como máximo, tiene sentido. 

Un paso más es el concepto de Gremio, que agrupa a miembros de diferentes tribus en intereses comunes. Suelen ser agrupaciones de capítulos similares, pero admiten a cualquier persona de Spotify interesada en esa área concreta.


El título de este post se explica a continuación. Hace tiempo leí sobre un modelo organizativo que me interesó mucho, pues estaba muy relacionado con las cosas que estaba intentando hacer en Denodo en aquella época. Aparecía en el libro "Leading Lean Software Development", de Mary y Tom Poppendeck, y mencionaba que hay dos roles en cualquier organización: el que empuja hacia que las cosas se hagan a tiempo, y el que empuja el que las cosas se hagan bien. El equilibrio entre ambas fuerzas es lo que determina el tipo de resultados que se conseguirían. Un sólo perfil difícilmente conseguirá que se optimice esta relación, pues al final cada uno es como es. En aquella época mi desafío personal era conseguir mantener lo que yo consideraba que era el nivel mínimo de calidad en nuestras tareas diarias, pero subiendo el nivel de excelencia en cuanto a resultados. 

Spotify resuelve eso con su concepto de líder de capítulos, que es quien se encarga de que las cosas se hagan adecuadamente, la gente se forme en lo que necesita formarse, etc. Mientras, el propietario de producto es la persona que quiere ver resultados. 

Lo malo de estas estructuras matriciales es que, al final, hay que meter parches. Y aquí el parche se llama propietario del sistema. Evidentemente si contamos con decenas de pelotones creando nuevos servicios, todo va bien. Pero si añadimos que estos servicios se están ejecutando en la misma plataforma (si no, no habría un Spotify, sino decenas), hace falta alguien que controle ese acceso. El propietario del sistema (uno o varios para cada sistema) se ocupa de todo esto: calidad, escalabilidad, documentación, etc. Spotify intenta que no sea algo a tiempo completo. 


Además del artículo de Spotify, hay un muy buen artículo de la consultora IQ3 sobre estos temas y, en concreto, referencia a otro artículo de gente de Salesforce sobre la gestión de dependencias en equipos ágiles que me pareció muy interesante también.