¿Escalado de qué?

Hoy en día, vivimos en un mundo “Agile”, donde no sólo ahora todos somos Agile (aunque aún no entendamos que significa eso), sino que, además, todos queremos estar en la moda de escalar la agilidad (sí, la misma que aún no entendemos del todo) porque así las organizaciones lo necesitan, ¿o no?, a veces no está muy claro. Lo que sí está claro es la proliferación de información. certificaciones y certificados de frameworks de escalado como SAFe, LeSS, Nexus y los casos en que estos han triunfado (muy poco o casi nunca se ve un caso de estudio donde estos han fallado y estoy seguro que son muchos y hay muchas historias por allí que no han sido contadas).

También es cierto que estos frameworks se enfocan en “Agilidad Organizacional” que en la mayoría de los casos no es ni siquiera un objetivo trazado en las organizaciones que terminan intentando implementarlas, puede ser que el objetivo sólo sea el seguir trabajando en crear el mejor producto o servicio de la forma más ágil posible, pero con más gente o equipos, para poder ganar más clientes y por supuesto ganar más plata.

Tampoco se habla mucho de sí existe una necesidad real o no de escalar, a veces contratamos una empresa consultora o un Agile Coach que termina recomendándonos alguno de los frameworks antes mencionados, porque así cobrarán más por hora y ganarán más plata (me han dicho por ahí), cuando lo mejor es tratar de crear el menor de los cambios en el proceso existente (que seguro es no considerando ninguno de ellos) para que no se vea afectada nuestra efectividad como equipos, nuestra entrega de valor a la organización y nuestro desarrollo de productos.

Hay veces que la necesidad de escalar sólo es porque la organización hace un tiempo empezó a trabajar con Scrum o Kanban, luego fue creciendo y tuvo la necesidad de crear varios equipos siguiendo el mismo proceso de desarrollo. Ahora la organización se pregunta cómo organizar estos equipos para que sean eficientes y entreguen valor añadido al producto o productos de forma frecuente, temprana y con calidad, como escalan la agilidad.

En un caso como este que he descrito, propondría el olvidarnos de esos frameworks “ágiles” que cuando ves esos diagramas que ni entiendes por dónde tienes que empezar a analizarlos (diría que nada ágiles) y mucho menos cuando tienes que leer acerca de ellos y te encuentras que unos dicen que es ágil o que no y las discusiones alrededor de ellos que lo que hacen es dejarte con más preguntas que respuestas, más bien te diría volvamos a lo básico, analizar qué es lo que estamos haciendo, que necesitamos hacer, experimentar y aprender.

Como describe el caso planteado, la organización ya está utilizando Scrum con un proceso definido y establecido en su propio contexto y que conocen como el framework está descrito, con sus ceremonias, roles, etc.

Cuando en una organización tenemos varios equipos Scrum trabajando juntos ya sea en el desarrollo de un producto o servicios, el Scrum de Scrums (Scrum of Scrums - SoS) es el siguiente paso natural para escalar ágilmente. Si no estás trabajando con Scrum, utilizas Kanban o incluso cualquier otro marco de trabajo, el SoS es el equivalente a una reunión diaria entre equipos.

SoS es una de las primeras aproximaciones al escalado Agile presentada por Jeff Sutherland (creador de Scrum) en 2001, es un complemento para Scrum no considerado como parte de Scrum y que por tanto no se menciona en la Guía de Scrum.

El objetivo de SoS es garantizar que la organización y los equipos individuales de Scrum estén en la “misma página” con respecto a los impactos de su trabajo en otros equipos.

El componente principal del SoS es una reunión con un formato es similar a la reunión Daily Scrum, en la que, en vez de los equipos, son los miembros los que se sincronizan y alinean dentro de su equipo. SoS se puede celebrar de forma diaria, dos veces a la semana o al menos una vez a la semana. El día que se haga deberá de ser justo después de las reuniones diarias, por tanto, será preferible que los equipos celebren sus reuniones diarias en paralelo.

De la misma forma que el Daily Scrum, el SoS NO es una reunión de estado. Es una reunión corta, generalmente de 15 minutos, idealmente con un representante de cada equipo que brinda a los equipos que participan en el desarrollo del producto, una forma efectiva para la coordinación, el alineamiento y la comunicación entre estos equipos, así como una integración de las entregas a final de cada sprint. Esta reunión ayuda a mantener informadas a las personas en toda la Organización.

el SoS NO es una reunión de estado.

En el SoS los representantes de cada equipo comentan sobre el avance del desarrollo del producto, dependencias entre equipos y como removerlas e informan de impedimentos que han encontrado en su proceso de desarrollo que pueden afectar la entrega del producto en el tiempo esperado.

¿Cuáles serían los pasos para implantar Scrum de Scrums?

1. Explicar a los miembros de los equipos que es el SoS y como beneficiaría la comunicación entre los equipos.
2. Asegurar que todos entienden y aceptan el propósito de hacer SoS: Sincronizar el trabajo proveniente de diferentes equipos que trabajan en varias partes del mismo producto.
3. Definir cuándo se va a realizar el SoS.
4. Promover entre los miembros del equipo a mantener una mentalidad ágil, incluso cuando los problemas, impedimentos, etc. están escalando y cambiando el proceso.
5. Asegurarse que al durante el SoS se mantiene el objetivo de descubrir problemas y obstáculos que han estado obstaculizando el éxito del desarrollo del producto y que la reunión se lleva a cabo con un sentido general de colaboración entre equipos en mente.
6. Experimentar y Aprender, no existe un formato específico para la reunión, intentar siempre buscar la forma en más aporta a todos los participantes y que se ajusta mejor al contexto de la organización, de los equipos y del producto.

En resumen, el SoS es un equipo virtual compuesto por representantes de cada uno de los equipos Scrum que colaboran en el desarrollo e integración del producto. También cabe señalar que SoS nos permite trabajar ágilmente en el desarrollo de un producto, pero por muy excelente que lo hagamos, no nos lleva a que toda la organización sea ágil, para eso se necesita muchísimo más, pero que considero que la organización debe descubrir experimentando y aprendiendo y no con recetas prescritas que asumen que todas las organizaciones son iguales y que un solo marco aplica para todas, la frase suena mejor en inglés, one size does not fit all.

one size does not fit all.

A la hora de presentarse una situación donde es necesario escalar la agilidad a varios equipos, yo propongo considerar inicialmente utilizar SoS ya que es la forma menos invasiva de escalar y sólo implica incluir una ceremonia adicional al proceso de desarrollo que se está realizando, pero que es muy potente a la hora de promover la comunicación entre distintos equipos de desarrollo, transparencia y agilidad.