¿Cómo mostrar la autoorganización en un ART?

El evento core de SAFe® es la PI Planning, el evento presencial en que el estamos todos juntos (los de negocio, de producto y de desarrollo), y que funciona en cadencia a manera de latido para tren (ART- Agile Release Train). De manera autoorganizada ocurre el alineamiento y compromiso de todos los equipos del ART y bajo una visión, misión y objetivos compartidos.

No hay magia en SAFe... excepto quizá en la PI Planning

Scaled Agile

Historias de Usuario del módulo #3: PI Planning

Desde Estratecno quisimos montar un meetup para probar la autoorganización en un tren en toda su dimensión. Miguel encontró la SAFe City Simulation de Mark Richards y del equipo de CoActivation, que se basa en una metáfora no técnica, como es la construcción de ciudades, para llegar a audiencias que no sean de tecnología, así que Ángel y yo nos lanzamos y preparamos el meetup con la Simulación SAFe City :-)

Las tarjetas con las historias de usuario, las dispositivas de la introducción y el manual para el facilitador están disponibles en la página de los autores: SAFe City Simulation.

Tras una breve introducción y repaso de los conceptos de una PI Planning, iniciamos esta simulación de planificación cruzada que hace hincapié en el poder de la planificación colaborativa y la capacidad del enfoque de PI Planning de SAFe para permitir a los equipos optimizar de forma autoorganizada y colaborativa las dependencias internas en un ART y resaltar los cuellos de botella del flujo.

Planificación

Tablero de dependencias

Agile Kids, un equipo de constructores y su tablero :-)

El tren estuvo formado por una combinación de equipos constructores (funcionales) y uno de especialistas (de componentes), a los que les entregamos un conjunto de funcionalidades (features) e historias de usuario con numerosas dependencias entre equipos constructores y especialista para que de forma autoorganizada construyan un plan durante el breakout. Los outputs fueron los siguientes:

• Objetivos de cada equipo (factibilidad)
• Tablero de dependencias resueltas (Program Board)
• Identificación de riesgos

Los tres outputs son producto de la autoorganización a nivel del tren; los objetivos de equipo individuales están alineados con los objetivos del tren, el entramado de dependencias es resultado directo de acuerdos entre equipos y los riesgos y su posible mitigación es consenso de todo el tren.

El tiempo de juego fue de aproximadamente 1 hora 45 minutos, se repartió de la siguiente manera:

• Introducción y configuración (30 minutos)
• Planificación (1 hora minutos)
• Conclusiones (15 minutos)

Equipo de especialistas, fontaneros y electricistas en las Termópilas. ¡Parecían 300!

Tablero de los especialistas

Al acabar la simulación solo hicimos un par de preguntas: ¿Habéis sentido la autoorganización a nivel del tren? ¿Habéis sentido como planificamos los 7 equipos de forma colaborativa? Las respuestas fueron entre otras:

• He vuelto a sentir lo que es una PI Planning
• Me ha ayudado mucho a entender la dinámica del PI Planning
• Tengo una visión de la PI Planning
• Una fantástica experiencia! Con muchas ideas y reflexiones para aplicar en la PI Planning

Un feedback que me ha emocionado fue el siguiente:

• SAFeCity: SAFe no es una estructura que soporta el negocio tradicional. Las herramientas y los procesos pueden ser o no ágiles, el que lo ve Agile eres tú.

The making of :-)

Para quién quiera probar la simulación le recomiendo hacerlo en una mañana y hacer los 3 módulos que propone Mark Richards seguidos. Nosotros nos focalizamos en el tercer módulo, con lo que la visión y el establecimiento de objetivos comunes fue poco potente y resultó en el punto de mejora propuesto por la mayoría de asistentes.

Lo que hagas, hazlo con pasión

Steve Jobs

Descargas / Downloads

La Presentación y las Historias de Usuario

Quiero dar mis agradecimientos a Miguel y a Estratecno por creer en nosotros, en SAFe e impulsarnos a hacer estos meetups, a David por apoyarnos y a gestionar con RyanAir Labs el aportar el local, cervezas y tortillas :-), a Bria y a Ryan por el apoyo de Scaled Agile y a Ángel con el que formo equipo de primera y a todos los asistentes por su colaboración e ilusión

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

