¿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.

¿Cuál es la diferencia entre OKRs y KPIs?

Uno de los puntos que genera muchas dudas es al respecto de estos dos términos; de lo que muchos no son conscientes es que ambos forman un ciclo de feedback cerrado entre estrategia y ejecución. Veamos como se definen los dos conceptos:

• OKR (Objectives and Key Results o Objetivos y Resultados Clave): representan objetivos que se marcan desde la estrategia para lograr crecimiento y mejora, y cuyo éxito se mide a través de los Key Results. Éstos representan una advertencia temprana, son una brújula, para saber si vamos en la dirección adecuada. Recordar que alcanzar un 60% de los Key Results ya representa éxito.
• KPI (Key Performance Indicator o Indicador Clave de Rendimiento): se aplican en la ejecución y representan una medida del nivel del rendimiento y progreso de la construcción del producto. Ejemplos son margen bruto, participación de mercado, métricas de calidad, satisfacción del cliente, previsibilidad, NPS, tiempo de ciclo, calidad... en Agilidad los KPIs incluyen entre otras satisfacción de los empleados y desempeño de los equipos ágiles (velocidad).

Ambos forman un ciclo cerrado, los KPIs son las medidas cuantificables que nos permiten evaluar si estamos listos para ir en dirección de los OKRs, y cómo se está desempeñando en comparación con los resultados comerciales pronosticados. Los KPIs dan feedback de realidades a los OKRs, e influyen en la revisión y ajustes de éstos. En el fondo estamos hablando de un ciclo que alinea estrategia con ejecución de forma continuada.

Los OKRs y los KPIs forman un ciclo de feedback cerrado
Imágenes PixaBay: OKR, Equipo Scrum, ART y Incremento, KPI de freepik yTribu de Henrik Kniberg & Anders Ivarsson y KPI

¿Cómo hacer que historias de usuario afectadas por más de un equipo funcionen?

Equipos coordinándose en una historia de usuario
Cortesía de Pixabay

Si miramos la técnica de calidad INVEST que aplicamos a las historias de usuario, sobre todo los criterios Independent y Small, veremos que éstas están pensadas para ser construidas por un solo equipo dentro de uno de sus sprints.

Una historia de usuario excelente cumple con los 6 criterios, y una buena historia de usuario puede que solo cumpla con la mayoría de ellos. A veces buenas historias de usuario no son independientes y requieren de más de un equipo.

Y es justamente en este punto donde, a través de este post quiero, arrojar algo de claridad sobre como tratar estas historias que Jann Thomas denomina cross-team-stories o historias que cruzan equipos.

Una historia que cruza equipos consta en realidad de dos partes: la parte de la historia de usuario que permanece con el equipo que la identificó, y la historia de usuario que va al equipo que la completa. La propiedad/responsabilidad de ambas historias recae en el equipo que la ha identificado. La propuesta del flujo de la historia entre equipos sería la siguiente:

1. Durante una planificación del sprint, o una PI Planning, un equipo identifica una historia de usuario con una parte que debe realizar un equipo diferente.
2. El equipo que la identifica la divide en dos, una historia de usuario para cada equipo.
3. Representantes apoyados por, o directamente los Propietarios del Producto de los respectivos equipos, negocian la prioridad y el alcance de la historia que ha de construir el otro equipo.
4. El equipo que construye la parte planifica la historia en su sprint. El equipo que la ha identificado planifica su historia en el sprint adecuado teniendo en cuenta la planificación del otro equipo, sea el siguiente sprint o uno posterior.
5. Una vez finalizada la historia por parte del segundo equipo, el equipo que la ha identificado la integra y valida junto a la suya.

Lo que realmente estamos haciendo es una gestión de resolución de dependencias, que mientras no finalice deberemos de visitar en las reuniones de Scrum de Scrums.

¿Se puede escalar Agilidad añadiendo capas?

Versión de SAFe 6.0 como broma de 1 de abril

El 1 de abril me llegó por whatsapp una pretendida versión 6.0 del marco de SAFe©... En Estados Unidos, los países nórdicos de Europa y otros países más, el 1 de abril es el "April Fools' Day", que se puede traducir como día de las bromas de abril o día de los inocentes de abril.

Lo interesante de la imagen es lo que evoca, que el escalado se puede producir añadiendo nuevas capas, a semejanza de la forma tradicional de hacer crecer a las compañías.

En realidad la propuesta de SAFe es simplificar y desescalar a lo que funciona con personas, y por tanto alinearse con la naturaleza humana.

Como en Scrum, el bloque básico es el equipo, que sabemos que llega a niveles máximos de autoorganización y autogestión estando limitado de 5 a 11 miembros, incluidos Scrum Master y Propietario del Producto.

El siguiente nivel de escalado, el equipo de equipos, lo denomina tren o ART (Agile Release Train), y está limitado a ±125 individuos. Según el antropólogo Robin Dunbar la cantidad de individuos que se pueden relacionar plenamente en un sistema determinado y proporcionar un sentimiento tribal con un objetivo común es aproximadamente de 150. Este número está relacionado con el tamaño de la neocorteza cerebral y su capacidad de proceso, y es el que permite y limita la autoorganización y la mente colectiva al tren o ART.

Por encima de ese número los colectivos no son autoorganizados, son creaciones artificiales del ser humano y requieren reglas y coordinación. Ejemplos son la religión, la nacionalidad y por supuesto los trenes de trenes o Solution Trains de SAFe, que pueden ser necesarios cuando varios trenes trabajan en un mismo producto. Toda capa por encima del tren es un colectivo artificial.

Si pertenezco a un tren, donde tengo noción de quienes están a bordo y soy consciente de un objetivo común, estaré dispuesto y comprometido a colaborar, a ayudar y a pedir ayuda. En un colectivo artificial si alguien me pide ayuda, colaboraré o ayudaré en función de mi buena voluntad, quizá entienda que puede haber un objetivo sea común, pero no tendré ese sentimiento tribal de pertenencia. Por ejemplo si alguien me pide ayuda en Londres, no por ser de mi nacionalidad voy a ayudarlo.

En resumen, SAFe desescala agrupando a los individuos en trenes o ARTs, el bloque básico de escalado. La siguiente capa es una capa artificial que es deseable evitar. La idea es organizar trenes independientes alrededor de cadenas de valor, y solo en casos excepcionales formar un tren de trenes o Solution Train. Al organizar trenes alrededor de cadenas de valor no es necesario escalar más allá, ya que si cada tren es independiente diseñará, construirá, testeará y desplegará cosas de principio a fin por si solo.