Scrum

Mi equipo es grande ¿Por dónde escalo?

Antes de empezar a usar Scrum, yo utilizaba uno de los argumentos típicos de personas que no tienen ni idea (era lo que me pasaba a mí) “Scrum no sirve para equipos grandes”. Jeff Sutherland (co-creador de Scrum) habla de que los equipos pequeños son más efectivos y que esto viene demostrado por un experimento con 5000 equipos que se hizo con IBM.

Scrum recomienda que el tamaño del Development Team no supere las nueve personas; la explicación es larga pero tiene que ver con la comunicación y la dificultad de coordinarse entre las personas. Cuando leemos sobre “escalar Scrum”, siempre leemos normas  como: “puedes utilizar SAFE, LeSS o Nexus…”. Sin embargo, ahora que he aprendido un poco, creo que hay mucha confusión sobre cada uno de los frameworks de escalado. Vamos a hacer una pequeña introducción a cada uno de ellos.

Escalado Vertical y Horizontal

Creo que uno de los grandes errores es confundir entre los frameworks para productos grandes (más de personas) de los framework que trabajan a nivel de organización. Como decía un compañero, podemos decir que los primeros son un escalado horizontal mientras que los otros son verticales.

person-1245959_1280.jpg

Escalados Horizontales

LeSS

LeSS propone un escalado de equipos manteniendo el único Product Owner y el Product Backlog. De esta manera, lo que realmente se multiplican son los diferentes Development Teams que se irán repartiendo los diferentes Product Backlog Items. Para mí, este tipo de escalado permite la toma ágil de decisiones porque no hay un “comité de Product Owner” a la hora de avanzar. Desde mi punto de vista, lo malo es que, en equipo muy grandes, ser ese Product Owner puede ser muy complicado. Hay más información de LeSS en esta página.

Nexus

La alternativa apadrinada por Ken Schwaber (co-creador de Scrum) es Nexus. Sigue una filosofía parecida a LeSS en el sentido de que el Product Owner es único porque el Producto es único. La gran diferencia es que incorpora un nuevo rol, el Nexus Integration Team (NIT). El NIT es un equipo físico o virtual cuya misión es la integración de todas los equipos para alcanzar un incremento y que haya entrega. Para los creadores de Nexus, las dependencias entre equipos y su integración requieren de mucha energía y por eso el NIT es la clave de este framework.

Scrum@Scale

Jeff Sutherland (el otro co-creador de Scrum) apuesta por este otro framework.  La gran diferencia es que el Product Owner escala en número. Aquí tenemos figuras como el Chief Product Owner que va escalando cuanto más grande es el equipo. Además, los Scrum Master también escalan creando una especie de jerarquización entre Scrum Master. Este Scrum of Scrum Master se encarga de la unión e integración de los diferentes Scrum Teams. Podéis encontrar más información en la guía.

Escalados Verticales

Scrum of Scrum

Este es el primer framework de escalado vertical, el más sencillo de todos y por eso solo se aplica cuando tenemos pocos equipos. Scrum of Scrums se basa en añadir una reunión diaria Daily de coordinación entre equipos. A este evento, generalmente, asisten los Scrum Master aunque podrían acudir otras personas del equipo si se conviniera. La idea al final es la coordinación de equipos para el que puede haber un backlog de dependencias. Se puede leer más aquí.

SAFe

Para mi Safe se uno de los frameworks más complicados de escalado vertical. Existe un gran dilema en la comunidad sobre si es Agile o no porque tiene pinta de una jerarquización. Para mí, la principal característica es que define niveles que pasan desde equipo, programa a portfolio. En cada nivel se define una triada formada por una persona técnica, una de cultura y una de negocio tratando de mantener una cierta homegeneización. Podéis profundizar  más sobre Safe en este enlace.

Modelo Spotify

Uno de los modelos que más se están extendiendo es el modelo que aplica Spotify en su organización. Spotify nació como empresa digital y creció de esa manera. Me parece un modelo muy bueno para Spotify porque fue el modelo que ellos descubrieron que necesitaban. Tratar de imitar un modelo me parece muy complejo y creo que, en muchos sitios,, se imita como una manera de jerarquizar con palabras de moda  como Squad o Tribe.

organizaciones teal

Otro tipo de organizaciones 

Scrum Studio

Hay organizaciones que a la hora de plantearse un escalado vertical han optado por una alternativa más disruptiva. En vez de transformarse, han creado una organización paralela que trabaje con Scrum. Una de estas opciones es Scrum Studio que trata de incorporar la innovación en las organizaciones tradicionales, llevarlas a mercados y negocios que se les escapan por ser poco ágiles. La idea es tener equipos Scrum realizando productos innovadores. Podéis leer más sobre ello aquí.

Empresa Teal

Realmente la Empresa Teal no es un escalado como tal, pero me gusta incluirlo porque puede ser el futuro de muchas organizaciones. Hay una manera de clasificar organizaciones que podemos encontrar en el libro Reinventando Organizaciones de Frederic Laloux. El autor divide a las compañías entre el rojo hasta el esmeralda con una escala evolutiva. Digamos que los primeros colores son más jerarquía pura y control y los más evolucionados buscan la autoorganización.  En este tipo de organizaciones se rigen por tres reglas: autonomía, propósito y autenticidad. Precisamente por todo ello no hay una estructura organizativa, se invita a los empleados a descubrirla a través de un propósito que se crea. Sinceramente es el modelo que me gustaría ver en el futuro en más organizaciones.

Deja un comentario