Introducción a LeSS

Large Scale Scrum o LeSS es una iniciativa de Craig Larman y Bas Vodde, que provee una serie de reglas, guías y experimentos que se pueden utilizar para escalar Scrum en grandes compañías donde existen varios equipos Scrum. El punto clave de este “framework” es que escala

Ya sabemos que Scrum, funciona muy bien en empresas pequeñas con productos no muy grandes, y que, en las grandes organizaciones, tradicionalmente, se han implementado las metodologías en cascada.

LeSS se ha usado con grupos de doce a cientos y miles de personas en industrias como la banca, telecomunicaciones, juegos y sistemas de radares, donde se han hecho múltiples experimentos para poder definir mejor este framework.

 

Principios de LeSS

LeSS es un marco de trabajo para escalar el desarrollo ágil usando estos principios:

• “More with LeSS”, que no viene a decir más que, podemos conseguir más y mejores resultados con menos esfuerzo, es decir, un problema complejo requiere una comprensión profunda para que puede resolverse con soluciones simples.

• Pensamiento Lean eliminando desperdicios y centrándonos sólo en aquello que proporciona valor.

• Pensamiento sistémico, cuyo objetivo es que los miembros entiendan e interioricen todo el proceso de desarrollo ágil entendiéndolo como “un todo” y no como “parte de”.

• Control de procesos empíricos, esto se basa en que, en lugar de seguir una fórmula estática e invariable (como una receta de cocina), Scrum se basa en el principio de inspección y adaptación para obtener mejores resultados. Este principio va un poco más allá con LeSS, indicando que debemos controlar estos procesos de inspección y adaptación para apoyar a la transparencia.  

• Transparencia. Esto viene a repetir un poco el principio anterior, haciendo especial hincapié en que la información compartida se basa en elementos tangibles, producidos continuamente, en iteraciones muy cortas

• Enfoque como un producto completo y único, si bien gracias al modularidad podemos dividir un problema en partes más sencillas y repartir las tareas entre varios equipos, los elementos de Scrum se deben entender como algo único.  Al final y al cabo vamos a tener solamente un único producto potencialmente entregable, representando un único incremento, en un único sprint, independientemente de si hay 1 o 21 equipos Scrum. “Los clientes esperan un producto, no una parte.”

• Poner al cliente en el centro de todo, esto trata de identificar qué aporta valor y que supone un desperdicio para el cliente.

• Mejora continua mediante a la excelencia técnica¸ se busca entregar productos de calidad continuamente minimizando los defectos.

• Teoría de colas: Debemos entender cómo se comportan los sistemas con la teoría de colas en el dominio del desarrollo software para poder administrarlas controlando los límites de trabajo en curso, la multitarea y los productos de trabajo.

 

¿Cómo funciona LeSS?

Se basa en multi-equipos Scrum (varios equipos Scrum), donde hay un único Product Owner que nos da la visión del producto, encargado de priorizar el Product Backlog del cliente, para obtener el mayor valor de negocio posible. Se busca obtener un producto potencialmente entregable en periodos (Sprints) de 1 a 4 semanas.

Ahora tenemos varios equipos Scrum, desarrollando este producto en un Sprint compartido al mismo tiempo.

El ciclo de vida es iterativo e incremental. Donde cada Sprint comienza con el Sprint Planning 1, que es una pequeña reunión en la que cada equipo selecciona las historias de usuario que aportan más valor (Se encuentran la parte superior del Product Backlog priorizadas por el Product Owner) para implementarlas en el Sprint.

Después sigue el Sprint Planning 2, que es el evento en el que los equipos discuten y deciden las estrategias para desarrollar esas historias de usuario que han seleccionado anteriormente.

Durante el Sprint, cada equipo se auto-organiza para desarrollar la funcionalidad que seleccionaron en Sprint Planning 1, al mismo tiempo que colaboran continuamente con los otros equipos para entregar el incremento de un único producto (tiene que estar integrado).

Como los equipos son autoorganizados, ellos mismos son los responsables de coordinarse con otros equipos, es decir no existen coordinadores asignados. (comunicación dailys).

A medida que el Sprint avanza, más o menos a la mitad de la iteración, los equipos hacen una breve pausa del Sprint en curso, para refinar el Product Backlog, es decir, tendrán que colaborar con el cliente y los usuarios finales para esclarecer el trabajo de futuros Sprints. Gracias a conectar a los equipos con los clientes, podemos liberar al Product Owner para que trabaje sobre la visión y priorización

