Esta semana, un alumni611 (un alumno de uno de mis cursos) me contacto con una duda sobre cómo tener agilidad escalada.
Me mostró una serie de retos y he decidido contestar esta pregunta.
Sin más dilación, voy a proceder a la respuesta justificada de esa pregunta.
Distribución de equipos
En la organización en cuestión, había a una distribución de 4 equipos Scrum completos (Scrum Master, Product Owner y sus Developers).
Aún más una capa de integración donde había un Lead Scrum Master, un Chief Product Owner y un Lead Architect.
Como se ve en el esquema, hay una capa jerárquica que lo que hace a día de hoy es mandar.
Lleva un rol de ordeno y mando a los equipos donde hay 4 product owners que juegan el papel de proxy product owner sin más.
A parte, no queda muy claro quién maneja el Product Backlog, ya que hay 5 cabezas para el producto.
Pensad que este esquema se nutre para entregar un solo producto integrado.
Por eso esa capa de integración donde hay 3 personas decidiendo.
En este caso ahora mismo estamos hablando de una organización para gestionar un producto de entre 40-45 personas.
Potencial organización de equipos
Pensando que en esta organización hay una ensalada de proveedores externos, más propios, más luchas de poder, más juego de tronos, más disputas, …. más todo lo que os podáis imaginar empecé con una pequeña acción.
En la foto anterior, se ve la potencial idea para gestionar este entorno.
La idea es la siguiente, levantar 3 niveles, transformar los PO de los equipos en Stakeholders del Product Backlog.
Así pueden centrarse en las métricas de flujo y el análisis de la entrega de valor para tener un producto integrado.
A nivel estratégico los Product Owners de los equipos van a colaborar con el Chief Product Owner para tener un Product Backlog ordenado y nutrido con las información de los equipos.
La figura del Chief Product Owner sigue siendo presente y está siendo reafirmada. La idea es que lo canalice todo en términos de gestión de producto.
A nivel integración, seguimos con las 3 figuras iniciales, que formarán parte de un equipo de integración que va a recibir soporte de manera puntual e iterativa de integrantes de los equipos.
Tanto Lead SM, como Chief PO y Lead Architect serán los 3 roles fijos en el nivel de integración y las otras personas vinculadas a la integración serán iterantes.
A nivel operativo, tendremos los 4 equipos, con sus developers y sus Scrum Masters pero los PO se han transformado a Stakeholders perdiendo así cualquier gestión directa con el Product Backlog.
Esos Stakeholders ayudarán a los Scrum Masters a consolidar y mantener una flujo de integración y de entrega de valor saludable para que a final de cada Sprint haya un incremento de Producto integrado.
Debido a esto, hace que seamos capaces de entregar a la cliente o las personas interesadas en el buen quehacer del producto.
Los Sprints de los equipos están sincronizados en su día de inicio y de fin. Vaya, en otras palabras, que iteran con la misma cadencia.
¿Cómo serían los eventos?
Como nuestro esquema está basado en Scrum, vamos a mantener los 5 eventos que lleva la Guía Scrum como referencia. Así que vamos a tener Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retro.
Cómo iban a ser esos eventos escalados y cómo íbamos a hacer los eventos escala, vamos a hacer como una adaptación de la siguiente manera y cómo serían estos cuatro grandes eventos
La Planning tiene 3 partes, una parte primera global donde aterrizamos el objetivo global del Sprint y lo compartimos con el equipo.
Luego mandamos a los equipos a sus planning individuales para consolidar sus metas de Sprint y luego los volvemos a citar en un evento global para acabar de cerrar todo.
Vuelvo a comentar, en esta planning hay una parte de consolidar el objetivo global para tener clara una meta global para esos cuatro equipos.
Conjuntamente con las personas que están en integración y ayudando en las personas que están en las iniciativas estratégicas se cierran esos objetivos.
Cuando ahí hemos medianamente aterrizado una idea de su objetivo global enviamos a los equipos a hacer su planning especializado individual y también desde la parte estratégica hemos aterrizado hemos vislumbrado o liderado un potencial objetivo de equipo para ese sprint.
En esas planning de equipo ya hemos conseguido cerrar los objetivos de equipo y luego volvemos a cerrar la planning global con una alineación de objetivos global.
Esta planning dura como máximo 8 horas.
Vamos a proponer 2 dailies, una daily del equipo de integración donde veremos cómo de cerca o de lejos estamos del objetivo global y a partir ahí después vamos a nutrir de información las dailies individuales de los equipos.
Así que en total vamos a tener 5 dailies, 1 global de integración y 4 en los equipos.
Cuando terminamos el Sprint, tendremos una Review global y luego una retro con 3 segmentos.
En la review estamos gestionando el incremento integrado sería muy similar a la planning con tres niveles.
Poner el contexto global de cómo ha ido el sprint de manera global a todos los equipos y a partir de ahí sacar puntos de mejora que podrían tener que ver de manera individual con el equipo.
Vemos que podemos mejorar a nivel individual nosotros como equipo.
Luego a cerramos las mejoras continuas globales con las ideas tanto que hemos abierto en el contexto inicial como las que hemos trabajado en las que hemos trabajado en equipo.
Esto serían un poco los cuatro grandes eventos que tendremos.
De esta manera tenemos una interacción a nivel de sprint sí y a partir de ahí me gustaría poneros un cronograma temporal para que vierais cómo encajan estos eventos
El flujo de los eventos
Vamos a ver cómo encajan estos eventos a nivel a nivel del día a día
Os he puesto aquí 10 días e imaginad que el sprint de estos cuatro equipos empiezan y terminan con la misma cadencia a los cuatro
En este caso a diez días laborables que podríamos asumir que son dos semanas
He pintado los mismos eventos que hemos visto en el apartado anterior.
Hago notar que he añadido de manera obligatoria una vez por semana la acción de refinamiento.
Esta acción no seria más que descubrir y hacer madurar los elementos del backlog para ser tratamos por el conjunto de equipos de gestionan el producto.
Conclusión
Este no es un esquema de escalado tradicional, ya que hemos recolectado conceptos de otros esquemas de agilidad escalada que podéis encontrar por ahí.
En otras palabras, es una solución adhoc tomando cositas de aquí y de allí
Espero que os haya sido de ayuda para ver como potencialmente podríamos organizar estos equipos sobre todo haciendo mucho hincapié en la entrega de valor y en las métricas de flujo de Kanban
Además, para concluir, tened en cuenta que es un producto integrado y que el gran tema que hemos perseguido es intentar llegar a tener un producto integrado final.
Nuestro principal objetivo es mantener los valores de la agilidad e intentar entregar valor de manera integrada con una cadencia de sprint a sprint.
También hago notar que es un esquema aplicable de manera muy experimental para un problema muy concreto, pero creo que os puedo ayudar a construir vuestra solución particular de agilidad escalada.
Pensad que cada organización tiene su contexto, su entorno, su ecosistema y que no hay 2 organizaciones iguales. En otras palabras, puedes tener la receta pero cada cocinero tiene sus secretos.
Para finalizar, os dejo la explicación completa en video aquí de como tener agilidad escalada.