En las ofertas de trabajo relacionadas con la agilidad es habitual leer “debes tener conocimientos de escalado Agile como SAFe o Nexus”. Sin embargo, esto genera dudas porque SAFe o Nexus resuelven problemas muy diferentes y se suelen introducir en el mismo cesto.
Vamos a analizar las principales dimensiones que existen en escalado Agile y las propuestas principales de cada una de ellas. ¡Comenzamos!
Tipos de escalado Agile
Cómo cualquier herramienta Agile, la principal pregunta que debemos hacernos es, ¿qué problema queremos resolver? Cada uno de los problemas dispone de diferentes opciones o propuestas que se pueden trabajar para conseguir un mejor resultado.
La mayoría de empresas que buscan “escalar Agile” están buscando expandir la cultura ágil en la organización para obtener mejores resultados. Este debate es más habitual cuando la empresa objetivo tiene un cierto tamaño.
El primer problema que nos encontramos aparece cuando un determinado equipo Scrum o Kanban crece y se hace “grande”. Scrum propone que los equipos Scrum sean de 10 o menos miembros. Cuando el número de miembros de un equipo supera los 10, se empieza a dificultar la comunicación y la toma de decisiones autogestionadas. Pero, a veces, necesitamos equipos más grandes para ciertos retos o problemas que queremos resolver. Este escalado es el que conocemos como “escalado horizontal” y sirve para equipos que tienen un objetivo común.
Otras empresas se encuentran con el reto de expandir la agilidad de unos pocos equipos a una gran cantidad de ellos. Es decir, el resultado de este escalado es disponer de muchos equipos Scrum, Kanban, XP o Ágiles. Para este tipo de empresas el problema de escalado es organizativo o vertical. El escalado horizontal y el vertical pueden coincidir en empresas monoproducto.
Por último, existen empresas que prefieren trabajar en el diseño de su organización y su cultura. Estas empresas buscan un propósito que nos guíe o una cultura de transformación que guíe nuestras decisiones y las acciones que tomaremos. El diseño organizativo nos puede servir para las otras dos verticales.
Escalado Horizontal o para Grandes Equipos
Hace años colaboraba con un equipo responsable de dar servicio a una empresa de telecomunicaciones low-cost. Este equipo estaba compuesto por 12 personas y su crecimiento iba en auge. Cuando eran 18 personas empezaron a tener problemas de comunicación cada vez más acuciantes. Un día, el Product Owner (pertenecía a empresa cliente) nos comentó que iban a aumentar el presupuesto e iban a crecer hasta las 30 personas (actualmente ya son más de 40). Cuando se produce un aumento tan elevado y rápido, soluciones como Scrum se quedan cortas.
Ken Schwaber y Jeff Sutherland son los creadores de Scrum y para el escalado del mismo difieren en su propuesta. Ken apuesta por Nexus, un marco que apuesta por un único Product Owner y único Product Backlog. Además, agrega el concepto de Nexus Integration Team, un equipo dedicado a la integración de todos los equipos Scrum que componen el nexus.
Por otro lado, Jeff apuesta por Scrum@Scaled, donde sí que se “escala” la figura del Product Owner. Esta decisión puede ayudar a gestionar mejor los requisitos pero también puedes perder el sentimiento de unidad que nos proporciona Nexus.
Craig Larman, un reconocido agilista, creó la propuesta LeSS, parecido a Nexus pero donde se proponen diferentes técnicas para conseguir conexión entre equipos. Por ejemplo, podemos tener personas que roten de equipo para que el conocimiento se distribuya.
Por último, hemos añadido KMP, la certificación avanzada de Kanban University que trabaja el escalado de Kanban. Kanban propone 7 tipos de circuitos de retroalimentación, es decir, reuniones donde se inspecciona y se adapta. De los siete, tres de ellos corresponden a situaciones donde tenemos varios equipos Kanban que se tienen que coordinar. Por tanto, podemos ubicar KMP en esta categoría.
En el escalado horizontal es clave que cada equipo que componga el “súper-equipo” sean equipos capaces de entregar valor por sí mismos.
Escalado Vertical o MultiEquipos
Una de las necesidades de muchas empresas es extender la agilidad tratando de que la cultura se expanda. En este tipo de escalados existen soluciones generalistas que, a día de hoy, generan recelos en muchos firmantes del manifiesto Agile. Entre otras cosas, Agile defiende simplicidad y muchas de estas propuestas son grandes soluciones tratando de hacer creer a las empresas que las necesitan.
SAFe es uno de los más polémicos debido a que ha tenido un periodo de moda y muchas grandes empresas apostaron por ello. De hecho, SAFe llega a una propuesta que contiene absolutamente cualquier concepto Agile que podamos imaginar. Cada palabra o concepto de moda SAFe lo recoge. Por ejemplo, Inteligencia Artificial, que es la moda de 2023 y SAFe lo ha añadido sin entender muy bien su motivación. Un marco que sirve para organizar tu empresa te dice que uses IA. ¿por qué?
Por otro lado tenemos a Spotify, otra de las propuestas más extendidas y que Spotify nunca llegó a aplicar. El problema de Spotify es que sigue un modelo matricial clásico con nombres “ágiles” y por tanto, siguen apostando por modelos con dos responsables en vez de modelos más simples. Spotify puede ser interesante en muchas empresas, sobre todo por su concepto de comunidad o “guild”, personas organizadas en torno a una determinada habilidad, como puede ser back o front.
Uno de los marcos, que está de moda actualmente, es team topologies, que se basa en la definición de diferentes tipos de equipos dentro de una organización o producto. Team Topologies está muy orientado a software donde, al parecer, está ganando enteros.
Por último, la propuesta de NeuronForest sobre multiequipos para un escalado Agile, Value Delivery Teams. Los VDT son equipos capaces de entregar valor end-to-end dentro de una empresa. Esto supone una gran revolución, porque hace responsables a los equipos de todo el ciclo de valor, desde tratar con clientes, el precio, construir y vender. Es decir, cada equipo funciona como una mini-empresa que abarca un mercado o un producto de la compañía. De esta manera, se reducen las dependencias y la burocracia que aparecen cuando nos organizamos por departamentos.
Diseño Organizacional
A la hora de conseguir una evolución en una empresa podemos necesitar trabajar tanto el diseño de lo que queremos ser cómo de la cultura organizativa que querremos. Cuidado, el diseño organizacional evita el desarrollar un plan a largo plazo donde se detallen todos los pasos que daremos para ser una empresa “ágil”. Sino que, nos ayuda a definir un propósito futurible y aspiracional al que deberemos tender. De esta manera, cuando trabajemos en la organización y tomemos decisiones podremos decidir aquellas que nos acerquen a lo que queremos ser.
Dentro del diseño organizacional podemos encontrar a Unfix como la última incorporación. Unfix es como una caja de legos que te permite componer y diseñar tu empresa. De hecho, podemos usar Unfix para crear SAFe o un Value Delivery Teams. Puede parecer que es una labor simple, pero tras un diseño con Unfix se esconde mucho trabajo y conversaciones complejas en las empresas para obtener un resultado satisfactorio.
En segundo lugar, hemos añadido a Design Thinking, una técnica que tiene muchos usos. Design Thinking permite crear equipos de trabajo que diseñen su organización, de manera que nos permita visualizar qué queremos ser en el futuro. La filosofía de Design Thinking es la revisión continua, debemos evitar hacer un ejercicio de DT inicial para tener un plan de trabajo y ser inflexibles. ¡Debemos probar contínuamente para avanzar!
Por otro lado, tenemos el Nuevo Estilo de Relaciones (NER) de K2K. Una técnica inventada por K2K que genera una nueva cultura de trabajo basado en confianza y relaciones por encima de reglas. De hecho, K2K trabajó con las organizaciones para diseñarlas con los empleados y desarrollar formas diferentes de trabajo sin ajustar a un marco concreto.
Una técnica parecida pero nacida de Semco es Semco Style Stories, una filosofía de trabajo también basado en las personas que, de manera autogestionada, definen cómo debe funcionar la empresa.
¿Escalamos?
Agile en ningún momento comenta nada de escalado, de hecho, evita esta aproximación. La agilidad más pura aparece en equipos pequeños capaces de entregar valor por sí mismos, de hecho, siempre se dice que hay que “desescalar la empresa” para poder escalar después.
Aún así, si apostamos por equipos grandes o por organizaciones con muchos equipos ágiles, es importante que elijamos la herramienta adecuada.
Y tú, ¿cómo escalas en agilidad?
Gracias Javier. Como siempre de alto interés lo que escribes.
Reconozco que según profundizo en las metodologías ágiles, voy perdiendo la fe en que realmente mantengamos esa supuesta agilidad.
Ahora hablamos del escalado y nos aparecen los mismos problemas que cuando solo hablamos de un equipo de hasta 9 personas pero incrementados con la necesaria coordinación, por ejemplo, en un plan estratégico que integra varios proyectos (y programas) en una empresa.
La propuesta VDT, que seguramente sería bueno ver en detalle, da por hecho que la actividad global que realiza un equipo es independiente de la de otro (se habla de mini-empresas). Eso no ocurre en la realidad. O somos mini-empresas independientes o, si somos una empresa, esos grupos tendrán que tener un mínimo nivel de coordinación. La empresa es un todo y SIEMPRE hay efectos entre departamentos o áreas.
Abrazo.
Buenas, ahí está la clave del cambio. Nosotros trabajamos con los clientes para hacer esa división. En un cliente nos dividimos por tipo de comercio, en otros por geografía y en otros por productos… Lo más difícil es esa división pero hay que intentarlo y trabajarlo.