Las organizaciones actuales están adoptando nuevas metodologías que abarcan toda la gama con la esperanza de encontrar la mejor ventaja competitiva para su negocio. Algunas se fijan en las metodologías ágiles convencionales, mientras que otras buscan inspiración en organizaciones como Spotify.
Con tantos marcos, modelos, terminologías y opiniones en el espacio ágil, es un reto para los líderes empresariales y los profesionales ágiles decidir qué enfoque se adaptará mejor a su organización, o incluso por dónde empezar.
En este artículo, vamos a poner de manifiesto la relación entre dos de estos enfoques: Scrum@Scale®y el llamado "Modelo Spotify".
Algunos[i] actualmente clasifican el Modelo Spotify y el Scrum@Scale como dos marcos distintos para escalar el Agile. Sin embargo, en 2019, el Registered Scrum@Scale Trainer™ y antiguo Agile Coach de Spotify, Henrik Kniberg, publicó un caso práctico de Scrum@Scale titulado "Spotify: un caso práctico de Scrum@Scale", en el que explica que el "Modelo Spotify" es en realidad una primera implementación del Scrum@Scale.[ii]
Aunque las interpretaciones modernas de ambos sugieren matices, la pregunta sigue en pie: ¿son el Scrum@Scale y el Modelo Spotify dos enfoques diferentes para escalar de forma ágil, o es el Modelo Spotify sólo una instancia temprana de Scrum@Scale?
Antes de entrar en materia, es importante aclarar la distinción entre un "marco" y un "modelo". Según el New Oxford American Dictionary, un Marco es "una estructura de soporte esencial; una estructura básica que subyace a un sistema, concepto o texto", y un Modelo es "un sistema o cosa que se utiliza como ejemplo a seguir o imitar; un diseño o versión particular de un producto".[iii]
¿Qué es el modelo Spotify?
El Modelo Spotify se presentó por primera vez en 2012, cuando Henrik Kniberg y Anders Ivarsson publicaron el libro blanco "Escalada ágil en Spotify." En el documento, Kniberg e Ivarsson detallan el enfoque de Spotify para permitir la agilidad. Desde la publicación de ese documento, Henrik Kniberg ha comentado en numerosas ocasiones que el Modelo Spotify no es un marco de trabajo, sino que representa el punto de vista de Spotify sobre el escalamiento desde una perspectiva técnica y cultural.
En 2012, el documento de Kniberg & Ivarsson "Scaling Agile @ Spotify" detalló cómo Spotify utilizó escuadrones, tribus, capítulos y gremios para escalar a más de 30 equipos.
Como dice Henrik, "he pasado algunos años trabajando con Spotify y publicó algunas cosas.... Esto ha llegado a conocerse como el "Modelo Spotify" en el mundo ágil, aunque en realidad no pretendía ser un marco o "modelo" genérico en absoluto. Es sólo un ejemplo de cómo trabaja una empresa".[iv]
¿Qué es el marco Scrum@Scale?
El marco Scrum@Scale, en cambio, es un marco real. El Scrum@Scale amplía de forma natural el marco central del Scrum para obtener mejores resultados en cualquier organización. Proporciona el andamiaje para que los sistemas y procesos crezcan de forma orgánica, capacitando a las organizaciones para lograr la agilidad del negocio y ofrecer un mayor impacto. En lugar de intentar aplicar una solución llave en mano de "talla única", Scrum@Scale proporciona un marco ligero y adaptable que tiene la capacidad de ajustarse a tu contexto, haciéndolo personalizable en todos los sectores. El Dr. Jeff Sutherland, cocreador de la Scrum, pasó años codificando las principales prácticas para el escalamiento, con los primeros experimentos de ese marco en 1983. A principios de 2018, Sutherland presentó formalmente el Guía Scrum@Scale[v] a la comunidad ágil como "el marco para que las organizaciones desarrollen iterativamente la mejor manera de que el Scrum funcione en su contexto".
La Guía Scrum@Scale detalla los componentes clave del marco Scrum@Scale para que las organizaciones puedan instalar un "Sistema Operativo Ágil". El Ciclo Product Owner y el Ciclo Scrum Master son fundamentales para los incrementos, lanzamientos y retroalimentación del producto.
Desde la fuente: Una entrevista con el Dr. Jeff Sutherland y Avi Schneier
El Modelo Spotify y la Scrum@Scale están alineados; sin embargo, las diferencias entre el modelo y el marco son importantes. Para proporcionar más contexto e historia, pedimos al Dr. Jeff Sutherland, cocreador de la Scrum e inventor de Scrum@Scaley Avi Schneier, consultor principal de Scrum Inc. y colaborador del Scrum@Scale para responder a algunas de las preguntas más populares sobre la relación entre el Scrum@Scale y el Modelo Spotify.
P: ¿Cuándo se inventó el Scrum@Scale y cuándo se "lanzó" por primera vez?
Sutherland: "El primer prototipo de mis ideas sobre el escalado que condujo a la síntesis final del Scrum@Scale se implementó en Mid-Continent Computer Services en 1983. Se implementaron varias versiones mejoradas en múltiples empresas hasta que se formó el primer equipo de Scrum en 1993. En 1995, Ken Schwaber y yo escribimos el primer documento formal sobre el Scrum. En 1996, pusimos en marcha el primer conjunto de equipos basados en este documento formal sobre la Scrum. Éste contenía todas las piezas clave de lo que hoy conocemos como Scrum@Scale, incluida una arquitectura basada en componentes. Esta arquitectura basada en componentes permitía a las empresas construir su organización como construyen sus productos. Los prototipos de la Scrum@Scale estaban en el mercado, evolucionando y adaptándose en cientos de empresas hasta que el Liderazgo Ágil de Intel me pidió que creara una Guía Scrum@Scale formal. Las primeras iteraciones de la Guía Scrum@Scale se elaboraron en 2014 y se codificaron a partir de los comentarios reales del mercado, y la versión 1.0 se publicó formalmente en 2018".
Los primeros prototipos del marco Scrum@Scale estaban en el mercado, evolucionando y adaptándose. En la década de 2010, Jeff Sutherland y Scrum Inc.™ comenzaron a iterar sobre la documentación de Scrum@Scale.
Q: "Construye tu organización como construyes tus productos." ¿Qué significa esto? ¿Cada implementación del Scrum@Scale es única?
Sutherland: "Hoy en día, los productos deben tener un modelo de componentes escalable, de modo que cualquier pieza de un sistema pueda actualizarse diariamente sin romper otras piezas del sistema. Esta estrategia es la que utiliza Saab Technologies para construir aviones de combate, Tesla para construir coches y Apple para construir iPads.
Para que una organización construya con éxito este tipo de productos y los escale, su modelo organizativo debe ser paralelo a su implementación técnica, o no podrá realizar mejoras diarias en las nuevas funciones que se despliegan en el mercado más de una vez por segundo, como en Amazon. Esta velocidad trastorna industrias enteras en semanas. Por ejemplo, hace unos años Amazon se hizo rápidamente con gran parte del mercado de préstamos al consumo en Alemania".
Schneier: "En realidad, éste es el mayor reto que veo cuando las organizaciones adoptan la Scrum@Scale. El error más común es tomar la jerarquía existente y tratar de mapear Scrum@Scale y la forma en que los equipos deben organizarse sobre ella. Esto es problemático. La forma correcta es, primero, trazar tu(s) flujo(s) de valor y, después, trazar a las personas sobre él. Decimos que para ser ágil a escala, tienes que estar dispuesto a refactorizar la organización para optimizar la producción. La resistencia a esto sólo crea residuos".
P: De un vistazo: ¿Qué es el Modelo Spotify?
Sutherland: "Cuando Henrik asumió el cargo de Jefe de Agile/Lean Coach en Spotify, estaban siguiendo los pasos de Scrum. Sin embargo, el Scrum Masters no lideraba y los equipos no rendían, así que Henrik hizo algunos cambios. Cambió el nombre del equipo por el de "Escuadrón", llamó a los grupos de equipos "Tribus" y permitió a los equipos con Agile Coaches mejorar su rendimiento. Los gerentes eran responsables de los "Capítulos", que incluían la contratación y la formación de desarrolladores con conjuntos de habilidades específicas en los equipos. Henrik y yo enseñábamos juntos Scrum@Scale en Estocolmo, así que había una alimentación cruzada mutua en esta época. Cuando estaba en Estocolmo, visitaba a Spotify, donde Henrik y yo nos reuníamos con el Agile Coaches para abordar cuestiones críticas.
Por ejemplo, el director general de Spotify le dijo a Henrik que los equipos tenían que entregar el doble de rápido para competir con Google y Amazon. En nuestra reunión Agile Coaches en Spotify, observamos que todos los equipos ya entregaban cada sprint, pero la mejor manera de duplicar la producción era entrenar a los desarrolladores para que entregaran todos los días, al igual que Google y Amazon. En unos seis meses conseguimos que cerca de ⅓ de los equipos entregaran todos los días".
Schneier: "Lo que hoy se conoce como el "Modelo Spotify" en realidad tiene poco que ver con Spotify o con su forma de trabajar. En la mayoría de los casos, las empresas y los consultores han adoptado la terminología al tiempo que han renunciado a las estructuras, las prácticas y la mentalidad clave que permitieron a Spotify funcionar en primer lugar."
P: ¿Qué problema resuelve el Scrum@Scale?
Sutherland: "El Scrum@Scale es un sistema operativo para todas las organizaciones que ofrece el doble de valor a la mitad de coste y les permite ofrecer una verdadera agilidad empresarial. Se basa en el trabajo con algunas de las mayores y más valiosas empresas del mundo. El doble de valor en la mitad de tiempo se demuestra en un nuevo artículo de la Biblioteca Digital del IEEE, "Rocket Mortgage ofrece el doble de valor en la mitad de tiempo a escala."[vi] Este documento ilustra, paso a paso, cómo incluso una implementación de SAFe grande y exitosa puede reducir el tiempo de ciclo en 400% mediante la implementación de Scrum@Scale".
P: ¿El Modelo Spotify fue una implementación temprana del Scrum@Scale?
Sutherland: "Scrum@Scale aclara la implementación de un Equipo de Acción Ejecutiva y un Foro MetaScrum que son fundamentales para que una empresa aporte mayor valor. Esto se reflejará normalmente en el precio de las acciones o en la valoración de la empresa si la organización es de propiedad privada. También tiene una implementación más rigurosa de la Scrum y espera que la Scrum Masters sea "Líderes que sirven".
Lo que Henrik Kniberg implementó en Spotify fue valioso para la empresa en ese momento. La implementación llevó a Spotify a una oferta pública y fue una inspiración para muchos desarrolladores ágiles. Henrik me invitaba con frecuencia a visitar Spotify para trabajar con el Agile Coaches para resolver sus problemas más difíciles. Como señala Henrik en su estudio del caso de la Scrum@Scale, se trata de un caso único de Scrum@Scale adecuado a su tiempo y lugar. La dirección de Spotify dice que ya no lo utilizan y que ninguno de los creadores del modelo está actualmente asociado a Spotify.
Como dice Marcin Floryan, Director de Ingeniería de Spotify, "no hemos inventado este modelo. Spotify está (como toda buena empresa ágil) evolucionando rápidamente. Este artículo es sólo una instantánea de nuestra forma de trabajar actual: un viaje en curso, no un viaje completo. Cuando leas esto, las cosas ya habrán cambiado".[vii]
P: ¿Qué falla cuando una empresa "copia" lo que hace otra? ¿Qué riesgo asume una organización al limitarse a "hacer" el Modelo Spotify?
Schneier: “A menudo se nos pide, cuando empezamos a trabajar con un nuevo grupo de líderes empresariales, que apliquemos las "mejores prácticas". Esto suele ser un esfuerzo temerario. En primer lugar, no hay garantía de que la adopción de la forma de trabajar de otra organización, incluidas las formas de trabajo ágiles, vaya a funcionar en tu contexto. Aunque la mayoría de los problemas a los que se enfrentan las empresas son comunes, cada empresa es una compilación única de productos, ecosistema y cultura. Por eso, el enfoque de "talla única" está condenado. Los mejores resultados se consiguen cuando empezamos a examinar el "por qué" subyacente de una determinada práctica o marco de trabajo, y luego experimentamos e iteramos sobre cómo funciona en tu contexto y cultura. Por eso el Scrum@Scale ha demostrado su eficacia en multitud de organizaciones y ámbitos.
En segundo lugar, el concepto de "mejores prácticas" implica que no hay una forma mejor de hacerlo, y detiene la búsqueda orgánica por parte de la organización que lo adopta para encontrar realmente lo que mejor le funcionaría. Prefiero los términos "prácticas principales" o "mejores prácticas" para fomentar la adopción y continuar la búsqueda. El principal riesgo que asume una organización al adoptar el Modelo Spotify es que no son Spotify, por lo que no sólo fracasará, sino que les impide encontrar realmente una forma mejor de funcionar".
P: ¿Qué patrones de escalado surgieron en Spotify? ¿Alguno de ellos acabó en el marco del Scrum@Scale?
Sutherland: "Los patrones que crearon el Scrum@Scale están documentados en el libro de patrones (Scrum: El espíritu del juego[viii]) y los patrones se desarrollan a partir de empresas que existían décadas antes de Spotify.
Lo principal que sacaría de Spotify es que Agile Coaches no son suficientes, pero necesitamos Scrum Masters para ser Agile Coaches, que es lo que estamos haciendo en Scrum Inc. Henrik estableció una norma formal para que Agile Coaches tenga un enfoque total en la mejora de los equipos.
La segunda cosa valiosa en Spotify, en mi opinión, son los gerentes como líderes de capítulo. Los gerentes contratan, despiden, forman y motivan a las personas en áreas de habilidades específicas en toda la organización. Además, establecen normas sobre herramientas, calidad y rendimiento en toda la organización. No realizan ninguna gestión directa del día a día de sus empleados".
Schneier: “Este patrón, aunque no forma parte formalmente de S@S, es una práctica beneficiosa que hemos difundido a través de las nociones de Comunidades de Práctica y Círculos de Calidad".
P: ¿Qué otras implementaciones tempranas de Scrum@Scale influyeron en la evolución del marco Scrum@Scale?
Sutherland: "El primer prototipo en Mid-Continent Computer Services, en 1983, tenía Sprints, Backlogs, Product Owners, equipos autoorganizados, Burndown Charts, etc. y convirtió a la Unidad de Negocio de Cajeros en la unidad de negocio más rentable en seis meses. Esto es lo que esperamos ver en todas las implantaciones del Scrum@Scale.
La primera implementación de Scrum@Scale con el modelo formal Scrum que publicamos Ken y yo se hizo en una empresa de Internet que salió a bolsa en 1996 (Individual Inc.). En aquella época también trabajábamos con grandes grupos de equipos en empresas como Fidelity.
Los fundamentos formales del Scrum@Scale se desarrollaron en IDX (ahora GE Healthcare) durante 1996-2000. Se hace referencia a IDX en repetidas ocasiones en los patrones de escalado descritos en Scrum: El espíritu del juego.
El Scrum explotó con la publicación del Manifiesto Ágil en 2001[ix]. En 2005, Ken me pidió que formara a todas las grandes empresas de Silicon Valley. Yahoo, Google, Adobe y muchas otras empresas empezaron a hacer Scrumming con grandes grupos de equipos en esa época.
De 2000 a 2008, fui el director de tecnología de PatientKeeper, que tenía uno de los conjuntos de equipos Scrum@Scale de mayor rendimiento jamás documentados.[x] El MetaScrum se perfeccionó aún más en PatientKeeper.
En 2009, ya estaba implantando S@S en empresas como Pegasystems, que consiguió resultados igual de espectaculares que los de la implantación de 1983 en Mid-Continent Computer Services.
La documentación formal de la Scrum@Scale fue fundamental para el liderazgo ágil de Intel y SAP, y el trabajo realizado desde 2005 con miles de equipos en Microsoft y Amazon fue influyente. El liderazgo ágil en SAP, con más de 2000 equipos de Scrum, ayudó a informar de la primera versión de la Guía Scrum@Scale y se mostró firme en la necesidad de una MetaScrum eficaz".
P: "La principal conexión con el Scrum@Scale es la entrega": ¿Cómo ayuda S@S a los equipos a cumplir?
Sutherland: "Como se muestra en detalle en el documento mencionado anteriormente, "La Hipoteca Cohete ofrece el doble de valor a la mitad de coste", Scrum@Scale analiza sistemáticamente tanto las operaciones empresariales como las tecnológicas e implementa las mejoras que tienen el máximo impacto en términos de coste/beneficio.
El primer paso de Rocket Mortgage fue conseguir la implantación de un Scrum coherente. Eliminaron los 15 roles SAFe y los redujeron a los tres roles de la Guía Scrum. Todos los demás roles se volvieron a formar como miembros del equipo o se trasladaron a otra área de la empresa. El segundo paso fue implantar un enfoque de entrega en todos los roles y en todas las reuniones.
Product Owners tienen que mejorar la entrega de valor por punto. Scrum Masters tienen que mejorar el rendimiento del equipo. Los que no podían hacerlo con eficacia fueron trasladados a otras funciones en la empresa. Las reuniones se cambiaron para centrarse totalmente en la entrega. Se cambiaron los horarios, el orden del día y los participantes para entregar un producto totalmente funcional en un plazo cada vez más corto, hasta conseguir actualizaciones diarias del producto en vivo.
Hay muchos otros detalles en el documento que muestran a las empresas cómo pueden utilizar paso a paso el Scrum@Scale para aumentar el rendimiento y la cuota de mercado, con cualquier implementación ágil o marco de escalado preexistente".
Schneier: “Si echas un vistazo a los primeros vídeos y documentos de Kniberg en Spotify, verás que se hace mucho hincapié en la liberación de manera DevOps. Así es como están conectados. Al igual que el Scrum es agnóstico al método de entrega, también lo es el Scrum@Scale. Dicho esto, si un equipo Scrum -y, por tanto, un grupo de equipos Scrum, o un Scrum de Scrum, como lo llamamos nosotros- es un camino independiente hacia la producción, entonces puedes ver por qué apoyaríamos un método de entrega del tipo DevOps o DevSecOps. Es, sencillamente, la forma más rápida de hacer llegar a tus clientes un producto que funciona".
Conclusión:
Si tú, como muchos líderes empresariales, estás buscando respuestas sobre cómo estructurar tus equipos o escalar Scrum para conseguir mejores resultados empresariales y agilidad, no te conformes con adoptar lo que otros han probado y esperar los mismos resultados. No existe una solución mágica "llave en mano". Cada organización debe examinar sus prácticas con regularidad, y evolucionar y adaptarlas continuamente a medida que su contexto, su mercado y su cultura cambian inevitablemente.
O, como Jeremiah LeeEl ex director de producto de Spotify lo expresa de forma elocuente, "Es posible que hayas descubierto el modelo Spotify porque estabas intentando averiguar cómo estructurar tus equipos. No te detengas aquí. Sigue investigando... Resulta que, en 2012, Spotify no había descubierto cómo mantener la velocidad y agilidad de un equipo pequeño en una gran organización. La empresa evolucionó más allá de su modelo epónimo y buscó fuera de sí misma para encontrar mejores respuestas. Tú también deberías hacerlo".[xi]
Esto es lo que enseña la Scrum@Scale y lo que Spotify instala. Como marco, la Scrum@Scale proporciona una estructura a través de una burocracia mínima viable (MVB) que no limita el crecimiento de una manera determinada. En su lugar, Scrum@Scale permite que una red de equipos crezca de forma orgánica, basándose en las necesidades únicas de la red, y a un ritmo de cambio sostenible que pueda ser mejor aceptado por las personas implicadas y la organización en general.
Referencias