¿Cuál es una buena técnica para construir una hoja de ruta?

Tablero con una hoja de ruta
cortesía de Alexandre Magno

Imaginemos que tenemos nuestra visión del producto y estamos listos para obtener la hoja de ruta. Una de las mejores técnicas es la denominada "recuerda el futuro" o "remember the future", la que voy a presentar en este post.

Si construimos la hoja de ruta partiendo de la fecha actual hacia adelante, lo que ocurre es que pensamos en pasos pequeños y de lo que el producto debería hacer después de cada uno de ellos, como extrapolación razonable de lo que ha hecho anteriormente. Así pensamos en pequeñas mejoras, y dado que somos pesimistas, llenaremos el camino de buffers y pasos a menudo triviales.

Si recordamos el futuro empezamos por proyectarnos en el futuro, a un estado de éxito al que queramos llegar, y luego vamos dando pasos hacia atrás. "Recuerda el futuro" es una dinámica colaborativa, por tanto deben de estar presentes todos los interesados de negocio, los Propietarios del Producto y el cliente si fuera posible.

Dibujamos una línea de tiempo y empezamos por el final, por cuando tengamos pensado lanzar el producto. El marcado de ese final generará mucha conversación alrededor de para cuando tiene sentido lanzar el producto. Esa conversación generará informaciones cruzadas que son la clave para una buena estrategia, por ejemplo marketing podría revelar que la competencia lanzará un producto similar en noviembre, entonces podríamos decidir marcar octubre para el lanzamiento. Si creáramos una hoja de ruta basada en un plan detallado de ventas podríamos acabar lanzando nuestro producto después de la competencia y no darnos cuenta.

Para proyectar el estado de éxito pedimos a los asistentes que imaginen que están más allá de esa fecha de lanzamiento, que el producto ha sido un éxito y que han estado utilizándolo de forma casi continuada. De esta manera estamos respondiendo a la pregunta "¿qué habremos hecho?", pensar en un éxito futuro como ya completado nos permite tomar decisiones más efectivas al reducir el conjunto total de resultados posibles. Entonces podremos responder a la pregunta "¿cómo lo hicimos?", y ya podemos imaginar una secuencia de beneficios u outcomes obtenidos hacia atrás, generando descripciones creativas y ricamente detalladas de los mismos.

Si fuéramos hacia adelante en el tiempo nos haríamos la pregunta "¿qué deberíamos de hacer?" con lo que no tendríamos un marco de referencia para comparar, no asumiríamos el éxito y posiblemente nos perderíamos pensando en si es posible conseguir el siguiente beneficio u outcome.

Para construir la hoja de ruta:

• Paso 1: Pedimos a los participantes que imaginen que están en el futuro y que han logrado el éxito.
• Paso 2: Pedimos que vayan más allá: un día, semana o mes...
• Paso 3: Pedimos a los participantes que anoten con el mayor detalle posible, qué aspecto tiene el éxito, qué beneficios u outcomes han obtenido.
• Paso 4: Retrocedemos en el tiempo al siguiente punto de éxito y les pedimos que respondan a la pregunta "¿qué habrá pasado para que ese estado de éxito sea cierto?"
• Paso 5: Iteramos "¿y justo antes de eso?"... ¿y antes de eso?... y así crearán la linea del tiempo a la inversa recordando el futuro.

El resultado será una hoja de ruta con los beneficios u outcomes sobre la línea de tiempo. Esta es la linea de tiempo principal, podemos hacer otras líneas opcionales paralelas con historias de usuarios (outputs) o riesgos por ejemplo. Si hiciéramos más de una linea de tiempo es importante resaltar que debemos de trabajar en una sola a la vez, nunca en paralelo, perderíamos el foco.

¿Cuál es el rol de un Scrum Master en un marco de escalado como SAFe®?

Equipo de Scrum Masters y coaches ágiles que ha hecho posible
el éxito del Town-Hall, un honor formar equipo con vosotros :-)

