LeSS, Large-Scale Scrum o Scrum a gran Escala, fue creado por dos agilistas con gran experiencia en ayudar a organizaciones con decenas, centenas, en algunas ocasiones unos pocos miles de personas a usar Scrum, y en muchos casos en más de una ubicación geográfica. Craig Larman y Bas Vodde escribieron sobre el tema hace muchos años, exponiendo sus ideas y experiencias.
Tuve la oportunidad de interactuar con ambos en mis tiempos de miembro del Board de Directores de Scrum Alliance y en otras ocasiones. También participé en formaciones de LeSS con cada uno de ellos y fui uno de los revisores del libro que escribieron sobre el framework. Este libro sirve como referencia principal para un Scrum a gran escala, junto con el contenido del sitio web oficial http://less.works. Para obtener más detalles sobre LeSS, os recomiendo que leáis este material.
La idea principal de LeSS es aplicar, en un contexto a gran escala, el Scrum tal como es. O casi. LeSS agrega muy pocos elementos al framework básico, tratando de eliminar (o al menos no mencionar) algunos aspectos, tales como el Objetivo de Sprint y la definición de Equipo de Scrum. Al igual que Scrum, LeSS es deliberadamente incompleto y utiliza el enfoque empírico de la transparencia, inspección y adaptación para el trabajo, en lugar de buscar el pronóstico predecible que dicta el funcionamiento de muchas organizaciones.
La simplicidad es la palabra clave y el objetivo fundamental de LeSS es simplificar una organización grande y compleja – una frase que he escuchado, tanto de Craig como de Bas, más de una vez.
La organización gira en torno del trabajo de los Equipos de Desarrollo, que son sus elementos más importantes. Estos equipos generan, cada uno, funcionalidades listas para usar, de principio a fin, eliminando así las dependencias asincrónicas que generarían colas y esperas. Con el apoyo de sus Scrum Masters, los equipos se autoorganizan en la coordinación de su trabajo, en la planificación conjunta de lo que cada uno hará en el Sprint, en la colaboración durante el Sprint para resolver las dependencias entre ellos sincrónicamente, en la distribución del conocimiento necesario para realizar el trabajo y en la resolución de problemas organizativos. Esta mayor responsabilidad de los Equipos de Desarrollo reduce e incluso elimina la necesidad de una administración intermedia, allanando la jerarquía organizacional y simplificando la organización.
El cambio de la mentalidad de proyecto a la mentalidad de producto es otra idea poderosa que LeSS adopta en busca de la simplicidad. La organización traslada el foco de su trabajo de la realización continua de proyectos, que a menudo representa grandes lotes de trabajo, a la entrega incremental de valor a sus usuarios, en pequeños lotes. A diferencia de los proyectos, que tienen un comienzo y un fin, el producto evoluciona continuamente, Sprint tras Sprint, mientras exista.
Por lo tanto, toda la complejidad de la gestión de proyectos que rige el funcionamiento de gran parte de las organizaciones de hoy desaparece. Al mismo tiempo, al adoptar un solo producto más amplio, priorizado en un único Product Backlog por un Product Owner, LeSS elimina la necesidad de administrar la cartera. La formación de equipos ya no es un problema, ya que los equipos estables y de larga duración trabajan en el producto.
El trabajo, realizado en pequeños lotes, se integra continuamente entre los diferentes equipos, lo que permite realizar entregas frecuentes a los usuarios del producto. Estos ciclos cortos de feedback realimentan continuamente la planificación, maximizando la adaptabilidad de la organización.
Fundamentos de LeSS
Equipos múltiples
Con LeSS, el desarrollo de productos se lleva a cabo entre dos y aproximadamente ocho equipos. Como en Scrum básico, cada equipo es pequeño, entre tres y nueve miembros. Los equipos también son autoorganizados, multidisciplinarios, estables, con miembros dedicados, duraderos y co-localizado. La gran mayoría de los equipos producen funcionalidades enfocadas en el usuario final.
Un producto
LeSS está diseñado para lidiar con varios equipos que trabajan con Scrum en un solo producto, representado en un Product Backlog. Pero la visión del producto ideal, en LeSS, es algo diferente. Es común que las grandes organizaciones dividan su cartera en decenas o incluso cientos de pequeños productos. LeSS, por el contrario, trabaja con una definición más amplia, que abarca en un mismo producto lo que estas grandes organizaciones considerarían varias.
Por lo consiguiente, podemos imaginar que una organización que utiliza LeSS, en el mundo ideal, tendrá un solo producto amplio con todos los equipos trabajando en él. Este producto ofrece soluciones integrales centradas en sus usuarios finales, es decir, aquellos que lo utilizarán, en lugar de componentes, capas o pasos intermedios.
Es importante destacar que las reglas de LeSS se ocupan del desarrollo de un solo producto por parte de múltiples equipos, sin ofrecer reglas ni prácticas de cómo tratar la priorización entre diferentes productos o las dependencias entre ellos.
Un Product Owner
LeSS trata el rol del Product Owner de una manera diferente a la configuración más común para las adopciones de Scrum, alineándose mejor, pero con Scrum básico. En esta configuración predominante, cada equipo tiene su Product Owner y cada Product Owner tiene su Product Backlog. Por lo tanto, cada equipo se especializa en un determinado tipo de elemento, que compondrá su Product Backlog local, priorizado por su Product Owner.
Si observamos el conjunto total de equipos, es fácil entender que, en general, no pueden trabajar en los elementos más importantes para la organización. Como cada equipo tiene su propio Product Backlog, los elementos de un determinado tipo llegan directamente a su Product Backlog correspondiente. Por ello, en determinado momento, habrá equipos limitados a trabajar en elementos de menor importancia, ya que no tienen el acceso o las habilidades necesarias para trabajar en elementos de otros tipos.
En este escenario, los equipos que se ocupan de elementos de gran importancia pueden tener en espera, en su Product Backlog local, elementos más importantes que aquellos en los que están trabajando otros equipos, caracterizando la priorización inadecuada. Pero, dado que cada equipo lleva a cabo su reunión de Sprint Planning sólo en su lista, este problema está oculto en priorizaciones locales.
Por el contrario, con un solo producto amplio que utiliza LeSS, hay un solo Product Owner, priorizando un único Product Backlog, que proporciona elementos para el trabajo de todos los equipos involucrados. De esta manera, la organización en su conjunto puede priorizar mejor. Teóricamente, el conjunto total de equipos puede seleccionar directamente, a partir de este único Product Backlog, los siguientes elementos más importantes, lo que permite una visión sistémica que conduce a una verdadera priorización.
La elección de los elementos que desarrollará un determinado equipo en el Sprint se realiza en conjunto, en colaboración con el Product Owner, durante la reunión de Sprint Planning. Si el conjunto de equipos no consigue seleccionar los elementos más importantes, dado que determinados equipos no tienen el conocimiento necesario, esta disfunción queda expuesta y los equipos pueden buscar gradualmente una mejor distribución del conocimiento entre ellos, lo que naturalmente conducirá a una mejor priorización.
Un Incremento común
En el desarrollo con LeSS, todos los equipos trabajan, Sprint tras Sprint, en un mismo Sprint común, en un código compartido, para generar un Incremento del producto común listo. Cada equipo genera funcionalidades listas de punta a punta, que se integran continuamente al producto en cada Sprint.
Durante el desarrollo en el Sprint, cada equipo trabaja en torno de su Sprint Backlog, pero los diferentes equipos colaborarán entre sí según sea necesario, principalmente para resolver cualquier dependencia que se identifique. Al final, se lleva a cabo una reunión de Sprint Review común, en la cual los diversos equipos presentan el Incremento producido en conjunto a los clientes y otras partes interesadas, inspeccionando y adaptando el producto en su conjunto.
Creo que como lectores ya os habéis dado cuenta de que la adopción de LeSS implicará un cambio profundo en la estructura de la mayoría de las organizaciones que eligen usarlo.
En futuras publicaciones, tengo la intención de tratar diferentes aspectos de LeSS, y también hablar acerca de LeSS Huge, para cuando hay más de, aproximadamente, ocho equipos trabajando en el desarrollo de productos.
Nuestras formaciones
Certified ScrumMaster® – CSM
Certified Scrum Product Owner® - CSPO
