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, arrojaremos luz sobre la relación entre dos de estos enfoques: Scrum@Escala®y el llamado "Modelo Spotify".
Algunos[i] clasifican actualmente el Modelo Spotify y Scrum@Scale como dos marcos distintos para escalar Agile. Sin embargo, en 2019, Registrado Scrum@Scale Trainer™ y ex Agile Coach en Spotify, Henrik Kniberg, publicó un ScrumEstudio de caso @Scale titulado "Spotify - a ScrumEstudio de caso @Scale", en el que explica que el "Modelo Spotify" es en realidad una aplicación temprana de Scrum@Escala.[ii]
Aunque las interpretaciones modernas de ambos sugieren matices, la pregunta sigue en pie: ¿son Scrum@Escala y el Modelo Spotify dos enfoques diferentes para escalar ágilmente, o es el Modelo Spotify sólo una instancia temprana de Scrum¿Escala?
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 subyacente 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, sino que representa la visión de Spotify sobre la ampliación desde una perspectiva técnica y cultural.
En 2012, el documento de Kniberg & Ivarsson "Scaling Agile @ Spotify" detallaba cómo Spotify utilizó Squads, Tribes, Chapters y Guilds para escalar a más de 30 equipos.
Como dice Henrik: "He pasado unos cuantos años trabajando con Spotify y publicó algunas cosas.... Esto se conoce 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 la Scrum¿Marco @Escala?
En ScrumEn cambio, el marco @Scale es un marco real. Scrum@Escala amplía de forma natural el núcleo Scrum para obtener mejores resultados en cualquier organización. Proporciona el andamiaje para que los sistemas y procesos crezcan orgánicamente, capacitando a las organizaciones para lograr la agilidad empresarial y ofrecer un mayor impacto. En lugar de tratar de 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, lo que lo hace personalizable en todos los sectores. Dr. Jeff Sutherland, cocreador de Scrum, pasó años codificando las principales prácticas para el escalado, con los primeros experimentos de ese marco en 1983. A principios de 2018, Sutherland presentó formalmente el ScrumGuía @Escala[v] a la comunidad ágil como "el marco para que las organizaciones desarrollen iterativamente la mejor forma de Scrum funcionar en su contexto".
En ScrumLa Guía @Escala detalla los componentes clave de la Scrum@Scale para que las organizaciones puedan instalar un "Sistema Operativo Ágil". El sitio Product Owner Ciclo y el Scrum Master Los ciclos son fundamentales para los incrementos de producto, las versiones y la retroalimentación.
Desde la fuente: Entrevista con el Dr. Jeff Sutherland y Avi Schneier
El modelo Spotify y Scrum@Scale están alineados; sin embargo, las diferencias entre el modelo y el marco son importantes. Para aportar más contexto e historia, preguntamos al Dr. Jeff Sutherland, cocreador de Scrum e inventor de Scrum@Escalay Avi Schneier, Consultor Principal de Scrum Inc. y colaborador de Scrum@Escala para responder a algunas de las preguntas más populares sobre la relación entre Scrum@Escala y el modelo Spotify.
P: ¿Cuándo fue Scrum@Escala inventada y ¿cuándo fue "lanzada" por primera vez?
Sutherland: "El primer prototipo de mis pensamientos en torno al escalado que condujo a la síntesis final de Scrum@Scale se implantó en Mid-Continent Computer Services en 1983. Varias versiones mejoradas se implantaron en múltiples empresas hasta que la primera Equipo Scrum se formó en 1993. En 1995, Ken Schwaber y yo escribimos el primer documento formal sobre Scrum. En 1996, habíamos puesto en marcha el primer conjunto de equipos basados en este documento formal sobre Scrum. En ella estaban 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. Prototipos de Scrum@Scale estaban en el mercado, evolucionando y adaptándose en cientos de empresas hasta que Intel Agile Leadership me pidió que creara una ScrumGuía @Escala. Las primeras versiones de la ScrumLa Guía @Escala se elaboró en 2014 y se codificó a partir de las opiniones reales del mercado, y la Versión 1.0 se publicó formalmente en 2018".
Los primeros prototipos de la ScrumEl marco @Scale estaba en el mercado, evolucionando y adaptándose. En la década de 2010, Jeff Sutherland y Scrum Inc.™ comenzó a iterar sobre ScrumDocumentación de @Escala.
Q: "Construye tu organización como construyes tus productos." ¿Qué significa esto? ¿Todas las implementaciones de Scrum@¿Escala ú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 fabricar coches y Apple para fabricar iPads.
Para que una organización pueda construir con éxito este tipo de productos y escalarlos, 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 Scrum@Escala. El error común es tomar su jerarquía existente y tratar de mapear Scrum@Escala y la forma en que los equipos deben organizarse sobre ella. Esto es problemático. La forma correcta es, en primer lugar, trazar tu(s) flujo(s) de valor y, en segundo lugar, 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. Resistirse a ello 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 pasando por el proceso de Scrum. Sin embargo, Scrum Los Maestros no lideraban y los equipos no rendían, así que Henrik hizo algunos cambios. Cambió el nombre del equipo a "Escuadrón", llamó a los grupos de equipos "Tribus" y permitió a los equipos con Agile Coaches mejorar el rendimiento. Los gerentes eran responsables de los "Capítulos", lo que incluía contratar y formar a desarrolladores con conjuntos de habilidades específicas en todos los equipos. Henrik y yo enseñábamos Scrum@Scale juntos en Estocolmo, por lo que hubo una alimentación cruzada mutua en ese momento. Cuando estaba en Estocolmo, visitaba Spotify, donde Henrik y yo nos reuníamos con el Agile Coaches para tratar 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 entregaban cada sprint pero la mejor forma de duplicar la producción era entrenar a los desarrolladores para que entregaran todos los días, como Google y Amazon. En unos seis meses, aproximadamente ⅓ de los equipos entregaban 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 renunciaban a las estructuras, las prácticas y la mentalidad clave que permitieron a Spotify rendir en primer lugar."
P: ¿Qué problema tiene Scrum@Scale solve?
Sutherland: "Scrum@Scale es un sistema operativo para todas las organizaciones que proporciona 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 empresas más grandes y valiosas 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 implantación SAFe grande y con éxito puede reducir el tiempo de ciclo en 400% implantando Scrum@Escala".
P: ¿Fue el Modelo Spotify una implementación temprana de Scrum¿Escala?
Sutherland:"Scrum@Escala aclara la puesta en marcha de un Equipo Ejecutivo de Acción y de un MetaScrum Foro que son fundamentales para que una empresa aporte más 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 aplicación más rigurosa de Scrum y espera Scrum Maestros para ser "Líderes que sirven".
Lo que Henrik Kniberg implementó en Spotify fue valioso para la empresa en aquel 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 en la resolución de sus problemas más difíciles. Como señala Henrik en su ScrumEstudio de caso @Escala, es un caso único de Scrum@Escala adecuada 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á asociado actualmente a Spotify.
En palabras de Marcin Floryan, Director de Ingeniería de Spotify: "No hemos inventado este modelo. Spotify está (como cualquier buena empresa ágil) evolucionando rápidamente. Este artículo es sólo una instantánea de nuestra forma actual de trabajar: un viaje en curso, no un viaje completado. Cuando leas esto, las cosas ya habrán cambiado".[vii]
P: ¿Qué sale mal 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". A menudo se trata de un empeño temerario. En primer lugar, no hay ninguna garantía de que adoptar 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 al fracaso. Los mejores resultados se consiguen cuando empezamos por 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 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 líderes" 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 Scrum¿Marco de escala?
Sutherland:"Los patrones que crearon Scrum@Escala están documentados en el libro de modelos (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 Maestros para ser Agile Coaches que es lo que estamos haciendo en Scrum Inc. Henrik estableció una norma formal según la cual Agile Coaches tiene un total de enfoque 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 directivos contratan, despiden, forman y motivan a 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 diaria 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 primeras implementaciones de Scrum@Escala influyó en la evolución de la Scrum¿Marco de escala?
Sutherland:"El primer prototipo en Mid-Continent Computer Services en 1983 tenía Sprints, Backlogs, Product Owners, equipos autoorganizados, Burndown Charts, etc. e hizo de la Unidad de Negocio ATM la unidad de negocio más rentable en seis meses. Esto es lo que esperamos ver en todos ScrumImplementaciones @Escala.
La primera aplicación de Scrum@Escala con lo formal Scrum modelo publicado por Ken y por mí 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 de Scrum@Scale se desarrollaron en IDX (ahora GE Healthcare) entre 1996 y 2000. Se hace referencia repetidamente a IDX en los patrones de escalado descritos en Scrum: El espíritu del juego.
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 CTO de PatientKeeper, que tenía uno de los mayores rendimientos de Scrum@Conjunto de equipos jamás documentado.[x] En 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.
Documentación formal de Scrum@Scale fue fundamental para el liderazgo ágil en 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 Scrum equipos, ayudaron a informar la primera versión del ScrumGuía @Escala y se mostró inflexible sobre la necesidad de una MetaScrum."
P: "La conexión principal con Scrum@Escala es Entrega": ¿Cómo ayuda S@S a los equipos a cumplir?
Sutherland: "Como se muestra detalladamente en el documento mencionado anteriormente, "La Hipoteca Cohete ofrece el doble de valor a la mitad de coste", Scrum@Scale analiza sistemáticamente las operaciones empresariales y tecnológicas e implanta mejoras que tengan el máximo impacto coste/beneficio.
El primer paso para Rocket Mortgage fue conseguir un Scrum implementado. Eliminaron los 15 SAFe papeles y córtalo a los tres papeles en el Scrum Guía. Todos los demás papeles fueron reciclados como miembros del equipo o trasladados a otra área de la empresa. El segundo paso consistió en implantar un enfoque en todos papeles y todas las reuniones.
Product Owners necesario para mejorar la entrega de valor por punto. Scrum Los maestros tienen que mejorar el rendimiento del equipo. Los que no podían hacerlo eficazmente eran trasladados a otros papeles en la empresa. Las reuniones pasaron a ser totalmente enfoque en la entrega. Cambiaron el calendario, la agenda y los participantes para entregar un producto totalmente funcional en un plazo cada vez más corto, hasta que consiguieron actualizaciones diarias del producto en directo.
Hay muchos otros detalles en el documento que muestran a las empresas cómo pueden utilizar paso a paso Scrum@Escala para aumentar el rendimiento, influir en 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 liberar de forma DevOps. Así es como están conectados. Así como Scrum es agnóstico en cuanto al método de entrega, por lo que Scrum@Escala. Dicho esto, si un Equipo Scrum - y, por tanto, un grupo de Scrum Equipos, o un Scrum de Scrums, 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 un producto funcional a tus clientes".
Conclusión:
Si tú, como muchos líderes empresariales, buscas 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 evolucionarlas y adaptarlas continuamente a medida que cambien inevitablemente su contexto, su mercado y su cultura.
O, como Jeremiah LeeEl ex director de producto de Spotify lo expresa de forma elocuente, "Puede 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 Scrum@Escala enseña y lo que Spotify instanciaba. Como marco de trabajo, Scrum@Escala proporciona estructura mediante una burocracia mínima viable (MVB), que no limita el crecimiento de una manera determinada. Por el contrario, Scrum@Scale permite que una red de equipos crezca orgánicamente, en función de 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