Cuando escalamos Agilidad los roles que conocemos pueden variar ligeramente con respecto a cuando hacemos Scrum en un sólo equipo. Por ejemplo, un Propietario del Producto no puede tener la cabeza centrada en los equipos a la vez que la tiene en el producto y en el negocio cuando el producto es grande y hay varios equipos trabajando en él. SAFe® le da solución al problema definiendo Propietarios del Producto enfocados en las pilas de los equipos, e introduciendo otro rol, que denomina Product Manager, que está enfocado en la pila a nivel de programa, y que es quién interacciona con clientes e interesados y que está cercano a negocio. De manera similar el rol del Scrum Master en un entorno escalado tiene sus variaciones.

En el marco de LeSS, el marco de adopción para compañías con madurez en Agilidad, el Scrum Master ayuda a las personas y equipos a ver al sistema y al producto de forma holísitica: esto es clave porque la entrega no integrada de equipos individuales no crearía valor para el cliente. Un LeSS Scrum Master encontrará problemas complejos a gran escala e intentará encontrar formas simples de empoderar a las personas para que resuelvan sus impedimentos. En este enfoque se amalgaman Scrum Master y coach ágil.

En el modelo Spotify original directamente no existen Scrum Masters, sólo un coach ágil por tribu. El modelo emergió de una empresa con los valores ágiles fuertemente ligados a su cultura con lo que éstos no son necesarios.

Las compañías cuya cultura es tradicional e inician una transformación ágil a nivel escalado necesitan Enterprise Agile Coaches experimentados para acompañar e liderar la transformación a nivel estratégico y organizacional, coaches ágiles para acompañar a las áreas, equipos de equipos, tribus y trenes (ARTs), y estos coaches ágiles necesitan Scrum Masters "ojos y manos" en cada uno de los equipos individuales.

SAFe es el marco de escalado idóneo para compañías tradicionales que dan sus primeros pasos a nivel escalado, y describe muy bien esa idea de Scrum Masters "ojos y manos" que colaboran con el coach ágil, el RTE (Release Train Engineer), que es líder a su servicio. A semejanza del Propietario del Producto, el Scrum Master esta centrado en los equipos de desarrollo, y el RTE es quien lidera la adopción en el tren, el ART (Agile Release Train), y quién lidia con los impedimentos sistémicos que impiden la buena marcha del mismo. A continuación muestro un resumen del rol, podéis profundizar en el artículo original sobre el "Scrum Master en SAFe":

El rol de Scrum Master es un rol especial para uno de los miembros del equipo con habilidades de liderazgo al servicio que pasa gran parte de su tiempo ayudando a otros miembros del equipo a comunicarse, coordinarse y cooperar, para fomentar la autogestión y autoorganización del equipo; en general, este ayuda al equipo a cumplir sus objetivos de entrega a través de prácticas ágiles efectivas. El Scrum Master también ayuda al equipo a coordinarse con otros equipos del tren y comunica el estado al RTE según sea necesario. Ayuda a educar al equipo en Scrum, eXtreme Programming, Kanban y SAFe, asegurando que se siga el proceso ágil acordado.

Responsabilidades con el equipo

El Scrum Master SAFe efectivo es un líder al servicio de equipos que:

• Exhibe liderazgo Lean-Agile
• Apoya y refuerza las reglas acordadas
• Facilita el progreso del equipo hacia el objetivo
• Lidera los esfuerzos del equipo en su proceso de mejora continua
• Facilita las reuniones
• Apoya al Propietario del Producto
• Gestiona los impedimentos, los que se encuentren fuera del tren los escala al RTE
• Crea un equipo de alto rendimiento
• Protege y comunica
• Promueve la entrega continua y otras prácticas técnicas

Responsabilidades en el tren

El Scrum Master ayuda a coordinar la cooperación entre equipos y ayuda al equipo a funcionar como un equipo efectivo que se sienta parte del tren:

• Coordina con otros equipos
• Promueve la cultura y las herramientas de DevOps
• Facilita la preparación de los eventos del tren
• Apoya en la estimación normalizada en el tren

