Cómo realizar una reunión de sincronización (o daily) en un equipo que usa el método kanban

Imagen generada con Copilot de Bing

Hola a todos, 

A continuación les comparto como sugiero se realice una reunión de sincronización en un equipo que sigue el método kanban.

1. Preparación:

•  Antes de la reunión, todos los miembros del equipo deben revisar el tablero Kanban para tener una comprensión clara del estado actual de los tickets y cualquier problema o bloqueo que pueda surgir.

2. Inicio de la reunión:

• El Flow Master, Scrum Master, facilitador o un miembro designado del equipo da inicio a la reunión, asegurándose de que todos estén presentes y preparados para participar.

3. Breve introducción:

• Se da una breve introducción para recordar el propósito de la reunión, la cual es: sincronizar al equipo, identificar bloqueos, ver cuáles son elementos más próximos a cerrarse (y enfocarse en llos) y planificar el trabajo del día.

A continuación cada miembro del equipo cuenta su avance, progresos y bloqueos.

3.1 Informe del trabajo realizado desde la última reunión:

• Cada miembro del equipo comparte brevemente el trabajo que ha completado desde la última reunión. Esto incluye los tickets que han avanzado en el tablero Kanban y cualquier otro logro relevante. Comenzando siempre por los Urgentes, luego con los de fecha fija, luego con los normales y terminando con los "intangibles" o de arquitectura. Este orden se conservará en este y los tres pasos subsiguientes.

3.2 Informe del trabajo a cerrar el día de hoy:

• Los miembros del equipo comparten los tickets que serán cerrados el día de hoy. Se sugiere que el flow master ponga una marca a estos ítems, de forma que pueda identificarlos al día siguiente y ayude a que los miembros del equipo se enfoquen en los que tienen mayor prioridad por temas de urgencia y fecha.

3.3 Actualización del tablero Kanban (opcional, pues puede haberse hecho antes):

• Mientras los miembros del equipo informan sobre su trabajo, se actualiza el tablero Kanban en tiempo real. Se mueven las tarjetas de tickets a través de las columnas según su progreso actual. 

3.4. Identificación de bloqueos o problemas:

• Los miembros del equipo informan sobre cualquier bloqueo, petición de ayuda o problema que estén experimentando. Estos pueden ser obstáculos que impiden avanzar en un ticket o cualquier otro impedimento que esté afectando el progreso del equipo. Se debe dar prioridad a los elementos que estén viajando en el carril de urgentes y luego los de fecha fija.

3.5 Finaliza el estado de cada miembro del equipo, y el daily. 

• Los miembros del equipo contaron sus progresos, metas, bloqueos y peticiones de ayuda; y se cierra el reporte de estado.

Comienza la planificación del día de trabajo.

4. Identificación de los ítemes críticos a cerrar:

• El flow master de acuerdo con la información proporcionada en la sesión, la urgencia y las fechas, ayuda al equipo a identificar los elementos prioritarios a cerrar o avanzar en una dirección determnada el día en curso. Esta conversación se puede omitir en la medida que el equipo va alcanzando madurez y entiende la forma en que se da foco en el flujo de trabajo.

5. Discusión y resolución de bloqueos:

• Se discuten los bloqueos identificados, las peticiones de ayuda y se busca una solución. Los miembros del equipo pueden realizar sugerencias, ofertas de ayuda o recursos para superar los bloqueos de manera colaborativa. Estos bloqueos, el flow master los pririzará en función de las fechas y comentará su avance el día siguiente en la medida que persistan.

6. Planificación del trabajo del día:

• Basándose en el estado actual del tablero Kanban y en las discusiones sobre bloqueos, el equipo planifica el trabajo para el día. Esto puede implicar priorizar tickets, poner foco en elementos a cerrar, asignar tareas específicas a los miembros del equipo o ajustar el enfoque según las necesidades y compromisos.

7. Cierre de la reunión:

• Se finaliza la reunión agradeciendo la participación de todos y recordando cualquier acción acordada durante la reunión. 

8. Acciones de seguimiento:

• Si se han identificado acciones o soluciones durante la reunión, se asignan responsables y se establecen plazos para su seguimiento.

Al seguir estos pasos, el equipo puede mantenerse alineado, identificar y abordar rápidamente los problemas y avanzar de manera efectiva en el trabajo del día a día utilizando el método Kanban.

Si tienes mejoras o has identificado otras formas de hacerlo, te invito a que lo compartas en los comentarios.

Saludos ágiles,

Jorge Abad

Varios proyectos a la vez generará más retraso en la generación de valor. Limita el WIP.

Hola a todos

Muchas veces tenemos la sensación de que debemos satisfacer las necesidades de todas las áreas o personas que nos piden tareas, requerimientos o proyectos, esto sucede a nivel:

• individual
• de equipo
• de áreas de construcción o ejecución de proyectos y productos de software,

con la sensación de que debemos atenderlos a todos, ya sea para no generar quejas, o por evitar problemas políticos, pero esto en vez de ayudarnos generará:

• pérdida de foco
• grandes esfuerzos de gestión y pérdida de energía, pues debes estar pendiente de varias cosas a la vez
• retrasos en la entrega, que a su vez generará:
• más inconformidad en las áreas que esperan resultados
• pérdida de valor de las funcionalidades construidas y la necesidad de introducir cambios
• sobrecostos por los cambios introducidos
• pérdida de dinero debido a la no generación oportuna de valor
• poca flexibilidad para reaccionar a los cambios, debido a que debes resolver muchas cosas a la vez y habrá demoras resolviendo un problema puntual.

Por eso, si lideras un equipo, un área de ejecución o aún de forma individual, te sugiero que:

• tengas foco
• hagas una o pocas cosas a la vez
• Limita el Work In Progres (WIP) o trabajo en progreso
• Aprende a decir ¡No!

Sino, tu propias ganas de satisfacer a todos, distruirá tu propósito de generar valor, cayendo en el adagio popular 

"El que mucho abarca, poco aprieta"

Saludos ágiles

Jorge Abad

Una propuesta para Daily de un equipo Kanban

Hola a todos

Según la Guía de Scrum -https://scrumguides.org/ - respecto al daily afirma: "El Equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en discusiones.

• ¿Qué hice ayer que ayudó al Equipo de Desarrollo lograr el Objetivo del Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?"

Algunos equipos Scrum siguen haciendo las famosas tres preguntas

• ¿Qué hice ayer?
• ¿Qué voy hacer hoy?
• ¿Qué impedimentos tengo?

Aun así lo que sugiere la guía respecto a preguntarnos "¿si vamos a lograr el objetivo?" es un elemento clave para generar incrementos de valor en el marco Scrum, pero este post es sobre Kanban, y en este modelo de trabajo lo que existe es un flujo continuo (se espera sea de valor, para el negocio o para el equipo), y para este tipo de equipos también se sugiere una sincronización diaria, a continuación les comparto una sugerencia para preguntas o afirmaciones para esta reunión corta de no máximo 15 minutos:

• Afirmaciones o preguntas compartir por cada miembro del equipo:
• ¿en qué he estado trabajando?
• ¿qué necesito para cerrar lo que tengo en curso?
• tengo impedimento(s) y es/son :____________/ no tengo impedimentos
• yo me ofrezco a ayudar con__________
• yo me ofrezco ayudar a________
• un facilitador o líder del equipo podría al final del daily de cada mienbro de equipo, podría preguntar:
• ¿quien necesita ayuda?
• ¿en que estado están los impedimentos?¿como hacemos para resolverlos?
• ¿algo importante a compartir que debamos saber todos?

El facilitador o líder del equipo y el equipo mismo, deben poner foco en:

• desbloquear el flujo
• enfocarse en cerrar tareas
• terminar de abrir

Una sugerencia para equipos o dueños de una actividad o proceso

En caso de que el daily sea realizado por varios equipos o personas encargadas de una parte del proceso, se sugiere realizar el daily comenzando por la persona o equipo que finaliza el proceso y terminar con el que comienza, de esa manera nos enfocamos en terminar cosas y no en abrir.

hasta acá este compartir

Saludos ágiles

Jorge Abad.

El Planning, el Tasking, el Tablero Kanban, la Guía de Scrum y un Tip Poderoso para “Oler” Impedimentos

Hola a todos, este es uno de los post que hace tiempo tenía pendiente por escribir y por fin se alinearon los astros y pude escribirlo.

Empecemos, según la Guía Oficial de Scrum (1) el planning consta de dos partes:

• Tema Uno: ¿Qué puede hacerse en este Sprint? (conocido como “El Qué”): El cual consiste en la identificación del Objetivo del Sprint y la lista de ítems de backlog que hacen parte del producto que si se completan lograrían el Objetivo del Sprint

• Tema Dos: ¿Cómo se conseguirá completar el trabajo seleccionado? (conocido como “El Cómo”): El cual consiste  que el Equipo de Desarrollo decide cómo construirá esta funcionalidad para formar un Incremento de producto “Terminado” durante el Sprint que cumpla con el Objetivo y contenga los ítems seleccionados en el paso anterior más el plan para terminarlos.

Adicionalmente, para el tema 2 dice claramente:

“El Equipo de Desarrollo por lo general comienza diseñando el sistema y el trabajo necesario para convertir la Lista de Producto en un Incremento de producto funcional. El trabajo podría ser de tamaño o esfuerzo estimado variables. Sin embargo, durante la Planificación del Sprint se planifica suficiente trabajo como para que el Equipo de Desarrollo pueda hacer una proyección de lo que cree que puede completar en el Sprint que comienza. Para el final de esta reunión, el trabajo planificado por el Equipo de Desarrollo para los primeros días del Sprint es descompuesto en unidades de un día o menos.” (Esto último es conocido en el mundo de Scrum con el Tasking, o la descomposición en tareas de los ítems de backlog - como la palabra misma lo sugiere-)

