El modelo de equipos Squad de Spotify fue un fracaso
(jeremiahlee.com)<p>"Ni el propio Spotify usa 'the Spotify model'. Ustedes tampoco deberían usarlo."<br />
El famoso white paper de Spotify sobre "Scaling Agile" de 2012 no fue más que una aspiración suya y nunca se implementó por completo.<br />
El white paper no coincidía con la realidad, pero como servía para reclutar, lo dejaron así; tras salir de la empresa, el autor dejó este registro para corregirlo.<br />
Un texto que explica en detalle qué estaba mal con ese modelo, qué se puede aprender de los errores de Spotify y qué otros modelos recomienda.<br />
<br />
El coautor de ese white paper y los Agile coaches de Spotify ya habían dicho desde antes a gente externa que no lo siguieran.<br />
"Incluso cuando escribimos el white paper, ya no estábamos haciendo eso. Era solo una ambición parcial y una estimación. La gente se esforzó por copiar algo que en realidad no existía."<br />
<br />
¿Por qué no funcionó bien?<br />
<br />
1. La gestión matricial resolvía el problema equivocado (Wrong Problem)<br />
<br />
Los equipos ágiles full-stack funcionan bien. Pero la gestión en forma de matriz crea todavía más problemas.<br />
→ Los equipos de Spotify tenían una estructura duradera, así que la ventaja de no tener que cambiar de manager al moverse a otro equipo era muy limitada.<br />
→ Los engineering managers solo se hacían responsables del desarrollo de carrera, y no podían ayudar a aprender habilidades interpersonales, entre otras cosas.<br />
→ No había un solo manager a cargo de los ingenieros de cada equipo. El product manager, que hacía un papel de mini-CEO, no tenía a alguien que cumpliera un rol equivalente al de mini-CTO. Es decir, no había nadie responsable del soporte al equipo técnico ni de negociar prioridades. Si había desacuerdos dentro del equipo técnico, el product manager tenía que negociar con todos los ingenieros. Si eso no funcionaba, terminaba negociando al menos con tres engineering managers distintos de backend/web/mobile, o escalando el asunto al responsable de ingeniería del área.<br />
<br />
[ Lo que se puede aprender de los errores de Spotify ]<br />
→ Como en los equipos de producto-diseño-tecnología normalmente hay más ingenieros, debería haber un manager a cargo de todos los ingenieros para que exista una vía de escalamiento cuando haya conflictos dentro del equipo.<br />
→ Los product managers deberían tener un par equivalente con quien discutir temas técnicos, como la relación entre CEO y CTO. <br />
<br />
2. Dependía de la autonomía de los equipos<br />
<br />
Cuando la empresa es pequeña, cada equipo hace trabajo de alcance variado y con frecuencia cambia qué equipo lleva la delantera.<br />
Cuando la empresa crece, las funciones duplicadas entre equipos se consolidan en nuevos equipos para ganar eficiencia.<br />
Cuando hay muchos equipos, cambia menos veces quién lleva la iniciativa, y eso permite pensar a largo plazo sobre los problemas que cada uno debe resolver.<br />
<br />
→ Spotify no definió un proceso común para la colaboración entre equipos. Como cada uno participaba a su manera, la productividad de toda la organización bajaba.<br />
→ El "modelo Spotify" se documentó cuando la empresa era mucho más pequeña. Debió haber aparecido una actualización posterior, pero no ocurrió. Solo se habló de autonomía, y la parte sobre colaboración entre equipos nunca se completó.<br />
<br />
[ Lo que se puede aprender de los errores de Spotify ]<br />
→ La autonomía necesita alineación. Las prioridades de la empresa deben ser definidas por la dirección. La autonomía no significa que los equipos hagan lo que quieran.<br />
→ Hace falta sí o sí un proceso de colaboración entre equipos. La autonomía no consiste en dejar que cada equipo resuelva todo por su cuenta.<br />
→ La dirección también debe definir cómo se evalúa el éxito, para que sea posible coordinar prioridades al decidir la colaboración entre equipos. <br />
→ La autonomía exige responsabilidad. Product Management debe responder por el valor del producto. Cada equipo tiene la responsabilidad de dejar "terminada" la parte que añade. Un equipo maduro debe justificar su independencia demostrando el mejor movimiento posible en términos de valor de negocio, riesgo, aprendizaje y siguientes pasos.<br />
<br />
"Si tuviera que escoger una sola cosa que habría querido corregir en Spotify, sería no haber enfatizado tanto la autonomía." - Joakim Sunden, ex Agile Coach de Spotify<br />
<br />
3. La colaboración era solo una capacidad asumida<br />
<br />
Spotify permitió que cada equipo controlara su forma de trabajar, pero mucha gente no tenía una comprensión básica de Agile.<br />
Por eso, cada equipo tuvo que esforzarse en encontrar una combinación funcional, iterando mejoras de proceso para mejorar su output.<br />
No había un lenguaje común para evaluar de forma eficiente los problemas del proceso, las soluciones o los resultados. En la práctica, ni siquiera era Agile; simplemente era "Not-Waterfall".<br />
<br />
Spotify tenía "Agile coaches" para enseñar y sugerir mejoras de proceso a cada equipo. La intención era buena, pero no había suficientes coaches para ayudar a todos los equipos.<br />
El tiempo que cada coach podía dedicar a un equipo no alcanzaba para acompañarlo hasta completar proyectos y evaluar resultados. Por eso, no terminaban siendo responsables de nada.<br />
<br />
[ Lo que se puede aprender de los errores de Spotify ]<br />
→ La colaboración es una habilidad que requiere conocimiento y práctica. Los managers no deberían asumir que la gente ya entiende las prácticas Agile existentes.<br />
→ Cuando la empresa crece lo suficiente, cada equipo necesita una organización de soporte que le ayude a planificar dentro del equipo y a hacer posible la colaboración entre equipos. Program Management debe hacerse responsable del proceso de planning. Los Program Managers dedicados deben lograr que el equipo funcione de forma colaborativa, mientras Product Manager y Engineering Manager cumplen cada uno su papel. <br />
<br />
4. Es difícil cambiar un mito<br />
<br />
Que Agile Scrum introdujera términos como burndown o sprint se debía a que hacía falta ponerles nombre a conceptos nuevos.<br />
Spotify introdujo palabras nuevas como Missions, Tribe, Squads y Chapter Lead, y eso sembró "la ilusión de que habían creado algo que solo podía existir si elegían palabras especiales".<br />
<br />
Si se eliminan esos sinónimos innecesarios, el modelo de Spotify no es más que un conjunto de "Cross-Functional Team" con demasiada autonomía y una estructura de gestión deficiente.<br />
Si Spotify hubiera llamado a las ideas de este modelo por sus nombres originales, tal vez cuando el modelo fracasó se habría visto no como un cambio de identidad cultural, sino como la búsqueda de procesos internos que funcionaran mejor.<br />
<br />
[ Lo que se puede aprender de los errores de Spotify ]<br />
→ La mayoría de los negocios solo pueden sostener unas pocas áreas de innovación. Rara vez la innovación en procesos internos diferencia a una empresa en el mercado. Estudiar el pasado puede ayudar a encontrar áreas mejores donde innovar.<br />
→ Optimiza la comprensión. Para mantener la productividad organizacional, hay que evaluar el valor de cada cosa nueva que la organización tenga que aprender.</p><p>*** En lugar de eso, hagan esto. ( Aunque no hay un camino rápido. )<br />
<br />
Probablemente encontraste el modelo Spotify porque querías diseñar la estructura de tu equipo. No te detengas ahí; investiga más.<br />
Empresas que han resistido pruebas durante más tiempo que Spotify han escrito mucho más sobre esto.<br />
<br />
Spotify en 2012 no encontró cómo mantener la velocidad y agilidad de equipos pequeños dentro de una organización grande.<br />
Ellos miraron afuera para ir más allá de ese modelo precursor y encontrar mejores respuestas; tú también deberías hacerlo. <br />
<br />
Recomendaciones del autor sobre otras formas de trabajo<br />
<br />
- ¿Tu organización de producto-desarrollo-diseño tiene más de 200 personas? Cuando estuve en Fitbit, "Scaled Agile Framework" nos funcionó bien.<br />
- Si tienen 200 personas o menos, recomiendo "Shape Up By Basecamp". Planeo usar esa estructura en mi próximo startup.<br />
- Lean los libros "Essential Scrum" y "Team Topologies".</p>
4 comentarios