SAFe adopta un enfoque pragmático y asume en general que el Scrum Master es un rol a tiempo parcial asumido por un miembro del equipo, y promueve que durante la adopción inicial de SAFe, cuando el rol puede ser más intensivo, la organización considere la inclusión temporal de un Consultor del Programa SAFe (SPC), interno o externo, para entrenar a los equipos y Scrum Masters para adquirir rodaje y experiencia en las prácticas de SAFe

Mi agradecimientos a Mónica, Andrés, Patricia, Nacho, Pilar y Nacho por formar equipo conmigo y por la foto :-D

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

¿Sprinta el equipo o el producto?

En más de una ocasión he oído la expresión "el equipo está sprintando", yo mismo he utilizado expresiones como "en escalado los equipos han de sprintar sincronizados". Detrás de "sprintar" está la idea de que el equipo de desarrollo ha aprendido a planificar historias de usuario, a empezarlas y a terminarlas totalmente antes de acabar el sprint, la fase más crítica en una implantación de Scrum. Cuando el equipo ha aprendido a "sprintar", a encontrar su ritmo de entrega, es cuando empieza a acelerar.

Hace poco me topé con Jaume, quién me contó que lo que realmente "sprinta" es el producto... tomando perspectiva, Scrum es una gestión de entrega incremental de producto en la que el equipo entrega con cada sprint un incremento de producto terminado, un resultado completo potencialmente desplegable en producción. No cabe duda, es el producto quién "sprinta".

Considerar que el equipo "sprinta", que construye con cadencia, nos lleva a una disfunción muy propia de equipos poco maduros. Aquellos que afirman que sus historias de usuario son indivisibles y por tanto se han de construir en dos o más sprints, y creyendo que aplican Scrum, obvian que una historia de usuario no puede ser mayor que la que cabe en un solo sprint.

Scrum es un gestión de entrega incremental de producto - cortesía PixaBay

Mis agradecimientos a Jaume Jornet, un espíritu ágil que me hace reflexionar cada vez que nos encontramos :-)

¿Es Scrum Manager a LeSS como Scrum Alliance a SAFe®?

Actualmente existen diferentes entidades/comunidades que certifican y promulgan la Agilidad, todas ellas toman los valores del Manifiesto Ágil, y entre ellas están las que se centran en la Agilidad a nivel de equipo y las que tratan la Agilidad escalada.

Veamos primero las principales a nivel de equipo:

Scrum Alliance:

"Fundada en 2001, Scrum Alliance es la entidad de certificación y comunidad profesional más grande establecida e influyente de la comunidad Agile... Nuestra visión es "transformar el mundo del trabajo" con la misión de guiar e inspirar a personas, líderes y organizaciones con prácticas, principios y valores que creen lugares de trabajo alegres, prósperos y sostenibles... Como organización sin fines de lucro, nos enfocamos en crear valor para nuestros certificadores y miembros al inspirar, habilitar y guiar el uso de Scrum y otros métodos ágiles para crear entornos de trabajo efectivos y colaborativos".

El foco principal de la Scrum Alliance es preparar y guiar a profesionales en la aplicación de Scrum, un avance evolutivo del trabajo que se realiza a través de sprints. Para ello se basa en la guía oficial de Scrum que describe el marco y sus reglas, un conjunto de prácticas concretas que se deben realizar en un marco definido de artefactos, roles y eventos.

El marco de Scrum, el foco principal de la Scrum Alliance

Scrum.org:

"Basado en los principios de Scrum y el Manifiesto Ágil, Scrum.org ofrece capacitación integral, evaluaciones y certificaciones para mejorar la profesión de entrega de software. En todo el mundo nuestras soluciones y la comunidad de entrenadores profesionales de Scrum capacitan a las personas y organizaciones para lograr Agilidad a través de Scrum. Ken Schwaber, el cocreador de Scrum, fundó Scrum.org en 2009 como una organización global, dedicándose a mejorar la profesión de entrega de software al reducir las brechas para que los trabajos y productos de trabajo sean confiables".

La Scrum.org se anuncia como el hogar de Scrum, y al igual que la Scrum Alliance se basa en la guía oficial de Scrum que describe un macro definitivo.

El marco de Scrum por la Scrum.org

