Muchos equipos que adoptan Kanban provienen de un entorno ágil. El pensamiento ágil ha desalentado el uso de las fechas de vencimiento. Las fechas de vencimiento generan un comportamiento indeseable. Centrarse en las fechas de entrega hace que los equipos trabajen bajo una gran presión. Muy a menudo, eso se traduce en atajos en las actividades de diseño/prueba. El efecto neto es que la calidad del trabajo se ve comprometida y la deuda técnica se acumula.
Dicho esto, las metodologías ágiles, específicamente Scrum, tienen inherentemente una fecha de vencimiento. La mayoría de las veces, esta es la fecha de finalización del Sprint. El equipo tiene una expectativa clara de que el alcance planificado del Sprint tiene que ser completado por la fecha de finalización del Sprint. Alguien ha pasado por el proceso de mapear la capacidad del Sprint con los puntos de historia que se planea en ese Sprint. Sí, algunos requisitos pueden extenderse al siguiente sprint, pero eso es generalmente un pequeño porcentaje del alcance general del Sprint.
Por lo tanto, la fecha de finalización del Sprint sirve como un recordatorio razonable para el equipo de que tienen que completar su trabajo para entonces. A pesar de los problemas mencionados anteriormente, las fechas de vencimiento pueden ayudar a los miembros del equipo que trabajan en diferentes historias de usuario pertenecientes al mismo MMF a alinear su fecha de finalización. Si hay que hacer algo antes de un hito intermedio (como una fecha de demostración al cliente), la fecha de vencimiento puede centrar a los miembros del equipo participantes en ese hito.
A diferencia de Scrum, los sistemas Kanban, al estar centrados en el flujo, eliminan la presión de la fecha del Sprint. La pregunta es: ¿deberían los equipos que están acostumbrados a las fechas de vencimiento, considerar su uso en las tarjetas/elementos de trabajo en su Tablero Kanban?
Aunque se espera que los equipos de proyecto sean autoorganizados y autodirigidos, la realidad puede ser muy diferente; y la ausencia de fechas de vencimiento puede causar la pérdida de impulso dentro del equipo. La ley de Parkinson se impone. 5 días de trabajo pueden alargarse fácilmente a 7 días cuando no se establece una expectativa con el desarrollador de un plazo de 5 días. En los proyectos que trabajan con presupuestos fijos, estos desvíos pueden acumularse rápidamente y provocar una escalada de la dirección.
Por lo tanto, en muchas situaciones, el uso de una fecha de vencimiento a nivel de tarjeta o de tarea resulta útil. No se trata de volver a las viejas costumbres, en las que la fecha de vencimiento se convierte en una fecha límite grabada en piedra y la calidad/deuda técnica pasa a ser una consideración secundaria. Se utiliza como una simple guía para que el miembro del equipo complete una tarjeta/tarea puede ser útil.
La siguiente pregunta es: ¿cómo se fija la fecha de vencimiento?
El enfoque típico para esto ha sido la estimación. Los sistemas ágiles/Kanban desaconsejan la estimación detallada en horas, pero se utilizan mucho las estimaciones por puntos de la historia e incluso suelen existir estimaciones por horas. En las empresas de servicios de TI, los proyectos se estiman y licitan en el ciclo de vida de preventa. Esas estimaciones son heredadas por el equipo de desarrollo, aunque a menudo no con el mismo nivel de granularidad. Las estimaciones de preventa se amplían a estimaciones más detalladas en el momento de la ejecución.
En los sistemas Kanban, se suele adoptar un simple enfoque de tamaño de camiseta para comunicar si una tarjeta concreta debe completarse en 1 semana o en 2 semanas. Así que, en general, los equipos tienen una idea de la correlación entre el tamaño (en puntos de historia o tamaño de camiseta u horas) y la cantidad de tiempo transcurrido que les llevaría hacerlo. Eso determina la fecha de entrega.
Los sistemas Kanban también tienen la ventaja añadida de centrarse en los datos del tiempo de entrega y el tiempo de ciclo, con gráficos de distribución estadística que permiten al equipo asumir compromisos a varios niveles (nivel de lanzamiento, sprint o tarjeta) con un cierto nivel de confianza. Por lo tanto, después de establecer una cierta cantidad de datos históricos, los equipos que utilizan Kanban pueden utilizar eficazmente las fechas de vencimiento para proporcionar orientación a los miembros del equipo o visibilidad a los clientes / partes interesadas.
En resumen, ¡necesitamos un equilibrio! Los equipos ágiles se oponen a las fechas de vencimiento porque tienden a impulsar un comportamiento erróneo y a subvertir la calidad. Por otro lado, la ausencia de fechas de vencimiento puede hacer que el rendimiento de algunos equipos disminuya. Mientras que las fechas de vencimiento basadas en estimaciones pueden funcionar bien, los sistemas Kanban proporcionan una ayuda adicional a los equipos para determinar fechas de vencimiento más realistas. Mi recomendación para estos equipos es utilizar las fechas de vencimiento con las tarjetas Kanban, pero SÓLO como una guía, no como algo que hará que el equipo comprometa la calidad del producto y aumente la deuda técnica.
Me gustaría conocer su experiencia con el uso de las fechas de vencimiento en los sistemas Kanban.
Otras publicaciones del blog que pueden interesarle:
