DEV Community

Gustavo Sánchez
Gustavo Sánchez

Posted on

Kanban: Mi primer reunión de retrospectiva.

Esta semana tuve mi primer reunión retrospectiva bajo el marco de trabajo de Kanban, cabe aclarar que las reuniones en Kanban no son explicitamente 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 primer 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 publico y digital, es accesible por otras personas de la empresa, rara vez tiene comentarios de gente no relacionada por lo que yo tenia 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 esta próxima a ser terminada o cuando van a ser requeridos para intervenir, por ejemplo: notificar a clientes que una corrección esta 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 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 esta trabajando en ello. Se terminaron los correos, conversaciones o platicas de "como va" cierta actividad. El tablero se esta convirtiendo en un radiador de conocimiento y un medio pasivo de comunicación del trabajo.

Esta bien tener una actividad varios días en tu WIP , esta 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 mas pequeñas, lo se. 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 seria 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 lineas de texto diario, es super valioso 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 criticas sobre personas en lugar de criticas 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 anecdoticos y no pasaron a mayores. La reunión giro a tratar de responder las siguientes preguntas:

  1. ¿Que se hizo bien?
  2. ¿Que se puede mejorar?

Conclusiones.

Nuestra primer retrospectiva sentó un antes y un después en nuestra manera de trabajar. No podemos verlo como una victoria aun, ya que aun 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.

Top comments (0)