Spotify Engineering Culture - part 1 - Subtitulado

Spotify Engineering Culture - part 1 - Subtitulado

¿Cómo se construye la cultura ágil en Spotify?

La importancia de entender la cultura ágil

  • La cultura ágil en Spotify es fundamental para su éxito, aunque a menudo pasa desapercibida. Es comparable al aire que respiramos; si todos comprenden esta cultura, estarán más dispuestos a mantenerla y reforzarla a medida que la empresa crece.

Evolución de Scrum en Spotify

  • Desde su inicio en 2008, Spotify comenzó como una empresa que utilizaba el método Scrum. Este enfoque proporcionó un ambiente laboral positivo, pero con el tiempo se transformó en múltiples equipos con diversas prácticas.
  • Se decidió hacer las reglas opcionales y enfatizar los principios ágiles sobre las prácticas específicas. Se renombró "Scrum" a "entrenador ágil" para reflejar un enfoque más centrado en el servicio.

Equipos autónomos y multifuncionales

  • Los "planteles autónomos" son pequeños equipos multifuncionales (menos de ocho personas) responsables de todo el ciclo de vida del producto: creación, diseño, implementación y mantenimiento.
  • Cada equipo tiene una misión a largo plazo alineada con la estrategia global de productos, lo que les permite decidir qué construir y cómo hacerlo.

Colaboración y motivación

  • Las oficinas están diseñadas para fomentar la colaboración entre los miembros del escuadrón, facilitando sesiones de planificación y retrospectivas.
  • La autonomía dentro del equipo acelera la toma de decisiones locales, minimizando esperas por parte de directivos o comités.

Alineación versus autonomía

  • El principio clave es ser autónomo sin suboptimizar; cada miembro debe escuchar a los demás como músicos en una banda de jazz para crear algo cohesivo.
  • La alineación y autonomía no son opuestos; deben coexistir. Una baja alineación con alta autonomía puede llevar al caos organizativo.

Estandarización e innovación

  • Con alta autonomía viene poca estandarización; diferentes equipos pueden usar distintas herramientas o metodologías según sus necesidades.
  • Existe una fuerte cultura de polinización cruzada donde las mejores prácticas emergen naturalmente entre equipos cuando suficientes adoptan un enfoque específico.

Arquitectura flexible

Cultura de Colaboración y Autonomía en Equipos

Propiedad del Código y Colaboración entre Escuadrones

  • Cada sistema es propiedad de un escuadrón, promoviendo un modelo de código abierto donde se prioriza el compartir sobre poseer.
  • Si un escuadrón necesita algo del sistema B, puede solicitarlo a otro escuadrón o editar el código ellos mismos, fomentando la autonomía.
  • La cultura incluye revisiones por pares para mejorar la calidad del código y difundir conocimiento entre los miembros.

Respeto Mutuo y Motivación

  • Existe una fuerte cultura de respeto mutuo; los empleados suelen dar crédito a sus colegas en lugar de tomarlo para sí mismos.
  • Se enfatiza la motivación dentro del equipo, con encuestas que muestran altos niveles de satisfacción laboral (91%).
  • A pesar del crecimiento rápido, se busca mejorar continuamente la satisfacción laboral; se invita a los insatisfechos a comunicarse.

Estructura Organizativa: Tribu y Capítulos

  • Los escuadrones están organizados en tribus que permiten una estructura ligera; cada miembro pertenece tanto a un equipo como a un capítulo.
  • El líder del capítulo actúa como gerente formal, enfocándose en coaching y mentoring para el desarrollo profesional.

Comunicación Informal y Guildas

  • La comunicación informal es clave; las guildas son comunidades ligeras donde se comparte conocimiento sobre áreas específicas.
  • Cualquiera puede unirse o abandonar una guilda libremente, lo que fomenta la colaboración sin estructuras jerárquicas rígidas.

Automatización y Frecuencia de Lanzamientos

  • La facilidad para liberar productos es crucial; lanzamientos frecuentes evitan versiones grandes difíciles de manejar.
  • Inversiones en automatización de pruebas e infraestructura continua son necesarias para mantener lanzamientos regulares sin complicaciones.

Estructura de Squads en el Desarrollo de Software

Tipos de Squads y sus Funciones

  • Los Squads lanzan sus propias funcionalidades directamente, organizándose en tres tipos: Client App Squads, Feature Squads e Infrastructure Squads.
  • Un Feature Squad se enfoca en áreas específicas como la búsqueda, desarrollando y manteniendo funciones relacionadas en todas las plataformas.
  • Los Client App Squads facilitan la liberación de aplicaciones en plataformas específicas como Desktop, iOS o Android.
  • Los Infrastructure Squads mejoran la eficacia de otros squads proporcionando herramientas para entrega continua, pruebas A/B y monitoreo.

Modelo de Autoservicio y Sincronización entre Squads

  • Se utiliza un modelo de autoservicio similar a un buffet donde los squads no sirven directamente el código a producción; su objetivo es facilitar que los Feature Squads lo hagan por sí mismos.
  • La gestión del lanzamiento se realiza mediante "Release Trains" y "Feature Toggles", permitiendo una programación regular para las liberaciones (cada semana o cada tres semanas).

Mecanismos de Lanzamiento y Control

  • Las características A, B y C pueden estar listas mientras que D está en desarrollo; el release train incluirá todo pero ocultará lo incompleto usando feature toggles.
  • El uso de "feature toggles" ayuda a exponer problemas tempranos de integración y minimiza la necesidad de ramas no fusionadas, evitando así la "muerte técnica".

Confianza vs. Control Centralizado

  • Aunque puede parecer arriesgado permitir que cada equipo implemente su propio código sin control centralizado, se ha aprendido que la confianza es más importante que el control formal.