¿Qué hay detrás de desescalar para escalar?

Cuando en Agilidad hablamos de escalar de lo que estamos hablando es de escalar Scrum de un solo equipo a un Scrum escalado a equipos de equipos en grandes empresas.

Si nos situamos en Scrum y recordamos las características de los equipos de Scrum, veremos que se trata de equipos multifuncionales y autoorganizados, idealmente de equipos con independencia en habilidades y toma de decisiones para poder construir cosas de principio a fin. Podemos entender de que se trata de una estructura plana en la que la relación entre los roles es de iguales, y que todos ellos tienen responsabilidades complementarias que no se pisan unas a otras.

LeSS Escala Scrum Desescalando
Thanks to Gene Gendel

Por tanto cuando hablamos de escalar Scrum estamos hablando de escalar estructuras planas. Las estructuras de grandes empresas suelen ser estructuras muy jerárquicas que sobrecargan los flujos de valor con desperdicio (retrasos, burocracia, actividades que no agregan valor) y que por tanto suelen representar cuellos de botella que afectan seriamente al time-to-market. Una transformación ágil debe de tratar, entre otras, de desescalar y aplanar estas estructuras jerárquicas para eliminar esos cuellos de botella y acelerar el flujo de valor.

La aproximación de LeSS(Large-Scale Scrum)

El primer propósito de LeSS es desescalar a través del cambio organizacional. Desescalar el número de roles, estructuras organizativas, dependencias, complejidad arquitectónica, mandos intermedios, localizaciones y número de personas. LeSS no trata de escalar un equipo a varios equipos, LeSS trata de escalar Scrum para lograr el desescalado organizacional.

El objetivo principal de LeSS en esa desescalada es exponer crudamente el dolor de ser grande, derrochador y lento. Para ello propone el modelado sistémico averiguando las variables que existen en el sistema, cuales son relevantes para la empresa y como estas están interrelacionadas para maximizar las deseables y quitar las que son desperdicio a través de círculos virtuosos y viciosos.

La aproximación de SAFe (Scaled Agile Framework)

SAFe aborda la desescalada de manera diferente introduciendo un segundo sistema operativo organizacional, que aplicado a la estructura jerárquica existente crea una red empresarial centrada en el cliente con equipos y trenes (ARTs) autorganizados, que por ende son estructuras desescaladas paralelas a la jerarquía.

SAFe desescala a través del segundo sistema operativo organizacional a flujos de valor (Value Streams) y trenes (ARTs)
Imagen del tema Business Agility cortesía de © Scaled Agile, Inc.

La jerarquía tiene su razón de ser, necesitamos una jerarquía de liderazgo y de flujo de comunicación cuando hablamos de empresas de miles de empleados, por tanto en grandes empresas probablemente no podamos prescindir de estas. Utilizando el marco de SAFe como segundo sistema operativo organizacional introducimos el noveno principio de SAFe, la descentralización de la toma de decisiones, que desescala llevando las decisiones allí donde está la información dentro de las estructura de red empresarial.

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

¿Existe una simulación para experimentar el WIP en una simulación Kanban?

Meetup "Featureban" organizado por Agile Women

Justo antes de la crisis del COVID-19 el grupo de meetup Agile Woman organizó un meetup sobre Featureban, un juego de simulación para Kanban creado en 2014 por Mike Burrows que es muy poderoso, simple, divertido y que propicia la reflexión.

El juego muestra de forma sencilla como implementar la gestión visual en nuestros primeros tableros Kanban, para luego introducir límites WIP y gestionar y acelerar el flujo de trabajo.

Cuando sobrevino el COVID-19 tuvimos que aprender a realizar todas nuestras actividades, incluidas las formaciones, de forma remota. Para nuestros cursos de Kanban en Estratecno fue necesario encontrar una simulación de Kanban que mostrara el funcionamiento de los límites WIP... y allí estaba la versión on-line e interactiva de Featureban de uso gratuito que Kaiten ha creado y puesto a disposición de la comunidad.

El tablero en formato físico original y en formato on-line

El tablero de la simulación es relativamente simple, tiene cuatro estados: "Ready/Queue", "Doing", "Validating" y "Complete/Done". La simulación trata de mover una serie de fichas de "Ready/Queue" a "Done", y una moneda (cara/cruz) o dos naipes (rojo/negro) introducen la variabilidad del día a día para indicar si fue un buen o un mal día. Simplificando la reglas en un buen día el jugador avanza una ficha o desbloquea una ficha propia o la de otro, y en un mal día bloquea una de sus fichas.

