Scaled Agile usando sólo SCRUM

Si tienes una compañía muy grande o quieres escalar agile para conseguir dar ese paso para que tu compañía se haga mucho más grande de lo que es, seguro que estás en el proceso mental de decidir que metodología o sistema de escalado vas a implementar.

Quizá aún estás en el ámbito de proponerte usar Nexus, LeSS o Scrum@Scale. Quizá ya hayas superado estos y te estés planteando embarcarte un “Tren” hacia algo mucho más complejo. Quizá estés en las vías de plantearte SAFe. 

Pero casi seguro que no te has planteado seguir usando Scrum. Como ibas a hacerlo si Scrum al fin y al cabo es un sistema pequeño, ligero, nada adaptado a una gran organización, con cientos de desarrolladores y múltiples proyectos.

Me complace decirte que por esa NO reflexión hemos pasado todos, o al menos, casi todos. 

Pongámonos a pensar cuáles son los principales motivos que nos llevan a escalar Agile.

Luchar contra la complejidad

Tendemos a pensar que, dado que Scrum es pequeño y muy ligero, no está preparado para ser usado en entornos empresariales.

¿Otra vez juzgando a los demás por su tamaño? No cometamos ese error, por favor. Pequeño sí, pero matón también.

Uno de los pilares para los que fue diseñado Scrum, fue para luchar contra la complejidad y por lo tanto tiene demostrada capacidad para enfrentarse a este tipo de entornos empresariales complejos.

La propia Guía Scrum lo dice bien claro. "A medida que la tecnología, el mercado y las complejidades ambientales y sus interacciones, aumentan rápidamente, la utilidad de Scrum en el manejo de la complejidad se comprueba día a día".  La Guía Scrum

Las estrategias de Scrum para combatir la complejidad, se encuentran en su core, en su propia ligereza y tamaño, así como en sus rutinas, lo que le confiere una consistencia a prueba de cualquier organización.

Resolver las dependencias entre proyectos

En mi opinión está es la principal razón por la que solemos empezar a plantearnos escalar Scrum. Nos encontramos situaciones en la que las interdependencias entre proyectos y personas, escalan en tamaño y complejidad.

Pero, a veces también nos olvidamos de que Scrum tiene su propia manera de enfocar estas dependencias entre equipos y proyectos. ¿Cuál? Organizando todo alrededor de equipos multidisciplinares, a los que hemos empoderado adecuadamente, siendo estos capaces de alcanzar las más altas cotas de auto-organización.

Demasiados recursos en un solo proyecto

En algún libro he leído que a esta situación se referían como al problema del bote de galletas. Demasiadas manos intentando a la vez coger una galleta de un bote con una abertura estrecha. Al final o nadie consigue coger la galleta, o es difícil evitar que varias manos vayan a la misma galleta.

Es una clara referencia a que cuando tenemos demasiados equipos trabajando sobre un mismo producto o sobre una cartera de ellos, tenemos que conseguir que varios de ellos no peleen por la misma galleta.

"El Product Owner discute el objetivo que el Sprint debe alcanzar y los elementos del Product Backlog que, si se completan en el Sprint, nos llevarían a alcanza la meta del Sprint." - La Guía Scrum.

Algunos elementos del Product Backlog es frecuente que estén relacionados con más de un objetivo. 

¿En serio es tan difícil en Scrum el hacer uso de la transparencia para informar de qué equipo está escogiendo qué elementos del Product Backlog y alinearlos con aquellos otros equipos con los que compartan dependencias?

Usando adecuadamente la transparencia podemos enfrentarnos sin duda a este topo de situaciones.

Clonar al PO

Cuando escalamos suele pasar que parece que vamos a necesitar clonar al Product Owner. Muchos equipos, equivale a muchos eventos y al Product Owner no le concedemos por el momento el don de la ubicuidad.

Aquí podemos disponer de miembros del Equipo Scrum, que apoyen la labor del Product Owner y actúen como delegados. Esta aproximación, aunque difícil de gestionar, nos evita el uso de Proxy Product Owner, que atacan directamente a la transparencia y que incluye su propia caja de retos y complejidades.

En este caso el método de prueba/error, puede ser tu mejor aliado.

Está de moda el usar escalado

No me cabe duda, que la mayor razón para usar escalado es que está de moda. No hay consultora que se precie, que no recomienda encarecidamente su uso. Parece un modelo relacional sencillo. Entidad grande, igual a complejidad, por lo que requiere algo a escala para gestionar.

Aquí se nos olvida frecuentemente que el camino del escalado es en sí mismo complejo y no exento de controversia. Podemos poner sobre la mesa, que ni los propios padres de la Guía Scrum, han sido capaces de ponerse de acuerdo sobre cuál es el mejor camino hacia el escalado. Cada uno de ellos presenta su propio enfoque.

Cierto es que enfoques como Nexus, Scrum@Scale y LeSS hacen un trabajo decente reduciendo las complejidades y manteniendo un más que notable nivel de simplicidad y consistencia.

Aun así, Scrum en sí mismo, es un gran enfoque para escalar, creedme.