Hoy en día, hay enorme interés en cómo escalar Scrum (es decir, llevarlo a empresas grandes, con varios equipos), tema que ya hemos tratado en varias ocasiones en el blog. Puedes tomar esta serie de dos post que comienza hoy (el segundo lo publicaremos la semana que viene) como continuación a los ya publicados:
– Scrum a gran escala (large-scale Scrum) o Scrum en empresas grandes donde enumeramos las principales metodologías (o buenas prácticas) sobre Scrum en empresas grandes.
– Implantando la agilidad en empresas grandes (1/2), donde hablamos de las reuniones Scrum de Scrums, Product Owner del Product Owner, etc.
En este caso, volvemos al tema de Scrum en empresas grandes porque después de revisar las ponencias de la conferencia agiles Agile 2014 – Orlando, quizá la conferencia más importante sobre agilidad, hemos visto las diferentes ideas y propuestas sobre las que en este ámbito se está ahora hablando, como por ejemplo la propuesta de Jeff (te dejamos la entrevista que le hicimos) sobre Scaling Scrum using Object Oriented Architecture (una visión de cómo llevar Scrum a empresas grandes siguiendo la filosofía de la orientación a objetos).
Con todo, después de revisar los últimos trabajos que hablan hoy sobre Scrum en empresas grandes, hemos querido sintetizártelos en esta serie de 2 post que van a tratar los puntos clave a tener en cuenta y que debes saber si quieres tener éxito escalando Scrum.
Tres dimensiones, o retos, para el crecimiento de Scrum y Scrum en empresas grandes
Uno de los artículos más destacados de la conferencia, en lo que a Scrum obviamente refiere, fue el de “Scrum at Scale. Go Modular for Greater Success” de Jeff Sutherland (te dejamos las transparencias de la conferencia), que trataba el tema de escalar Scrum. Para ello proponen tres dimensiones para mejorar Scrum, escala, distribución y saturación, como vemos en la imagen.
– Escala: es el número de equipos coordinados, la complejidad de los proyectos.
– Distribución: es el número de ubicaciones geográficas diferentes que están coordinadas.
– Saturación: es el grado de agilidad implantado en una organización.
Mejoras en alguna de estas dimensiones… harán que tu Scrum mejore. Cuando hablamos de Scrum en grandes empresas, nos centraremos en la dimensión “escala”, que será lo que trataremos en estos dos post sobre Scrum en empresas grandes.
Scrum, visto como un “framework” orientado a objetos
Según comenta el creador de Scrum, Jeff Sthuerland, en sus raíces, Scrum es un marco orientado a objetos. Cuando Jeff Sutherland desarrolló Scrum se basó en una arquitectura orientada a objetos donde cada elemento funciona de forma independiente y se adapta a una diversidad de situaciones.
La definición de retrospectiva, por ejemplo, sólo incluye: objetivos, calendario, asistentes y salidas, dejando a los equipos determinar cómo implementarlo.
Y Scrum en empresas grandes trabaja así: tenemos el qué y hay que ponerle el cómo.
Hay que conocer el contexto exacto de la organización para adaptar Scrum en general o llevar Scrum en empresas grandes en nuestro caso particular
Es importante tener muy claro el contexto de tu organización para poder adaptar Scrum a tus necesidades, ya que Scrum se puede utilizar en diferentes contextos. Algunas preguntas clave que comentaba Jeff Sutherland en su presentación, que deberías hacerte para conocer el contexto de tu organización son:
– ¿Cómo de importante es la velocidad de entrega?
– ¿Cómo de importante es la innovación?
– ¿Cómo de capacitado está el equipo?
– ¿Dónde están ubicados los equipos?
– ¿Cómo de complejo es el producto?
– ¿De cuánto tiempo se dispone para ser ágil?
– ¿Cómo de grave son las consecuencias de un defecto en el producto?
A pesar de no ser un tema muy hablado en los debates sobre Scrum en empresas grandes, el contexto es un tema muy importante para el éxito de Scrum en tu organización.
Áreas de trabajo para escalar Scrum en empresas grandes
Los trabajos originales de Jeff Sutherland hablan de 10 módulos, consideraciones o buenas prácticas a tener en cuenta durante el proceso de escalar Scrum. Nosotros les hemos dado el nombre de “áreas” de trabajo por ser más intuitivo.
Casos de estudio
Hay múltiples compañías que han implantado Scrum en empresas grandes… pero hay pocas que lo hayan contado. Nosotros en estos años hemos tenido múltiples experiencias con Scrum en empresas grandes, pero no podemos contar detalles (aunque en lo que refiere a experiencias os estamos dejando la serie “después de pasar por 80 empresas”)
No obstante, hay dos compañías, Autodesk y Spotify, que han implantado y escalado Scrum, y que cuentan abiertamente cómo (sobre todo la segunda). En los trabajos que tomamos como referenica para este post, también se toma como ejemplo a las anteriores, así que, cuando aplique y sea interesante, en los siguientes módulos dejaremos experiencias sobre los casos de estudio de Autodesk y Spotify.
Área de trabajo 1: La estructura de los equipos
Este punto es uno de los retos al llevar Scrum a empresas grandes. Cuando tienes un solo equipo vale, pero si tienes, por ejemplo 6, 6 equipos de menos de 10 personas… la cosa cambia.
El principal objetivo de esta área de trabajo es maximizar la productividad de los equipos, es decir, completar trabajo con éxito, en el menor tiempo posible y con la mejor calidad.
Para cumplir con este objetivo, tal y como ya hemos hablado en otros post, los equipos deben ser equipos multifuncionales y auto-organizados, pequeños en número, de no más de 9 personas por equipo, mínimas dependencias con otros equipos… te dejamos aquí más sobre este tema.
Área de trabajo 2: Visión estratégica
A la hora de llevar Scrum a empresas grandes un reto es que todos los equipos tengan la misma visión, por eso el objetivo de esta área de trabajo es alinear a toda la organización hacia esa visión común describiendo lo que hará en conjunto.
Para poder llevar a cabo con éxito estas prácticas, necesitamos conocer el mercado del producto y posibles usuarios… claramente aquí interviene mucho la labor del Product Owner (una infografía para saber más del PO), puesto que es quien tiene que recoger y tener claros los requisitos del software para construir un producto acorde a las necesidades.
Veamos a continuación, a modo de ejemplo, algunos casos de estudio de cómo las empresas que hemos mencionado antes han implementado este punto para conocer la situación, tanto externa como interna a la organización, para poder planear una estrategia y lograr sus objetivos.
Algunos casos de estudio
¿Cómo logra la visión estratégica Spotify? Con una fuerte cultura de equipo, lo que ellos llaman “tribus” (equipos que trabajan juntos, a su vez de manera autónoma). Si repasas los varios documentos sobre Spotify, verás que una de sus principales áreas de trabajo para llevar Scrum a una empresa grande se basa en la cultura del equipo.
¿Cómo logra la visión estratégica Autodesk? Con un Product Owner que mantiene una visión de trabajo en la que incorpora debates en equipo y retroalimentación.
Área de trabajo 3: Priorización del Product Backlog
Otro de los retos al llevar Scrum a empresas grandes es el manejo del Product Backlog. Cuando Scrum se lleva a empresas grandes, habrá normalmente un Product Backlog por equipo, por eso es conveniente en primer lugar priorizar el Product Backlog del proyecto en global y a continuación dividirlo en un Product Backlog por equipo (te dejo este post sobre el Product Backlog).
Algunos casos de estudio
¿Cómo logra la priorización del Product Backlog Spotify? Con historias de usuario suficientemente independientes para decidir las prioridades para los equipos, y reuniones diarias para proyectos que requieren mayor coordinación.
¿Cómo logra la priorización del Product Backlog Autodesk? El Product Owner posee los resultados de los productos, y trabaja junto al equipo y partes interesadas para priorizar lo atrasado y realizan una reunión para integrar todas las partes.
Área de trabajo 4: Descomposición del Product Backlog
El objetivo de esta área es dividir los proyectos complejos en elementos funcionales independientes más sencillos y con ello dividir el Product Backlog del proyecto en general en tantos Product Backlog como equipos haya (definiendo así el trabajo que tiene que realizar cada equipo). El reto aquí es saber repartir las diferentes historias del Product Backlog global en cada uno de los Product Backlog.
Acorde con el patrón “Specialized Velocities”, te dejamos más información sobre patrones para Scrum y agilidad, si hay muchos equipos es difícil usar un Product Backlog para todos, por lo tanto a cada equipo se le permite que estimen y contribuyan en Product Backlog adaptados a su trabajo, entonces cada equipo estima y desarrolla los elementos de su ámbito.
Aspecto de riesgo importante aquí, es evitar las dependencias entre equipos, debido a que una historia de usuario en el Product Backlog A no pueda realizarse hasta que esté terminada la del Product Backlog B, lo que ocasionaría retraso en el desarrollo del producto, problemas de integración…
Reuniones como las de grooming y Scrum de Scrum son de gran utilidad en este punto, ya que ayudan al Product Owner a reflexionar sobre la mejor manera de ordenar el Product Backlog y con ello las prioridades, te dejamos un post para saber más sobre las reuniones grooming.
Algunos casos de estudio
¿Cómo logra la descomposición del Product Backlog Spotify? Creando nuevas historias de usuario a nivel de componentes. El PO trabaja con el equipo para crear nuevas historias y filtrar historias completadas.
¿Cómo logra la descomposición del Product Backlog Autodesk? Básicamente dividen el producto en componentes lógicos, proporcionando un control centralizado y proceso estructurado asegurando que las historias fluyen de inicio a fin.
Concluyendo…
Hasta aquí la primera parte de este post, en el que hemos repasado algunos conocimientos claves para escalar Scrum y una serie de consideraciones para ello.
La semana que viene en la segunda parte hablaremos de otras consideraciones como son la planificación y gestión de release, feedback de los clientes, mejora continua y eliminación de los problemas, coordinación de equipos cruzados y métricas para tomar buenas decisiones, que propone Jeff Sutherland y que te llevarán al éxito escando Scrum.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023