Aquí vemos dos cosas:

• Se sugiere que el trabajo se descomponga de forma gradual en unidades, o sea, NO SE DESCOMPONGA TODO A PRIORI  en el planning del sprint (ya sea por timebox o conveniencia), sino que se identifique claramente las tareas próximas de lo próximo que se va a hacer y luego se descomponga el resto cuando estemos cercanos a construirlo (esto es conocido en el mundo de gerencia de proyectos como Planeación Gradual o Rolling Wave Planning – la cual empleamos nosotros ampliamente en el mundo ágil –). Acá quiero hacer una precisión, nunca lo he hecho así, siempre sugiero o hago la descomposición de todas las historias de usuario en tareas durante el planning  –y nos ha ido bien –, haré el experimento y lo compartiré.
• Lo segundo que me parece MUY PODEROSO es descomponer el trabajo en unidades de UN DÍA O MENOS.

Y es en esto último donde uno dice: “Claro, tiene sentido, de esa manera todos los días se finalizará algo y de esa forma se sentirá el progreso y se identificarán fácil los impedimentos y puntos de atasque".

Basado en lo anterior vienen los siguientes puntos

Cómo he trabajado el tasking o cómo lo he visto

Este ejercicio de descomponer las historias de usuario en tareas de un día o menos (léase Tasking), y me he encontrado con equipos que han decidido manejarlo de diferente manera, el punto no es discutir cuál es la mejor, es mejor pensar, con cual se siente más cómodo mi equipo, adicionalmente puede que lo hagan de una forma durante un tiempo y luego cambien a otra (recordemos el principio básico de la gestión empírica “Inspección y Adaptación”), volviendo al tema las formas de tasking que he observado son:

Forma de tasking	Observación
·         Dividir la historia de usuario en tareas de tamaños de unidades entre 1 y 8, así: 1h, 2h, 3h, 4h, 5h, 6h, 7h, 8h	La verdad esta no me gusta, lo que he encontrado es que no somos buenos estimando en esta forma, pues la precisión aun a nivel de tareas aún es baja en desarrollo de software, adicional abre el espacio a la microgestión que limita al equipo y no permite que el equipo aprenda.
·         Dividir historia de usuario en las tareas de tamaños de 2h, 4h, 6h, 8h	Esta forma me gusta, brinda amortiguación si se falla en la estimación.
·         Dividir la historia de usuario en las tareas de tamaños de 2h, 4h, 8h	Esta es la que más me gusta, por la misma razón de la anterior, adicionalmente permite que falles, aprender, mejorar, da más libertad al equipo.
·         Dividir la historia de usuario en tareas sin horas pero garantizando que cada tarea es menor a un día	Esta forma la he visto en equipos muy maduros en los cuales la confianza y transparencia son una constante presente en su día a día.

Ahora el Super Tip

Este tip me lo enseño Silvia Lozano (@sila_zenufana) – y me ha servido montones con los equipos que he tenido la suerte de estar y acompañar –, quien me sugirió en el tablero kanban poner UN PUNTO por cada día que permanece la tarea en la zona del WIP (“Work In Progress” o “Work in Process”) de esta manera se identificará que una tarea requiere ayuda si tiene más de DOS PUNTOS, pues recordemos que como tenemos por regla (o sugerencia) que las tareas no deben durar más de un día, si las tareas en el tablero kanban tienen DOS PUNTOS O MÁS significa que:

• Existe un posible impedimento
• Existe una posible dificultad en desarrollar la tarea
• Existe una posible falta de foco o de habilidad por parte de desarrollador que esta trabajando en ella
• Se estimó de una forma muy optimista o con falta de conocimiento del real tamaño
• Existe un desbordamiento de alcance
• O es un punto de mejora para discutir en la retrospectiva

En cualquiera de los anteriores es un punto donde tanto Scrum Master como Equipo observan un punto en el que hay que hacer intervención.

OJO: Lo anterior funciona muy bien si tenemos la buena práctica que siempre haya en el tablero una tarea por persona del equipo – recordemos que solo somos capaces de hacer una cosa a la vez, o sea en el WIP una persona no puede tener más de dos tareas –  o sea, que en el WIP si el equipo tiene 4 integrantes a lo sumo existirán 4 post-it (o pósit (2)) a la vez que representan una tarea por cada uno de ellos.

Cerrando

Espero que lo compartido sea de utilidad en tu equipo Scrum, y para terminar tres preguntas

• ¿Cuándo fue la última vez que leíste la guía oficial de Scrum?
• ¿Qué descubrimiento has hecho?
• ¿los puedes compartir?

Bienvenida la retroalimentación y sus comentarios.

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1.  La que se encuentra en Scrumguides.org
2.  Es correcta esta forma de escribirlo, la RAE lo permite ver acá  Pósit  http://dle.rae.es/?id=TnfXVsj