¿Introducir elementos de proyectos en una PI Planning tiene algún beneficio?

En algunas realidades de compañías que vivo seguimos intentando conciliar dos mundos con objetivos divergentes: los proyectos cerrados, que se focalizan en cumplir con el alcance, coste y tiempo, y la entrega incremental de valor con Scrum.

Llegada la PI Planning les pedimos a los equipos crear un plan a partir de una mezcla de requisitos de proyectos cerrados y elementos de una pila de producto.

La regla que definimos para ello parecía simple y de sentido común:

1. Planificar todo el trabajo proveniente de los proyectos
2. Rellenar con elementos de la pila de producto hasta que se haya agotado la capacidad

Sobrecarga en cada una de los sprints

Los beneficios esperados eran:

• Un equilibro de lo planificado con la capacidad del tren (ART)
• Identificación y resolución inicial de dependencias entre equipos
• Una visión sistémica y factible de todo el trimestre, visión que antes no teníamos
• Al conocer los requisitos de los proyectos antes podíamos efectuar una mejor preparación previa

Esperábamos que si hubiera más carga que la capacidad del tren proveniente de los proyectos, el plan se limitara a los elementos de los proyectos que fuera posible construir.

La realidad fue muy distinta. Las personas nos comportamos como nos miden; los equipos, aunque tuvieron la consigna de no sobrecargase, se sobrecargaron con el ánimo tradicional de "que hay que trabajar en todo lo que nos piden en un proyecto". En la imagen de la derecha vemos un ejemplo real, todos los sprints están sobreacargados, por ejemplo una carga de 55 puntos de historia cuando la capacidad es 46, ¡179 cuando la capacidad es 33!...

Las disfunciones que detectamos en la "PI Planning" fueron:

• Los elementos provenientes de proyectos cerrados eran muchos mas que los de la pila de producto
• La cultura de los "Propietarios de Producto" fue algo así "hay que cumplir con todo lo de los proyectos"

En conclusión no podemos dar objetivos divergentes (la de los proyectos cerrados y la de entrega de valor) a los equipos. Quizá podamos incluir algún proyecto menor en la PI Planning, quizá sea inevitable, pero la mentalidad de una compañía que quiera ser competitiva en el mercado y focalizarse en la entrega de valor, tiene que basarse en los valores y principios Lean-Agile.

Para cerrar el post quiero añadir que el segundo día de la PI Planning fue un infierno. La consigna de no sobrecargarse siguió siendo válida, aunque la de terminar los proyectos también... con lo que los equipos replanificaron para sobrecargarse de nuevo. Al cabo de tres meses tuvimos una lectura interesante y positiva: el hecho de haber realizado una PI Planning y haber "implementado SAFe®" provocó que con solo una entrega del 43% de los puntos de historias planificados, entregamos un ¡91% de valor!

¿En la planificación de sprint se limita la carga al 80% de la capacidad?

80% gracias a Pixabay

Hay algo de confusión cuando en Scrum decimos que se recomienda que los equipos no se carguen más allá del 80%, pero ¿del 80% de qué?

Si fuera de la carga (la cantidad de puntos de historia que un equipo pone en su pila de sprint) con respecto a la capacidad (la cantidad de puntos de historia que el equipo puede acometer en un sprint) algo no encaja... Al fin y al cabo la capacidad se basa en la velocidad (media de puntos de historia finalizados/entregados en los últimos sprints), que es una métrica objetiva a final de sprint que incluye todo lo que sea singular en ese equipo.

Para quién le interese podéis encontrar en mi post "Cuál es la diferencia entre velocidad, capacidad y carga en Scrum?" la definición de estos conceptos.

En otras palabras, si hemos medido en los tres últimos sprints que el equipo ha entregado digamos 31, 29 y 32 puntos de historia, podemos llenar el siguiente sprint con alrededor de 30 puntos de historia y estar razonablemente seguros de la entrega de todo lo planificado. Aquí no aplica el 80%...

Dónde si aplica este 80% es en el nivel más alto de desempeño de los equipos, desempeño que éstos alcanzan cuando la ocupación es del 80% de su tiempo.

