¿Cómo solucionar los problemas de escalado en Agile? | CAS2018 Alicante

Hoy hablamos con Laura Grau, Agile Leader en GFT España y una de nuestras compañeras de la sede de Valencia, acerca de su taller sobre PI Planning en la Conferencia Agile Spain (CAS).

Laura ha participado (nuevamente, porque ya fue ponente en 2016), en la última edición de CAS, celebrada hace apenas unas semanas en Alicante. En esta ocasión, ha impartido un taller práctico en el que ha simulado celebrar un PI Planning, compartiendo su experiencia como Release Train Engineer con los asistentes.

Fuente imagen: CAS 2018 (día 1: 13 diciembre)

Raquel Benito: Laura, tu taller estaba muy enfocado a los problemas del escalado pero ¿cómo casan los conceptos de Agile y escalado?

Laura Grau: Hoy en día no hay duda de que el desarrollo de producto sin seguir una filosofía agile (y todas las variantes de este término) no está acorde a las demandas del mercado. Debemos acertar rápido, con lo cual, “¿por qué no ir entregando “cositas” pequeñas y tanteando cómo reacciona el usuario?” Poder recalibrarnos sin perder una gran inversión es nuestro objetivo. Para esto, todas las guías y libros de cómo trabajar siguiendo unos principios ágiles, nos recomiendan tener un equipo de desarrollo de producto en el que combinemos todos los skills necesarios para entregarlo, un equipo de producto empoderado para tomar decisiones porque está demostrado que las mejores soluciones emergen de la gente que está “haciendo” el trabajo, un equipo que aumente el ancho de banda de la comunicación estando cerca, viéndose face-to-face

Y, sin embargo, a veces, nos encontramos con que, para poder hacer esos “cachitos” pequeños, un equipo no nos da la velocidad suficiente para poder entregar a ese mercado que nos está esperando, y decidimos coordinar varios equipos para trabajar ese mismo backlog de producto. En ese momento hemos tomado una decisión, “vamos a escalar”, y hemos comprado un problema “el escalado”.

Y normalmente, no sólo somos “más”, sino que, además, estamos distribuidos en localizaciones y zonas horarias e ¡incluso en culturas diferentes! ¿Cómo hacemos para mantener nuestro flujo de entrega de forma coordinada y sin perder nuestro espíritu ágil? Hay frameworks en el mercado que ofrecen herramientas para ayudar a resolver los problemas inherentes al escalado en un entorno ágil. En el taller de la CAS proponíamos visualizar cómo la herramienta del PI de SAFe puede ayudar en parte de esos problemas.

R: Desde tu experiencia, ¿cuál es el framework que prefieres o que recomendarías usar?

L: Si me hubieras hecho esta pregunta hace unos años, habría elegido un nombre entre los que existen en el mercado – hay varios que han emergido en los últimos años y que se están haciendo su hueco: SAFe, LeSS y Nexus, por ejemplo, son los más reconocidos, pero hay muchos otros e incluso implementaciones como el de Spotify que hacen furor. Sin embargo, me haces esta pregunta hoy, y te contesto que no puedo recomendar uno sin saber en qué contexto vamos a trabajar. Lo que me gusta es conocerlos y utilizarlos como herramientas, como palancas de cambio. En algún entorno, venderá mejor SAFe porque es un modelo de diseño empresarial, y representa mejor algunas figuras que, en otros modelos como Nexus, no aparecen. No quiere decir que uno es mejor que otro, es simplemente distinto el para qué está enfocado cada uno.

Nosotros ahora mismo estamos trabajando sobre el marco de SAFe, con pinceladas de LeSS por ejemplo. Mi recomendación es que, cuando vayas a tomar una dirección de cambio pregúntate si estás siguiendo principios lean y agile, si es así, “go for it”.

Fuente imagen: https://www.scaledagileframework.com/

R: ¿Cómo planteaste este taller?

L: Ya que la propuesta era trabajar en modo taller, quisimos plantearlo de manera que la experiencia fuera la pieza clave del aprendizaje:

En una primera parte, trabajamos como equipos agile independientes y un mismo backlog de producto. Sin utilizar ningún framework y sin ningún tipo de herramienta de soporte al escalado. ¿Qué ocurrió? Pues que, al poco, comenzaron a surgir los primeros “problemas” de escalado, integración, patrones de diseño diferentes, niveles de aceptación distintos… Comparamos con la realidad de nuestro día a día, y fue incluso divertido ver que nos había sucedido a todos en algún momento de nuestra vida profesional!

La segunda parte estaba enfocada a presentar las soluciones que una herramienta como el PI Planning de SAFe nos ofrece para solucionar los problemas que nos habíamos encontrado. Los PI plans se diseñan según una agenda que nos da un marco de trabajo para esos días, donde se incluyen presentaciones de la visión, contexto y los objetivos del negocio y ciclos de creación de un plan conjunto con su identificación de riesgos y dependencias, y por supuesto, una retrospectiva para seguir siempre mejorando.

