Escalar Agile

Resumen
Una vez que las organizaciones se dan cuenta de que las formas ágiles de trabajo pueden impactar tremendamente el time-to-market, la satisfacción del cliente y el compromiso de los empleados, entre muchas otras cosas, comienzan a pensar en escalar la agilidad.

Existe la idea errónea de que si eres una organización grande, necesitas un enfoque escalado. Esto no es necesariamente cierto, ya que la escalabilidad es principalmente relevante para aquellos casos en los que el producto es demasiado grande para que un equipo pequeño lo desarrolle.

Cómo dividir los productos y si escalar o no son probablemente preguntas más importantes que qué tipo de framework de escalabilidad seleccionar. Desafortunadamente, muy pocas organizaciones hacen estas preguntas – quizás debido al gran impulso de los frameworks de escalabilidad por parte de los consultores.

Dado que una organización necesita escalar, hay muchos frameworks de escalabilidad para elegir, entre ellos SAFe, LeSS, Scrum@Scale y algunos otros. Pero ninguno de estos frameworks debería aplicarse tal cual.

Nuestra firme convicción es que las organizaciones deberían inspirarse en estos frameworks, pero en lugar de copiarlos, deberían observar un conjunto de principios como la descentralización de la toma de decisiones, el pensamiento lean y el empirismo, incluida la mejora continua.

Para que cualquier tipo de cambio sea exitoso, incluida la escalabilidad de las formas ágiles de trabajo, es esencial que los managers adapten su enfoque de trabajo. Para la mayoría de ellos significa pasar de trabajar en la organización a trabajar sobre la organización.

El enfoque principal se convierte en empoderar (permitir la toma de decisiones) y habilitar (desarrollar capacidades para la toma de decisiones) a equipos e individuos. Para que esto tenga éxito, los managers/líderes tienen que empezar a cambiar las estructuras, políticas y métricas de su organización, además del desarrollo sistemático de sus equipos y miembros del equipo.

Introducción a la escalabilidad de las formas ágiles de trabajo

En casi todos los talleres que imparto, los participantes me preguntan sobre cómo escalar Scrum o equipos ágiles. La razón por la que preguntan es que raramente hay hasta 10 personas trabajando en sus organizaciones – generalmente hay muchas más.

Muchos de ellos vienen de grandes corporaciones, ya sea servicios financieros, automoción, farmacéutica o tecnología médica. En muchas grandes corporaciones tienen productos grandes, por ejemplo un coche, con muchas, es decir, cientos de personas trabajando en ellos.

El error conceptual aquí es que tener muchas personas resulta automáticamente en un enfoque escalado. Esto no tiene por qué ser cierto. Una organización puede tener muchas personas y muchos equipos, pero mientras cada uno de estos equipos trabaje en un producto individual, no necesariamente tienen que escalar – al menos en el sentido tradicional de cómo usamos el término escalabilidad.

¿Qué significa escalar agile?

Escalar agile se vuelve relevante cuando más de un equipo trabaja en el mismo producto. Vale la pena reenfatizar esto: muchos equipos trabajando en el mismo producto. Así que para determinar si necesitas un enfoque escalado, es importante mirar primero tu definición de producto.

¿Cómo puedes definir un producto?

Hay muchas formas de verlo. Una forma es desde la perspectiva del cliente. ¿Qué consideran mis clientes como un producto, es decir, por qué están dispuestos a pagar, por ejemplo Microsoft Office?

Otra perspectiva es más interna: ¿cuáles son los diferentes componentes de un producto que podemos desarrollar de forma mayormente independiente, por ejemplo Microsoft Excel o funciones dentro de Excel?

Una perspectiva que muchas organizaciones toman no es ninguna de las anteriores. Más bien miran las diferentes piezas arquitectónicas de un producto y dividen los equipos en base a eso. Este enfoque resulta mayormente en silos y muchas dependencias entre equipos.

La segunda opción puede en muchos casos resultar en muchos equipos pequeños trabajando de forma mayormente independiente, sin necesitar así un enfoque formal de escalabilidad. Pero incluso si se necesitara un enfoque escalado, es mucho más fácil coordinar cada equipo y el trabajo entre equipos, ya que los límites del producto están claramente definidos.

¿Cómo escalamos?

Más adelante en este artículo resumiremos los enfoques de escalabilidad más comunes. Pero antes de llegar ahí, nos gustaría evaluar la pregunta de cómo escalamos y qué principios pueden ayudarnos a escalar de una mejor manera.