Se juega con al menos 3 jugadores y cuenta con 3 ciclos o iteraciones. El primer ciclo se ejecuta sin limitar el WIP y en los dos siguientes se limita "Doing" y "Validating" con un WIP = 3. La diferencia de los ciclos 2 y 3 está en que en el segundo ciclo se parte de la situación final del primer ciclo, y en el tercer ciclo de una situación de cero.

Al terminar cada ciclo los jugadores hacen una retrospectiva sobre qué han aprendido y qué decisiones y acciones de mejora pueden incorporar para los siguientes ciclos y así acelerar el flujo.

Dos situaciones del juego en on-line, una con una carta roja (buen día), y otra con una carta negra (mal día)

El primer ciclo se inicia sin limites WIP y las monedas o cartas con sus movimientos y bloqueos se encargan de llenar el tablero con largas colas de fichas en "Doing" y "Validating", provocando una pobre entrega en "Complete/Done".

Plantillas para registrar tiempos de ciclo

Al introducir límites WIP en el segundo ciclo obligamos a los jugadores a colaborar y a tomar decisiones a favor del flujo para ir deshaciendo poco a poco el caos del primer ciclo. Los jugadores descubrirán al final del ciclo que la entrega de fichas es sensiblemente superior a la del primer ciclo.

El tercer ciclo, en el que se parte de una situación desde cero y donde la entrega de fichas es todaví mayor, muestra de nuevo la potencia de los limites WIPs y de como éstos fomentan la colaboración.

La simulación incluye plantillas para tomar métricas y dibujar un diagrama de flujo acumulado (CFD). En el caso de la simulación on-line las métricas y el resumen se generan forma automática.

Podemos observar buenos resultados en la imagen que sigue más abajo:

• Los ciclos o iteraciones 1 y 2 han resultado en la entrega de 11 fichas, mientras que el ciclo 3 ha resultado de por si solo en la entrega de 13 fichas. ¡Más fichas en la mitad de tiempo!
• El CFD muestra una pendiente para "Doing" y "Validating" con cierta homogeneidad, lo que muestra un buen flujo y por ende una buena colaboración entre los jugadores.

Resumen que da de forma automática la simulación on-line

Para aquellos que quieran facilitar la simulación on-line de Kaiten pueden descargar The Facilitator Guide que Evgeniy Stepchenko ha puesto disposición de la comunidad.

---

Actualización marzo 2021

Recientemente Featureban ha añadido a la simulación 3 nuevas características muy interesantes:

• Ya es multidioma y podemos jugar en castellano (spanish)
• Podemos seleccionar entre un juego de fichas de TI (informática) y uno de Marketing
• Y podemos cargar nuestro propio juego de fichas :-)

Nuevas características de Featureban: Fichas de Marketing e idioma ES

¿Criterios de aceptación o condiciones de satisfacción?

La satisfacción del usuario es clave para calidad y compromiso
cortesía de Pixabay

Hemos tenido mucho debate sobre si los criterios de aceptación son una práctica ágil.

Recordemos que la parte importante de las historias de usuario es la conversación. Cuando las visualizamos como descripción corta en un post-it lo que estamos haciendo es comprometernos a conversar sobre estas más adelante.

Algunas compañías buscan en los criterios de aceptación un lugar donde escribir una especificación detallada y precisa para mantenerse lo más cerca posible de especificaciones detalladas tradicionales. Lo hacen agregando detalle como criterios de aceptación en lugar de hacerlo de forma ágil, que consiste en agregar detalle dividiendo la historia en historias más pequeñas.

Imaginemos la siguiente historia de usuario:

Como viajero

Quiero seleccionar las fechas de ida y de vuelta

Para poder comprar los billetes de tren e ir de vacaciones

con los siguientes criterios de aceptación:

Comprobar que las fechas no son un momento previo a la mayoría de edad del usuario

Comprobar que las fechas no sean un momento anterior al actual

Comprobar que la fecha de vuelta no es anterior a la de ida

Comprobar que el formato fecha se corresponde al formato aceptado por el sistema (DD/MM/AAAA)

El término "criterios de aceptación" puede llevar a un equipo de desarrollo a que no se sienta involucrado en la definición de la historia. Simplemente puede que se limite a tomar cada uno de los criterios e implementarlos uno a uno. Si finalmente el resultado no se comporta como hubiéramos deseado es porque el Propietario del Producto no ha incluido algún criterio de aceptación faltante.

Mike Cohn habla de condiciones de satisfacción, como condiciones específicas de una historia de usuario y que definen lo que debe ser cierto para que ese elemento de la pila se considere hecho.

Utilizando condiciones de validación en la historia del ejemplo anterior quedaría:

El usuario puede operar cuando a la fecha de ida sea mayor de edad