Scrum Manager:

"Scrum Manager nace en 2006 por iniciativa de profesionales en la gestión de proyectos TIC... Scrum Manager es la primera capacitación de gestores ágiles que apuesta por un modelo de formación presencial a través de centros especializados, con calidad contrastada y recursos y estructuras optimizadas, frente al costoso modelo de cursos-evento... Scrum Manager no forma "gestores técnicos": gestores conocedores de marcos de Agilidad con la implantación de las correspondientes reglas y técnicas. Scrum Manager forma "gestores expertos" que lejos de radicalizarse en el "agilismo", amplían su inventario de conocimiento y práctica de gestión con las aportaciones de la Agilidad, facilitando así la creación de su propia síntesis de conocimiento para mejorar la gestión de su entorno".

Scrum Manager recoge su conocimiento en su libro troncal del BoK (Body of Knowledge).

Scrum Manager distingue dos niveles de Scrum

Lo interesante de Scrum Manager es que mira más allá de Scrum, relativiza la importancia de las prácticas y permite flexibilizar las implementaciones adecuando el modelo de prácticas y distribución de roles/responsabilidades a las características de cada organización. Al marco de Scrum, tal como lo define la guía oficial de Scrum, lo llama Scrum técnico, y el concepto original de Scrum de Nonaka y Takeushi, expresado en el "The New New Product Development Game", que se basa en principios, lo llama Scrum avanzado.

En la imagen anterior, en la parte inferior en la parte izquierda, podemos ver una metáfora para Scrum técnico, una rueda de bicicleta que ayudada por ruedines, el marco de Scrum y sus reglas, nos permite dar nuestros primeros pasos en dirección a la Agilidad. Para la Agilidad plena, Scrum avanzado, hace falta romper con el marco de Scrum y encontrar nuestra propia forma de avanzar sin ruedines, la metáfora para Scrum avanzado. El avance evolutivo del trabajo, por el carácter flexible del modelo, funciona tanto con iteraciones como con desarrollo continuo, según las circunstancias de cada proyecto.

La flexibilidad del modelo Scrum Manager requiere mayor experiencia y madurez en Agilidad y profesional de las personas que trabajan con él (se basa más en el valor de las personas que en las prácticas empleadas).

Ahora veamos la Agilidad escalada:

Large Scale Scrum (LeSS):

"Desde 2005, hemos trabajado con clientes para aplicar el marco LeSS (Scrum a gran escala) para escalar el desarrollo de Scrum, Lean y Agile a grandes grupos de productos. Compartimos esa experiencia y conocimiento a través de LeSS para que usted también pueda tener éxito al escalar... Cuando se creó el Manifiesto Ágil muchos "sabían" que el desarrollo ágil era para grupos pequeños, sin embargo nos interesamos y obtuvimos cada vez más solicitudes para aplicar Agile y Scrum al desarrollo de productos de gran tamaño... En 2005, Bas y Craig comenzaron a trabajar juntos en Nokia Siemens Networks donde combinaron sus experiencias y crearon el marco LeSS. Desde entonces, LeSS se ha aplicado a productos tan pequeños como 2 equipos y hasta 2.500 personas en empresas de grandes productos...".

LeSS, un marco que se basa en principios

El enfoque de LeSS empieza por desescalar la complejidad de la compañía, y una vez tengamos una compañía con todo aquello que de verdad aporta valor, aplicar un modelado sistémico para obtener un marco de trabajo singular de y para la compañía. Da un leve tinte de prácticas, lo importante es hacer el modelado basado en los principios de LeSS. Escalar con LeSS requiere de mucha madurez en Agilidad.

Scaled Agile Framework® (SAFe®)

"SAFe es una base de conocimiento on-line y revelada públicamente de patrones comprobados e integrados para implementar el desarrollo de Lean-Agile. Proporciona una guía completa para el trabajo a niveles de la gestión de cartera, grandes soluciones, programa y de equipo".

SAFe, una base conocimiento integrada de patrones de desarrollo integrados y probados