Luego tenemos un Sprint Review, una reunión compartida donde los equipos y clientes evalúan qué trabajo ha sido terminado y cuál será el mejor incremento para la siguiente iteración (deciden qué parte del desarrollo aporta más valor para la próxima iteración).

Cada equipo hace una retrospectiva para insepeccionar y adaptar la forma en la que trabajan, es decir, queremos que las personas posean el proceso y los métodos, no que sean esclavos de ellos. Valor ágil  número 1. Aceptar esto, es lo que nos va a permitir obtener una mejora continua.

LeSS va mas allá de la “retrospectiva en equipo”, los equipos, el product owner, los scrum masters y los gerentes usan algo denominado retrospectiva general para explorar los obstáculos sistémicos (que afectan a todo el sistema)  y organizacionales que impiden mejorar la entrega continua de valor. Es decir, todos estos roles mencionados, utilizan LeSS para inspeccionar y adaptar a la organización entera.

Cuando tenemos más de 8 equipos, hacemos algo similar llamado LeSS Huge, que sigue teniendo como objetivo obtener un producto entregable en cada Sprint.

Consideraciones

Pero realmente LeSS no funcionará en tu organización, no es por LeSS, es por la manera en la que está tu organización ahora. Tu organización tendría que cambiar a una forma que permitiera trabajar con LeSS. Esto es algo que no se logra ni fácilmente ni rápido.

De hecho, tu organización actualmente está diseñada para resistir y neutralizar cualquier esfuerzo hacia la agilidad.

Las reglas que tiene LeSS aunque no sean muchas tienen un impacto muy grande, con un alcance e implicaciones muy altas. Pueden pasar años para que puedas adoptar LeSS, a la vez que te deshaces de las reglas, procesos, estructuras y hábitos existentes.

Las adopciones de LeSS no son solo cambios de procesos y roles de la estructura de tu organización. Ya hemos visto varias veces empresas que utilizan etiquetas ágiles, pero siguen siendo igual de rudimentarias, porque siguen teniendo los mismos hábitos sin un cambio real, esto es lo que se denomina un fake-agile.

Adoptar LeSS, va más allá de esto, desafiando las convenciones tradicionales de los proyectos, productos, roles y prácticas técnicas. Lo que busca LeSS es instaurar la cultura ágil cambiando la estructura y políticas de la organización.

Por ejemplo, los equipos son multifuncionales, es decir, no solo se dedican a desarrollar código y a testear, sino que incluyen todas las habilidades de arquitectura y diseño, conocimiento del dominio de negocio, habilidades de UX/UI. Los equipos son los responsables de clarificar los requisitos con los clientes y los usuarios finales.

En pocas palabras un equipo multifuncional es aquel que:

• En su conjunto es autosuficiente.
• Tiene el conocimiento y habilidades necesarias para construir la parte del producto que le corresponde.
• La especialidad de cada miembro puede ser complementada por algún otro miembro del equipo.

Las organizaciones, tradicionalmente han tratado de resolver los problemas urgentes añadiendo más complejidad.

Por ejemplo: Supongamos que nuestro producto tiene un bug en producción porque a un equipo se le olvidó ejecutar un test. La reflexión del jefe sería imponer todos los pasos del proceso como si se tratara de una receta de cocina, asignando a alguien alguna nueva responsabilidad, rol o nuevo departamento para evitar este error en el futuro. Es decir, añadir más procesos, roles y herramientas. Pero el hecho de añadir esta “mejora”  puede empeorar los problemas subyacentes, ya que internamente o subconscientemente estamos reduciendo la responsabilidad del equipo. Cuando realmente no hace falta buscar soluciones tan complejas para solucionar el problema subyacente (aquí es donde viene el principio “More with LeSS” que vimos anteriormente”. En LeSS, los Scrum Masters, ayudan a los equipos a aprender, el enfoque es que, en lugar de dar órdenes directas, mejoremos las capacidades del equipo para que se auto-organice y puedan resolver ellos los problemas.

LeSS proporciona numerosos talleres experimentales, guías y recomendaciones que ayudan a entender el framework. Además de una explicación más detallada de los principios nombrados anteriormente. Para ver más puedes ver su página web.