En project management los jefes de proyecto aplican algo llamado factor de enfoque o Focus Factor; generalmente no planifican más de entre 6 y 6,5 horas diarias (de las 8) de cada persona para ejecutar un proyecto. Por tanto el factor de enfoque no es más que la capacidad de los equipos para mantenerse enfocados sin ningún impedimento en los objetivos del sprint.

Cuando trabajamos con horas se obtiene la "capacidad real" multiplicando la capacidad total, en horas, por el factor de enfoque. Por ejemplo, con un factor de enfoque de 80%, la capacidad real en horas de una persona por semana es de 40*80% = 32 horas.

Por tanto planificar una pila de sprint, teniendo en cuenta que no supere el 80% del tiempo disponible del equipo, es un excelente punto de partida. Una vez que el punto de historia se haya interiorizado y hayamos obtenido la velocidad hemos de obviar ese 80%, ya que la experiencia de sprints anteriores permite planificar con mucho más acierto.

¿Hay alguna dinámica para experimentar la creación de equipos según Team Topologies?

Team Topologies de Skelton y Pais

Para Agility Tres60 2021 Alex y yo preparamos una sesión de Team Topologies; dimos una breve introducción y luego efectuamos una dinámica que queremos compartir en este post.

Primero hablemos de Team Topologies; se trata de una guía práctica para formar equipos de software y permitir que superen sus retos, o para ayudar a equipos existentes a ser más efectivos en la entrega de valor. Describe los patrones organizacionales para la estructura de equipos y sus formas de interacción.

Recordemos las estructuras de equipos:

• Stream-Aligned Team: Es el tipo de equipo fundamental. Está alineado con parte del flujo de valor de negocio y tiene la responsabilidad de principio a fin del diseño, desarrollo, despliegue, soporte y retirada del producto o servicio, así como de los ciclos de feedback asociados.
• Platform Team: Su función es reducir la carga cognitiva de los Stream-Aligned Teams a través de, por ejemplo, ofrecer IaaS o PaaS.
• Enabling Team: Es un proveedor de servicios, por lo general de carácter temporal, y sirve para hacer más efectivos y mejorar las habilidades de los Stream-Aligned Teams, y también detectar si hay brechas en la plataforma o en lo que se espera que hagan estos equipos.
• Complicated-Subsystem Team: Equipo especializado que reduce la carga cognitiva de los Stream-Aligned Teams. Hacen cosas que requieren conocimiento, experiencia o habilidades muy específicas o sofisticadas, por ejemplo modelos matemáticos, simulaciones, etc.

Y las diferentes formas de interacción:

• Collaboration: Consiste en trabajar o colaborar muy cercanamente a otro equipo.
• X as a Service: Proveer algo como un servicio con una mínima colaboración. Los roles involucrados en este tipo de interacción son: Proveer algo y Consumir algo.
• Facilitating: Ayudar (o hacer coaching) o ser ayudado por otro equipo para eliminar impedimentos.

Team Topologies trata de gestionar la carga cognitiva limitando el tamaño de los servicios y/o productos de software que los equipos puedan manejar. Adopta "Team-First Approach" para establecer los límites del software. Cada servicio o producto debe de ser "propiedad" de un equipo con suficiente capacidad cognitiva para construirlo y operarlo. Trata de equipos pequeños multifuncionales, entre 3 y 9 miembros, cohesionados y longevos que trabajan sobre el mismo conjunto de problemas de negocio durante largo tiempo. Esto se materializa:

• Limitando los dominios de responsabilidad
• Limitando el numero de aplicaciones que operan
• Limitando el número de herramientas que necesitan manejar

Para asignar equipos a dominios:

• Asignar cada dominio a un único equipo, si de dominio es muy grande para un solo equipo, dividirlo en subdominios y asignar cada uno a un solo equipo
• Un equipo debe ser capaz de trabajar con dos o tres dominios simples
• Un equipo que es responsable de un dominio complejo no debe tener otros dominios asignados
• Evitar que un único equipo sea responsable de dos dominios complicados

Para quién quiera saber un poco más aquí os dejamos una ficha de referencia rápida que Henry Portman ha diseñado y comparte con todos:

Quick Reference Card de Henny Portman traducida por Emiliano Sutil - Thank you!!!

Para la dinámica partimos de un contexto "tradicional" con el objetivo de estructurar equipos e interacciones de forma alineada con Team Topologies. El contexto es el que sigue, también lo podéis descargar en pdf.

---

La empresa "Conoce el mundo con Gertru y Alex" es una plataforma online de viajes y aventuras que provee los siguientes servicios:

• Vacaciones en con niños en resorts familiares
• Viajes exóticos a países lejanos
• Aventuras con mascotas
• Rutas gastronómicas

Tiene un área de IT cuya misión es desarrollar y mantener los sistemas y aplicaciones que permiten la operación de la empresa, y está organizado de la siguiente manera:

• Departamento de Análisis
• Departamento de Desarrollo
• Departamento de QA
• Departamento de Operaciones

Una de sus realidades complejas que tiene que enfrentar son las interfaces con las aerolíneas y los hoteles.

Este departamento tiene entre otros, los siguientes problemas:

• Tiempos de desarrollo muy largos con muchos bugs
• Su frecuencia de despliegue es muy baja
• El nivel de satisfacción de los usuarios es muy bajo

Por esto la empresa ha decidido iniciar una transformación ágil incorporando un equipo de Agile Coaches para, entre otras cosas, reorganizar el área con base en la propuesta de Team Topologies.

---

La dinámica se efectúa sobre un tablero, en nuestro caso utilizamos Miro, en el que en la parte izquierda se muestra la organización por áreas (silos) tal como se describe en el contexto, y en la parte derecha tenemos un área en la que los asistentes trabajan la reorganización. Para los 4 tipos de equipos hay preparados rectángulos con los colores correspondientes, así como elementos de dibujo para los 3 tipos de interacciones. También hemos puesto una chuleta para tipos de equipos e interacciones.

Tablero listo para ser usado

Leyenda perfiles

Las personas las hemos representado con emoticonos, algunos de ellos para poner una nota de humor en la dinámica. :-)

En la situación inicial las personas están distribuidas y organizadas en sus áreas correspondientes, excepto los Agile Coaches que son nuevos y van a ser los responsables de implantar la reorganización.

La misión de los participantes en la dinámica es reestructurar equipos e interacciones mediante la aplicación de Team Topologies.

Algunas pistas para el facilitador:

• Cada servicio debería de tener al menos un Stream-Aligned Team
• Si el software corriera en la nube tendríamos un Platform Team de cloud
• La complejidad de los interfaces con las aerolíneas y los hoteles podría requerir un Complicated-Subsystem Team
• Los Agile Coaches que impulsan la reorganización serían un Enabling Team

Dinámica en acción en Agility Tres60, gracias a los participantes

¿Cómo gestionar bloqueos y riesgos en Kanban?

Equipo ante el tablero de riesgos

Uno de los eventos de revisión del ciclo de eventos de Kanban que se introduce en el nivel 2 del modelo de madurez Kanban (KMM) es la Blocker Clustering, o agrupación de bloqueos. Su propósito es analizar los principales motivos de los bloqueos y su impacto en términos de retrasos, para comprender y mitigar los riesgos que hay detrás de éstos.

El evento se establece con una periodicidad mensual con una duración máxima de 1 hora, y al que asisten representantes y la dirección del equipo, y opcionalmente un facilitador.

Los bloqueos que se tratan en el evento se recopilan a lo largo del periodo en tarjetas a tal efecto, incluyen al menos fecha de inicio y finalización, así como el motivo.

Estos se clasifican en un tablero por fuente/motivo de bloqueo y se analiza de cada categoría el intervalo de tiempo que ha llevado resolverlos:

• Identificar riesgos
• Identificar probabilidad e impacto
• Análisis de causas raíz
• Identificar acciones de resolución, gestión, mitigación o aceptar el riesgo (ROAM)

---

En el nivel 4 del modelo de madurez Kanban (KMM) la Blocker Clustering se sustituye por la Risk Review, o revisión de riesgos, cuyo objetivo es comprender y responder a los riesgos para una planificación de entregas de productos y servicios eficaz.