Para el desarrollo de este taller, tuve la suerte de contar con dos de mis compañeros en GFT: Jorge Bellver y Carlos Piqueres, que me ayudaron durante el desarrollo de la sesión. Jorge hizo el papel del Arquitecto Agile, marcando las guías y patrones de la arquitectura de nuestro producto; y Carlos, se metió completamente en el papel del Product Owner.

Yo había participado desde hace años en PI plannings para clientes de GFT, sin embargo, desde finales de 2017 he tenido la oportunidad de no sólo participar, sino de diseñar y organizar más de 7 PIs con nuestros clientes… todo un reto, si tenemos en cuenta que las sesiones son de dos días y que hemos contado con más de 110 asistentes en los últimos tres PI plannings… es una satisfacción llegar al final del segundo día y ver que hemos construido un plan entre todos, y que es un plan entendido por todos. Pero es una satisfacción mayor el volver en el tren de vuelta a casa y escuchar a los equipos hablando entre ellos, diciendo cosas como “el saber hacia dónde voy yo y los que trabajan a mi lado me da tranquilidad, me va a ayudar a hacer mejor las cosas” o “la verdad es que hemos desbloqueado un montón de dudas y vamos a poder avanzar mucho más rápido ahora”.

R: ¿Cómo se prepara un PI Planning?

L: La preparación es clave en el diseño de un PI. Sin una buena preparación, los beneficios del PI se pierden y se convierte en una ceremonia más que “hay que hacer porque lo dice el framework”.

Para empezar, SAFe te da un patrón para arrancar que describe las áreas de preparación: organización de tu tren, equipos, roles… preparación del contenido y ¡la logística! (nada despreciable este último punto si tenemos en cuenta que, muchas veces, no es solo coordinar la sala, sino los viajes, los hoteles, asegurarse de que la fecha de la agenda está acordada con todos, organizar una agenda que cubra todas las necesidades y, aun así, ofrezca espacio para temas nuevos que aparezcan durante el PI…) A medida que vas ganando experiencia, diseñas tu propio backlog de preparación de un PI que, además, se va nutriendo del feedback de los equipos, cada vez que ejecutamos uno más.

Como recomendación, si podéis, diseñad el tren para empezar pequeño, y lanzaos a una PI Planning con dos o tres equipos en vez de, directamente, con 100 personas, me lo agradeceréis. Como RTEs, está en vuestra mano el poder diseñar este ejercicio y os aseguro que no es fácil, pero es muy enriquecedor.

Fuente imagen: CAS 2018 (día 1: 13 diciembre) ) |
Laura, a la derecha, durante la sesión de PI Planning en la #CAS2018

R: Y después de un PI Planning, ¿qué viene?

L: Cuando acaban esos dos días, parece que todo termina aquí. Sin embargo, bien entendido, este es el principio, es el arranque de nuestro siguiente incremento y tenemos que llevarlo a cabo todos juntos.

Hemos trabajado en diseñar nuestras siguientes iteraciones, en identificar riesgos y dependencias… La vuelta a casa, en un entorno de escalado, implica que no estaremos todos delante de ese gran panel que hemos creado y, aun así, pasados estos dos días, queremos seguir teniendo nuestra representación de hacia dónde vamos y en qué condiciones hemos decidido avanzar.

Cualquiera que sea nuestra herramienta de gestión de backlog, al acabar un PI, tenemos que nutrirla con toda la información y asegurar que ponemos en marcha seguimiento de los riesgos y las dependencias que hemos identificado. Muy importante también es la trazabilidad del resultado de la retrospectiva del PI: debemos trabajar en proponer acciones de mejora para que la próxima iteración del PI, del Planning y de la ejecución, se acerque más a lo que necesitamos.

Y por supuesto…. trabajo de implementación y perfeccionamiento de nuestro plan: Hemos acordado un punto de partida del camino, ahora nos toca recorrerlo, avisarnos si nos desviamos, adaptarnos si aparecen piedras o nuevos senderos que recorrer…y seguir buscando en esa guía de viaje, para ir preparando el equipaje para la nueva escala en el camino… ¡que llega en 2 meses y medio con el nuevo PI planning!

R: Y para terminar, ¿algo a resaltar de la CAS de este año?

L: La verdad es que, de nuevo, ha sido una experiencia enriquecedora. Me vuelvo con contactos y con mucha información para leer o para poner en marcha directamente. La organización este año, con compañeros como Federico Casabianca o Jorge Muria, ha vuelto a sorprender y a hacer un trabajo excepcional. En mi caso en particular, sé que hubo mucho trabajo detrás de la logística para la preparación del taller (¡como en un PI de verdad!), así que no puedo sino agradecerles todo el buen trabajo para la puesta en marcha. ¡Gracias!

Si quieres saber más acerca de la CAS, ¡echa un vistazo a este vídeo resumen del evento! O a este post de la organización en Medium

GreenCoding

Con GreenCoding el desarrollo de software se convierte en parte integrante de tu programa de sostenibilidad

Más información