Kanban: Mi primer reunión de retrospectiva.

Esta semana tuve mi primera reunión retrospectiva bajo el marco de trabajo de Kanban, cabe aclarar que las reuniones en Kanban no son explícitamente necesarias para el trabajo a diferencia de Scrum. Las reuniones retrospectivas tienen el propósito de evaluar el flujo de trabajo (estas pueden ser periódicas o no), el propósito es ver que es mejorable y que se hizo bien; obvio, necesitas tener un periodo de recolección de datos, una actividad de análisis y conclusiones para poder mejorar el proceso de trabajo del área. En el caso de mi primera reunión no existieron métricas que comparar porque no hay iteraciones anteriores, aun sin esta actividad la reunión me dio una nueva perspectiva acerca de mi trabajo personal y el de mi equipo que a continuación te comparto.

A los demás les interesa el progreso de tus actividades.

El tablero de actividades es público y digital, es accesible por otras personas de la empresa, rara vez tiene comentarios de gente no relacionada por lo que yo tenía la idea de que a nadie le importaba un carajo excepto al área de desarrollo, me equivoque. En la reunión donde estaban todos los involucrados, el director del área, el product owner/analista de negocios, y la gente de soporte se hablo acerca del seguimiento que dan de las actividades, si bien no comentan, están pendientes del progreso. Los registros de estatus les fueron útiles para poder estimar cuando una actividad está próxima a ser terminada o cuando van a ser requeridos para intervenir, por ejemplo: notificar a clientes que una corrección está próxima a ser liberada o realizar algún tipo de prueba o validación.

El carril de detenidos es fundamental.

Me alegro darme cuenta de que el carril de detenidos fue tomado con entusiasmo, no se vio como un pretexto para no trabajar o como incompetencia tener varias actividades que no se mueven, al contrario. Cuando los externos vieron que actividades se detenían, consultaron la actividad para ver si podían ayudar a que progresara o solo tener en cuenta que no se está trabajando en ello. Se terminaron los correos, conversaciones o platicas de «como va» cierta actividad. El tablero se está convirtiendo en un radiador de conocimiento y un medio pasivo de comunicación del trabajo.

Está bien tener una actividad varios días en tu WIP, está mal no documentar el progreso.

En este periodo de trabajo con Kanban varios programadores mantuvieron sus actividades durante varios días, es posible que las actividades no haya sido divididas en unidades de trabajo más pequeñas, lo sé. No hubo problema ni comentarios al respecto. El comentario al respecto fue: no supimos si te atoraste en algo o necesitabas ayuda. Las tareas que no reportan estatus pueden verse como trabajo detenido. Notificar el estatus de trabajo al menos una vez al día es fundamental si trabajas con actividades grandes o complejas. Lo ideal sería dividir la actividad principal en sub actividades, pero esto es subjetivo, depende del estilo de trabajo de cada programador, personalmente prefiero dividir una tarea grande en varias pequeñas o crear actividades relacionadas. Este es mi estilo, mis compañeros no lo comparten, el punto es documenta tu avance con unas pocas líneas de texto diario, es supervalioso y no te quita tiempo.

La discusión siempre es sobre el flujo de trabajo, no sobre las personas.

Uno de mis mayores temores antes de la reunión es que esta derivara en críticas sobre personas en lugar de críticas sobre el flujo, afortunadamente no fue el caso. La discusión siempre se mantuvo en que hicimos bien y que podemos mejorar. Si bien se hicieron comentarios con nombres de personas y casos, solo fueron anecdóticos y no pasaron a mayores. La reunión giro a tratar de responder las siguientes preguntas:

  • ¿Qué se hizo bien?
  • ¿Qué se puede mejorar?

Conclusiones.

Nuestra primera retrospectiva sentó un antes y un después en nuestra manera de trabajar. No podemos verlo como una victoria aun, ya que aún faltan muchas cosas como la planificación, mantenimiento del backlog, recolección de métricas, etc. . Kanban va de mejorar cada día, ningún marco de trabajo es perfecto y siempre habrá rango de mejora.

Autor imagen: Jean-Pierre Dalbéra

 

 

 

Gustavo Sánchez

Soy especialista en escribir software de calidad. Mediante el uso de marcos de trabajo, técnicas y automatización de procesos he podido reducir los costes operativos de los sistemas de la empresa. Sistemas confiables y adaptables producen clientes felices.