• Analizar cada riesgo
• Agrupar riesgos de acuerdo con las acciones: resolución, gestión, mitigación o aceptar el riesgo (ROAM)
• Definir acciones que posiblemente afecten a las políticas y las clases de servicio

El evento se establece con una periodicidad mensual con una duración máxima de 1 a 2 horas, y al que asisten SDMs (Service Delivery Managers) de diferentes sistemas Kanban, opcionalmente un facilitador y cualquiera de los equipos con información sobre los bloqueos recientes.

Temas a cubrir en la Risk Review:

• Revisar clases de servicio
• ¿Siguen siendo apropiados? ¿Están siendo utilizados? ¿Hemos hecho excepciones?
• ¿Hay un nuevo patrón? ¿Necesitamos una nueva clase de servicio?
• Revisar bloqueos
• Priorizar las acciones de mitigación y reducción basadas en el análisis de grupos de bloqueos
• Revisar las políticas de cobertura de riesgos
• Considerar si la demanda observada recientemente se ajusta a los patrones históricos, y si la asignación de capacidad sigue siendo apropiada
• Revisar las políticas de modelado de la demanda
• ¿Deberíamos ajustar las políticas que dividen la demanda en servicios dependientes o compartidos?

¿Qué icebreaker virtual se puede utilizar en época de COVID-19?

Los icebreakers virtuales interactivos son divertidos y una forma poderosa para que las personas conectemos, tanto si nos conocemos bien como si acabamos de conocernos. También hacen movernos, nos despegan por un momento de la silla y el ordenador y hacen que corra la sangre, despertándonos y energizándonos.

Preparando una PI Planning María la RTE propuso un icebreaker que es ideal para la época que vivimos y en la que muchos hemos estado fuera de la oficina durante más de un año. Me ha encantado la idea: Reconoce ruidos de la oficina

¿A qué ruido corresponde este sonido? - Cortesía de Pixabay

¿Sabrías distinguir entre el ruido de la máquina de café y el de la secadora de manos del baño? Ambos son ruidos familiares en tiempos de presencialidad, pero ¿y un año después?

Pantallazo del Kahoot con los ruidos de la oficina

Los ruidos habituales en las oficinas, y habitualmente los más molestos, en los que podemos basar el icebreaker son:

• Teléfonos
• Impresoras
• Conversaciones de los compañeros de trabajo
• Tecleo en los ordenadores
• El aire acondicionado

Una buena forma para ejecutarlo es mediante un Kahoot con tres láminas con sonidos, convirtiendo el icebreaker en un concurso energizante. Kahoot fomenta la competividad sana recompensando a quienes respondan antes y correctamente para obtener una mayor puntuación y situarles alto en el ranking final. Eso provoca bromas y risas.

La dinámica debe durar como máximo 10 minutos, sino los participantes pueden sentir que pierden el tiempo y perder el interés. ¡A energizar a vuestros equipos! :)

¿Es Agile Coach el trabajo más difícil que existe?

Meme sobre como a veces nos sentimos los coaches ágiles

Me reí mucho cuando vi este meme de la imagen a la izquierda, sobre todo porque es exactamente así como me siento a veces... y parece que esté en un sótano donde el trabajo del coach ágil no es visible, jajaja.

En conversaciones al respecto hablábamos que quizás el trabajo más difícil sea el de médico, ya que a veces se mueren personas, y eso es muy duro. Luego caímos en la cuenta que la cuestión del post es sobre la dificultad de desempeño y, aunque ser médico es emocionalmente duro, sus intervenciones se basan procesos muy probados y siempre están "arropados" en las decisiones difíciles por un comité médico.

La dificultad en el desempeño de un coach ágil es que lidia con la resistencia al cambio. Como expertos en Agilidad traemos cambios a las rutinas y hábitos de los profesionales, y las personas nos negamos de forma natural, por miedo o dificultad, a realizar algo nuevo o diferente. El ser humano es un animal de hábitos y le agrada tener todo bajo control, en consecuencia las situaciones nuevas pueden generar caos, incertidumbre y descontrol.

Resistencia al cambio - from Torbenrick

Las personas están más dispuestas a cambiar cuando ven que sus líderes están cambiando de forma activa, que estos actúan dando ejemplo de cambio. Hay muchas razones de resistencia por parte de los líderes al cambio organizacional:

• Miedo a lo nuevo
• Temor al fracaso
• La gran inversión económica que representa una transformación ágil
• Pérdida de dinero, trabajadores, clientes o proveedores.
• Cambios en los beneficios/bonus que ofrece la organización
• Desconocimiento o desinformación del porqué se realizan los cambios y sus aspectos positivos y/o negativos

Y ahí estamos los coaches ágiles promoviendo el cambio, nadando a contracorriente, sacando a la gente de su zona de confort en una situación en la que no hay un peligro inminente. Algunos líderes ven en el cambio una oportunidad de mejorar, aprender y superarse, y dan permiso a sus equipos a fallar para aprender. Otros se dejan llevar por sus miedos, o tienen otros intereses, así que no escuchan al coach ágil y toman decisiones o ponen restricciones no alineadas con la Agilidad.

Y esa es la razón por la que coach ágil es uno de trabajos más difíciles que existen, su foco está en aquellos que por ahora son un impedimento para la transformación ágil y no sienten la necesidad de cambiar y liderar el cambio.

Un coach ágil sabe que su propio crecimiento es resultado de facilitar el crecimiento en la entrega de valor de otros. Ser coach ágil es una gran oportunidad para servir a los demás, de hacer trascender más allá del logro de un resultado puntual de una actividad o el cumplimiento de un objetivo. Se nos ponen por delante cada día nuevos y apasionantes retos para mejorar la forma de trabajar de equipos y líderes. En mi experiencia es uno de los trabajos más difíciles que existen y a la vez uno de los trabajos más motivantes y apasionados.

¿En qué consiste el rol de SAFe® Program Consultant (SPC)?

Responsabilidades del SPC - gracias por la ilustración María Mira

El SPC (SAFe Program Consultant) es un rol fundamental en un proceso de transformación ágil basado en SAFe© (Scaled Agile Framework).

Es el rol experto agente de cambio que combina su conocimiento técnico de SAFe con una motivación intrínseca para mejorar los procesos de desarrollo de software y sistemas de una compañía. Apoya y lidera los primeros pasos, desde la decisión estratégica y el lanzamiento de los trenes (ARTs) a la implantación de un Portfolio Lean. También ayuda a evitar errores habituales en el proceso de transformación acelerando el aprendizaje organizacional y la mejora continua.

Las principales funciones de un SPC son:

• Formar a los ejecutivos, managers y líderes de la organización con la formación certificada Leading SAFe.
• Facilitar con su experiencia la creación del plan de implantación SAFe: despliegue, comunicaciones y métricas.
• Facilitar la creación y soporte de una LACE (Centro de Excelencia Lean-Agile) que genere y ejecute el proceso de transformación de la organización.
• Dar soporte a la identificación de cadenas de valor y asociación de estructura de los trenes que necesita la organización.
• Facilitar el lanzamiento de trenes con la formación de los roles necesarios como Propietarios del Producto, Product Manager, Scrum Masters y Release Train Manager (RTE), y con el apoyo necesario para preparar y facilitar la PI Planning y las pilas de de equipos y tren.
• Dar soporte a los trenes en su ejecución, mentorizando roles y equipos y revisión de resultados y el proceso de mejora.

Es fundamental que una organización que inicia su transformación ágil tenga el soporte de un equipo de SPCs con un sólido conocimiento del marco de trabajo SAFe, una gran experiencia en implantaciones SAFe y en la formación de los distintos roles que precisa SAFe para su consolidación.

Es habitual, y muy efectivo, que las organizaciones que quieran iniciar su transformación con SAFe contraten equipos de SPCs de empresas dedicadas a apoyar procesos de transformación SAFe, como los son lo es el equipo de profesionales de Estratecno, formado por SPCs que acreditan una especialización de varios años en formación certificada SAFe y en consultoría y acompañamiento de transformaciones SAFe.