Cualquier equipo ágil, por ejemplo un equipo Scrum, tiene tres responsabilidades distintas: ¿Qué construimos? ¿Cómo lo construimos (técnico)? ¿Cómo colaboramos (metodología)? La mayor diferencia entre los diversos enfoques de escalabilidad es si escalan la unidad completa, es decir, el equipo Scrum con todas sus responsabilidades, o si solo escalan las responsabilidades del Cómo.

Esta distinción es importante ya que se relaciona directamente con uno de los principios ágiles clave que es la descentralización de la toma de decisiones al lugar donde ocurre el trabajo y la interacción con el cliente. También es importante ya que esto determina cuántos nuevos roles se crean y cuál se convierte el rol del liderazgo fuera de estos equipos.

¿Qué tipo de frameworks de escalabilidad ágil existen?

Hay muchas formas de escalar el desarrollo ágil dentro de una organización. Ninguno de estos enfoques cubre completamente cómo debería estar estructurada una organización. Generalmente solo cubren la unidad de desarrollo de productos de una organización.

Todas las unidades de apoyo dentro de una organización como Finanzas, Legal, RRHH, Compras no están cubiertas por ninguno de los frameworks de escalabilidad. Aunque algunos – incluidos consultores que venden estos frameworks – afirman que este es el caso, realmente no lo es.

En la sección a continuación pretendemos compartir contigo una visión general de los frameworks de escalabilidad más utilizados. Pero ten en cuenta que más utilizado no significa mejor. Nuestra firme convicción es que cada uno de estos frameworks tiene algunos beneficios distintos, pero también desventajas significativas.

Mejor que simplemente copiar uno de los frameworks es entender los principios clave para escalar el desarrollo ágil y crear algo dentro de tu organización que esté en constante evolución basándose en la inspección y adaptación regular y frecuente. Cada organización es única en su cultura y sus desafíos... tu forma de trabajar debería reflejar eso.

Scaled Agile Framework (SAFe)

El Scaled Agile Framework – también conocido como SAFe – es probablemente el framework de escalabilidad ágil mejor documentado. Fue inventado por Dean Leffingwell y se actualiza de forma regular. Puedes echar un vistazo a la última versión aquí.

SAFe es probablemente también el más prescriptivo de todos los frameworks de escalabilidad. Quizás por eso muchas grandes organizaciones comienzan su camino de escalabilidad usando SAFe. Como se mencionó anteriormente, esto no significa necesariamente que SAFe deba ser el framework de escalabilidad elegido. De hecho, aún tengo que ver una implementación exitosa de SAFe.

SAFe adopta una visión de equipo de equipos que denominan Agile Release Train, también conocido como ART. Un ART se basa en múltiples equipos de Scrum, Kanban o cualquier otro equipo Agile. A nivel de equipo hay Product Owners, Scrum Masters y Developers. A nivel del ART hay roles similares llamados Product Management, Release Train Engineer (RTE) y System Architect/Engineer.

Esto significa que SAFe escala la unidad completa de un equipo Scrum, incluidas las responsabilidades del Qué, que entonces quedan con Product Management. Esto genera desafíos significativos, ya que un Product Owner en SAFe no es lo mismo que un Product Owner en Scrum. El Product Owner en SAFe es principalmente una persona que refina el Backlog a nivel de equipo – que realmente ya no puede llamarse Product Backlog.

Uno de los beneficios clave de SAFe es que las organizaciones tienden a tener menos resistencia al moverse a SAFe que a cualquier otro framework – al menos esta ha sido mi experiencia. Esto puede ser bueno ya que resulta en que las organizaciones den el primer paso hacia el cambio. También puede ser malo si creen que implementar SAFe ya es el destino.

Una de las cosas más importantes a tener en cuenta es que cuanto más similar sea un enfoque de escalabilidad a tu estructura organizativa actual, políticas y métricas, menos resultará en que logres resultados diferentes. Así que implementar SAFe es probablemente más fácil que implementar algunos de los otros frameworks, pero lo más probable es que tampoco te acerque mucho más a lograr tus objetivos.

Large Scale Scrum (LeSS)

Large Scale Scrum – también conocido como LeSS – es otro enfoque de escalabilidad frecuentemente utilizado. LeSS fue inventado por Craig Larman y Bas Vodde. Ambos son individuos muy experimentados y pensadores sistémicos. Ambos también tienen opiniones muy firmes.