El marco de SAFe es un marco lleno de prácticas empíricas muy bien integradas y experimentadas en cientos de compañías, por ello es el mejor marco para una transformación ágil en una compañía tradicional, es un punto de partida que cubre los aspectos más importantes de una transformación.

Agrupando la esencia de los marcos en una sola imagen podemos entender el titulo del post:

SAFe, Scrum Alliance, Scrum.org se centran en las prácticas, Scrum Manager y LeSS en valores y principios

Todos las diferentes entidades descritas en el post están transformando los lugares de trabajo y convirtiéndolo en algo mejor, que aporta valor a empleados, clientes, familias y sociedad en general. Cada uno de ellos suma y ayuda a las compañías, dependerá de la compañía y su madurez decidirnos por cual de ellos empezar o seguir.

Exceptuando la Scrum.org, con la que mi contacto solo ha sido indirecto, en mi corazón hay un hueco para cada una de las restantes cuatro. He "crecido" con Scrum Manager, soy trainer y voluntario comprometido con la comunidad donde he encontrado personas excepcionales, soy instructor de la Scrum Alliance y en mis co-trainings con CSTs (Certified Scrum Trainers) he conocido grandes espíritus que han inyectado Agilidad pura en mi sangre, soy SPC (SAFe Program Consultant) y siento verdadera pasión por como el marco ayuda a las compañías que inician su transformación ágil, y finalmente soy CLP (Certified LeSS Practitioner) cuyos principios e ideas disruptivas aprendidas son el faro que marca mi dirección.

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

¿PI Planning o Town-Hall?

Demos a través de presentaciones - cortesía de Pixabay

Una PI Planning es un evento de dos días al que asisten todos los miembros de un tren, sus interesados y Business Owners y todos aquellos que sean necesarios para la toma de decisiones sobre la construcción del software a planificar. Los equipos planifican el próximo PI (Product Increment, comúnmente coincidente con un trimestre) para obtener un alineamiento y compromiso en torno a un conjunto claro de objetivos prioritarios.

Un Town-Hall es un evento de 1 día que consiste de tres partes:

• Demos: cada squad muestra el valor entregado mediante presentaciones powerpoint
• Retrospectiva: en la que en búsqueda de acciones de mejora se evalúa cómo se ha trabajado a nivel de tribu
• Planning: una planificación a alto nivel para establecer los objetivos para el próximo trimestre

Resaltar que en el marco de SAFe® la PI Planning viene precedida en el día anterior por un evento Inspect&Adapt de 4 horas, en el que se hace una revisión del incremento entregado por el tren, seguida de un problem solving workshop, que es la retrospectiva escalada a nivel de programa.

En nuestros Town-Hall la Planning tiene formato de PI Planning, es la mejor y la más probada de las prácticas, y cada Town-Hall lo ensayamos concienzudamente. Mientras presenciaba el último ensayo y veía un equipo tras otro proyectando sus diapositivas, fui consciente del esfuerzo que representaba toda esa preparación, y me pregunté si el esfuerzo no estaría mal dirigido. Al fin y al cabo lo que aporta valor es la planificación, y ese esfuerzo en las demos minimizaría las energías restantes para la planificación.

Cuando estamos en plena transformación ágil estamos a caballo entre dos culturas, una situación en la que los equipos, tribus y directivos sienten la necesidad de mostrar el trabajo hecho, a veces por la inercia de una cultura de justificación, a veces por la necesidad de reconocimiento. En nuestra cultura empresarial en España quizá sea necesaria esa transición paso a paso hacía una PI Planning formal.

Lo importante es que vamos madurando y que el foco se centra cada vez más en la planificación. Estamos pensando en una próxima mejora que será una sesión de demos el día anterior y en formato marketplace. En este formato los equipos muestran directamente lo que han construido desde su "stand" a lo largo de toda el evento. Los interesados y Business Owners recorren la sala y se detienen en aquellos stands de su interés, puede que intervengan dando feedback e influyendo en la priorización de los elementos en planificación. De esta manera la planificación trimestral puede transcurrir al día siguiente a lo largo de toda una jornada en la que todos están descansados y focalizados en lo que aporta más valor, en planificar.

Townhall en su fase de demos visto desde la mesa de mezclas :-)

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