El usuario puede comprar un billete cuando las fechas seleccionadas sean posteriores al momento actual

El sistema no permitirá avanzar al usuario en la compra si las fechas no son coherentes

El formato de fecha con el que opera el sistema es DD/MM/AAAA

Con el término "condiciones de satisfacción" el equipo está enfocado en resolver el problema del usuario en lugar de implementar los criterios definidos anteriormente. Toda implementación de una historia de usuario debe de comenzar con una conversación que culmina en la planificación de sprint, conversación en la que el equipo debe de hacerse preguntas como:

• ¿Cómo podemos ofrecer el mayor valor con el menor esfuerzo?
• ¿Cuál es la funcionalidad mínima que tenemos para ofrecer?
• ¿Cómo podemos abordar las necesidades del usuario?

Bajo esta perspectiva podemos entender la definición de hecho (DoD) como un conjunto especial de condiciones de satisfacción que se agregan a toda historia de usuario.

Aprender a utilizar condiciones de satisfacción puede tomar un poco más de tiempo al principio, pero vale la pena invertir en este esfuerzo, ya que un equipo comprometido con el producto siempre puede encontrar mejores soluciones que un Propietario del Producto que escriba criterios de aceptación en solitario.

En mi opinión las condiciones de satisfacción ayudan a enfocar en lo que importa, aunque ninguna de las dos opciones es mejor que la otra, depende de como se usen.

¿Hay algún patrón adecuado para escribir epics?

A/B Testing, una forma de validar una hipótesis
cortesía de Icons Icons

Recordemos que un epic se puede considerar como una superhistoria de usuario que se distingue por su gran tamaño, como una etiqueta que aplicamos a una historia grande cuyo esfuerzo es demasiado grande para completarla de una sola vez o en un solo sprint. A diferencia de las historias de usuario, que tienen baja granularidad, los epics tienen una alta granularidad y un alto grado de incertidumbre asociados. Realmente cualquier epic, e incluso una historia de usuario, no es más que una hipótesis; hasta que nuestro usuario la vea o la utilice y nos de feedback no sabremos si es la solución adecuada.

Desde este punto un epic lo podemos entender como una serie de experimentos, futuras historias de usuario, que construyen funcionalidad de forma incremental hasta llegar al resultado esperado. Esta forma de desarrollar epics ocurre como ciclo Lean Startup que mediante el desarrollo guiado por hipótesis, o hypothesis driven development (HDD), trata de desarrollar nuevas ideas, productos y servicios. A través de ciclo de feedback vamos validando nuestra hipótesis de manera que el Propietario del Producto gane comprensión sobre la solución más adecuada.

Como ejemplo está la técnica A/B Testing, que se utiliza en el ámbito del Marketing Digital y la Analítica web, que trata de identificar la mejor solución para un epic construyendo dos soluciones y realizando experimentos aleatorios con las dos variantes, A y B, siendo una la de control y la otra la variante. ¿No os ha pasado que lo que veis en Amazon en vuestro dispositivo es diferente a lo que ve vuestro compañero?

Barry O'Reilly popone el siguiente patrón en su artículo "How to Implement Hypothesis-Driven Development":

Creemos que [esta capacidad]

Resultará en [este resultado]

Tendremos confianza para proceder cuando [veamos una señal medible]

Patrón HDD de Barry O'Reilly

Creemos que [esta capacidad]

Responde a la pregunta ¿Qué funcionalidad desarrollaremos para probar nuestra hipótesis? Al definir la capacidad de una "prueba" del producto o servicio que estamos intentando construir, identificamos la funcionalidad y la hipótesis que queremos probar.

Resultará en [este resultado]

¿Cuál es el resultado esperado de nuestro experimento? ¿Cuál es el resultado específico que esperamos lograr al desarrollar la capacidad de "prueba"?

Tendremos confianza para proceder cuando [veamos una señal medible]

¿Qué señales indicarán que la capacidad que hemos construido es efectiva? Qué métricas predictivas clave (Leading Indicators) cualitativas y/o cuantitativas mediremos para proporcionar evidencia de que nuestro experimento ha tenido éxito y darnos suficiente confianza para pasar a la siguiente etapa.

Ejemplo de un epic de negocio escrito con este patrón:

Creemos que aumentar el tamaño de las imágenes de los restaurantes en la página de reserva

Resultará en una mejor participación y conversión del cliente

Tendremos confianza para proceder cuando

veamos un aumento del 5% en los clientes que revisan las imágenes de los restaurantes

y luego proceden a reservar en los próximos 2 minutos

My thanks to Barry O'Reilly on who I have based and who inspired me for this post :-)