Comparado con SAFe, LeSS solo escala las piezas del Cómo del equipo Scrum, es decir, los Developers y hasta cierto punto el Scrum Master. LeSS en su forma más simple no crea una jerarquía de Product Owners. Esto significa que un Product Owner de LeSS es realmente un Product Owner (en el sentido de Scrum) y trabaja con múltiples equipos para lograr los objetivos del y para el producto.

Basado en esta definición, un Product Owner en LeSS necesita equipos muy maduros. Maduros en su comprensión del cliente, maduros en su comprensión de cómo desglosar Product Backlog Items y maduros en términos de trabajar estrechamente con stakeholders.

Comparado con un equipo Scrum no escalado donde generalmente un Product Owner hace la mayor parte del Product Backlog Refinement, la interacción con el cliente y la gestión de stakeholders, en LeSS no habría tiempo suficiente para que una sola persona haga esto para todos sus equipos.

Como soy un gran aficionado al fútbol, frecuentemente uso analogías del mundo del fútbol cuando hablo con clientes. Implementar LeSS es como jugar en la Champions League. Esto no es algo que alguien deba hacer si no ha demostrado ya una gran implementación de Scrum.

Comparado con SAFe, LeSS elimina gran parte de la burocracia de las grandes organizaciones y con ella muchas capas de gestión. Esto resulta incómodo para muchas personas con solo mirarlo, y más aún al aplicarlo.

Una implementación de LeSS no es fácil y comparada con lo que otros frameworks afirman, LeSS probablemente requiere el mayor cambio en cómo los managers lideran y también requiere la mayor concentración, energía y tiempo en el desarrollo de personas. El paso de equipos de componentes a equipos de funcionalidades es solo uno de muchos ejemplos.

Esto no significa que LeSS sea malo. Si tuviera que elegir uno de estos frameworks para mi organización o para mis clientes, probablemente sería LeSS. Pero LeSS también requiere el mayor compromiso del liderazgo senior y el mayor tiempo de preparación de los equipos. Probablemente también conducirá a los resultados más significativos.

Para iniciativas de desarrollo de productos que requieren más de 8 equipos, LeSS tiene una configuración dedicada llamada LeSS Huge. La única diferencia es que ahora LeSS también escala el rol del Product Owner. Sigue habiendo un Product Owner, pero para varias áreas hay los llamados Area Product Owners.

Scrum@Scale

Scrum@Scale fue inventado por el Dr. Jeff Sutherland, uno de los co-creadores de Scrum. Similar a SAFe, Scrum@Scale escala la unidad completa de un equipo, es decir, el Qué y el Cómo.

El nivel por encima del Scrum Team tiene un Chief Product Owner y un Scrum of Scrums Master. Hay un Ciclo de Product Owner que resulta en el Executive Meta Scrum (EMS) y un Ciclo de Scrum Master que resulta en el Executive Action Team (EAT).

Similar a LeSS, Scrum@Scale pone mucho énfasis en descentralizar la toma de decisiones a los equipos. Jeff Sutherland mismo es un gran promotor de que el Product Owner esté a cargo de la creación de valor para los clientes y no sea solo alguien que trabaja en un Backlog.

La Guía de Scrum@Scale documenta bastante bien cómo funciona básicamente el framework. De vez en cuando se vuelve un poco críptica, pero la pieza fundamental es que Scrum@Scale es un enfoque fractal para escalar equipos Scrum que funcionan. Por lo tanto, tampoco debería ser el punto de entrada para ninguna organización. De hecho, esto se puede decir de todos los frameworks de escalabilidad.

Nexus

Nexus fue creado por el otro co-creador de Scrum, Ken Schwaber. Como framework parece ser muy cercano a LeSS, aunque hay una diferencia distinta que es el Nexus Integration Team. Aparte de eso, Nexus – similar a LeSS – escala principalmente las responsabilidades del Cómo mientras mantiene un solo Product Owner. Puedes leer más sobre Nexus aquí.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery – también conocido como DAD – fue inventado por Scott Ambler y Mark Lines. No soy un experto en DAD y – a pesar de trabajar con muchas organizaciones – nunca lo he visto aplicado en la vida real. Esto no significa que DAD no se esté aplicando y que no funcione, solo significa que no lo he visto. Puedes leer más al respecto aquí.

Modelo Spotify

Este es uno interesante. Las principales personas detrás del Modelo Spotify – una de ellas es mi amigo Henrik Kniberg – dicen que no hay un Modelo Spotify. Aun así, muchas de las grandes consultoras venden esto a sus clientes. Hablan de Tribus, Squads y Guilds, mientras que la mayoría de ellos (en realidad todos) nunca han puesto un pie en Spotify para ver si y cómo funciona este "modelo".

El Modelo Spotify suena divertido y cool, después de todo Spotify es una empresa divertida y cool. Pero ¿este modelo de una startup escandinava de streaming de música – incluso si existiera – realmente encaja con una empresa alemana de telecomunicaciones, una farmacéutica suiza o una aseguradora americana? Personalmente, lo dudo mucho.

Afortunadamente, nadie en Spotify afirma que este modelo pueda aplicarse universalmente... en realidad ni siquiera afirman que funcione dentro de Spotify. Si escuchas atentamente lo que Henrik describe en sus videos sobre la cultura de ingeniería de Spotify, le escucharás decir que todo esto suena genial, pero que todavía tienen un montón de problemas en Spotify y están mejorando continuamente cómo trabajan. Así que no existe el modelo en Spotify... solo hay instantáneas.

¿Cómo puedes escalar agile dentro de tu organización?

Cuando trabajamos con organizaciones, nuestro objetivo es ayudarlas a entender que si bien pueden obtener muchas ideas e inspiración de varios frameworks de escalabilidad, la pieza más importante es entender algunos principios fundamentales de escalar el desarrollo ágil de productos y luego evolucionar constantemente la organización hacia estos principios.

Algunos de los principios clave que observamos son los siguientes:
No escales si no tienes que hacerlo, es decir, antes de pensar en escalar, mira si puedes dividir tu producto de manera que unidades pequeñas puedan trabajar en ellos de forma independiente, lo que hace irrelevante la escalabilidad.
Cada equipo y el equipo de equipos se configuran de manera que idealmente entreguen valor al cliente y estén centrados en el cliente.
Aplicar pensamiento lean, es decir, reducir el desperdicio limitando el trabajo en progreso, prototipado riguroso (descubrimiento) y feedback frecuente del cliente.
Mejorar continuamente la forma de trabajar a través de reuniones retrospectivas regulares y frecuentes del equipo y entre equipos.
Descentralizar la toma de decisiones tanto como sea posible creando claridad y desarrollando competencia dentro de los equipos.
Abrazar la incertidumbre y crear una mentalidad de empirismo tanto para lo que se construye como para cómo se construyen las cosas.

Esta lista no es en absoluto exhaustiva. Pero si una organización y su equipo de liderazgo comienzan a tomar estos principios en serio, los hemos visto mejorar tremendamente la agilidad organizacional, incluida la satisfacción del cliente y el compromiso de los empleados.

¿Qué necesitan saber los líderes sobre escalar agile?

En demasiados casos he visto a líderes/managers creer que una vez que una organización se mueve hacia agile, ya no son necesarios. Esta es una de las razones por las que muchos managers se resisten a las iniciativas de cambio organizacional – el miedo a perder su estatus o incluso su trabajo.

Creo que ningún cambio organizacional sucederá sin la dirección, tanto la alta como la media dirección. Estos grupos son los que trabajan sobre la organización, en comparación con todos los demás que trabajan principalmente en la organización.

La organización en sí es como un producto. Necesita ser desarrollada. Y dado el entorno rápidamente cambiante para la mayoría de las organizaciones, es mi firme convicción que cada organización – similar a la mayoría de los productos – es un trabajo en progreso, es decir, necesita ser continuamente mejorada. Este es el trabajo de los managers/líderes en las organizaciones.

Para la mayoría de los líderes esto significa que su trabajo cambia significativamente. Para aquellos que han estado microgerenciando a sus equipos, significa empoderar y habilitar a los equipos para tomar cada vez más decisiones. Para aquellos que han estado directamente involucrados en las decisiones de producto, significa decidir si quieren permanecer en un rol enfocado en el producto o si quieren moverse a un rol de desarrollo organizacional. En cualquier caso, la mayoría de los managers/líderes necesitan adaptar lo que hacen ellos mismos y cómo lo hacen, es decir, la mayoría necesita pasar por un viaje personal de liderazgo ágil.

Basado en nuestra experiencia, es realmente útil tener un modelo que te ayude a estructurar sistemáticamente tu viaje personal y darlo paso a paso con la ayuda de un gran coach. Si quieres aprender más sobre cómo se puede hacer esto, echa un vistazo a nuestras ofertas de Certified Agile Leadership.