Ir al contenido principal

No más reuniones de estatus!



Siempre he sentido cierta animadversión a las reuniones, sobre todo si duran más de 20 minutos, esto mucho antes de estar metido en el tema #Agile. Luego de pensarlo la razones eran válidas: (1) el 90% de esas reuniones eran pérdida de tiempo y (2) luego de 20 minutos perdía fácilmente la concentración.

Actualmente, aquellos clientes que prefieren la manera tradicional de gestionar proyectos, esperan por una reunión de reporte de estatus periódicamente, en general semanalmente. Esto se convierte en una reunión post-mortem de actividades del proyecto que se debieron haber cumplido en un lapso de tiempo. Entonces,  ¿dedico 1 o 2 horas a contarle a alguien que no estuvo allí, porque si hubiera estado no necesitaría que le cuente nada, sobre que se hizo o se dejó de hacer durante este período de tiempo??

La pregunta es:  ¿tiene algún valor?.. ummm en realidad si! solo para aquellas personas que no estuvieron involucradas en el proyecto durante ese período de tiempo. Pero, qué te pareces si buscamos un mecanismo tipo "pull" que le permita a esa(s) persona(s) enterarse de cómo va el proyecto con el cual no tuvo tiempo en ese periodo de tiempo de interactuar??, por ejemplo ... podria ser una Wiki!! o mejor aún, un tablero (dashboard) que este a la vista de todos y le permita visualmente conocer el avance del proyecto?? sin obligar a nadie a contarte una película que debiste haber visto??

¿qué pasa con el resto del equipo?..  ¿tuvieron una comunicación fluida durante ese periodo de tiempo?? SI --> el equipo no necesita ninguna reunión de estatus.. NO --> (veamos la causa y no el síntoma) -->  revisemos la fluidez o el flujo de la comunicación en el equipo!!

Si tienes algún sentimiento parecido o distinto.. deja tu comentario. :)

Comentarios

Es un gran dilema para mi, como hacer que el equipo comparta el status del proyecto sin que "reportar el status" sea una tarea que quite más tiempo del necesario y que sea fácil para todos. Excelente tema.
nosotros introducimos pomodoro para hacer efectivas estas reuniones, primero un set de 5' de amiguis porque nos interesa la comunidad con la que trabajamos y 2 pomodoros máximo de reunión bajo OpenSpace :o) claro está con 5' intermedios para el café :o)
Saludos cordiales
DSN_XP
Amigo Gustavo, saludos!

Desde hace ya algún tiempo que no hago reuniones de status. Estan más que resueltas con los Standup Meetings y el tener el task board a la vista, sea físico o digital.

Con esto el seguimiento y el saber si llegamos a la meta se resuelve. Si lo que se quiere es mirar atrás para entender el por qué del estatus, es la retrospectiva la que esta haciendo falta.

Llegar aquí fue gracias a la capacidad de autoorganización del equipo, no fue fácil convencer a la vieja escuela de que esto funciona. Pero cuando la realidad te choca de frente, no hay argumento que valga.
Gustavo Bonalde dijo…
Muy agradecido por sus comentarios, este tema fue de mucha discusión.
Estoy de acuerdo con "mujer-del-sigloxxi" que este tema es un dilema, ¿para qué reportar un status del cual todo deberíamos estar al tanto??
Francisco y Arístides un gusto saludarlos por acá y que compartan sus opiniones.
A mi me funciona la técnica del pomodoro , buen dato el del OpenSpace y el cafecito :)
Arístides, para mi los standup meeting (de Scrum) no son reuniones de status, pero concuerdo contigo respecto a que no es fácil convencer a la vieja escuela y que la auto-organización de los equipos es clave en todo esto.

Entradas más populares de este blog

¿Cuál programa tomo? ScrumAlliance vs. Scrum.org

Luego de participar en varias discusiones de foros acerca de las distintas certificaciones que existen de Scrum, me decidí a escribir este post para tratar de aclarar este enredo (CSM, CSPO, CSD, CSP, CSC,CST, PSD, PSF, PSM, PSPO, PMI-ACP) que a veces surge con todo esto.

Resulta que los 2 principales organismos ScrumAlliance y Scrum.org (hay otros varios como ScrumManager.net) que ofrecen los cursos de certificación en Scrum, vienen del mismo origen: Ken Schwaber. En una carta del año 2010, Ken explica por qué deja el ScrumAlliance y decide crear un nuevo instituto: "Este viajeha sido moldeado pordos fuerzas opuestas: el deseo dehacer lo correcto,y el deseo deganar dinero.ForméScrum.orgpara reenfocarmis esfuerzos enhacer lo correcto.".. Lo cierto es que no se puede negar el factor "revenue" para estas empresas, por su cursos, certificaciones y assessment que ofrecen, al igual que su objetivo de divulgar Scrum y mantenerlo por un buen tiempo.

A continuación les dejo…

Hacer las cosas correctas vs Hacerlas correctamente

"Hacer las cosas correctas" es un aspecto de satisfacción en el producto, servicio o resultado que se quiere hacer, mientras que "Hacerlas correctamente" se refiere más al método utilizado en su desarrollo o implementación.

Existen cuatro combinaciones posibles:

Hacer lo correcto y hacerlo correctamenteHacer lo correcto y hacerlo incorrectamenteHacer lo incorrecto y hacerlo correctamenteHacer lo incorrecto y hacerlo incorrectamenteSi lo llevamos a los conceptos de Management: "Estrategia y Táctica", la combinación quedaría de la siguiente manera:
Se tiene una estrategía y se cuenta con una táctica adecuada (el estado del arte)Se tiene una estrategía y no se cuenta con una táctica (según Sun Tzu “Strategy without tactics is the slowest route to victory" )No se tiene estrategía, pero se cuenta con una táctica adecuada (según Sun Tzu "Tactics without strategy is the noise before the defeat”)No se tiene estrategía, ni tampoco con táctica (al menos …

Borrador de la 6ta edición de PMBOK

Les dejo un extracto de los cambios más relevantes del borrador del PMBOK 6, cuya versión definitiva se prevé para el tercer trimestre del 2017.

La secciones de la 1-3 han sido modificadas, dejando la información importante y agregando nueva información que refleja la evolución del Gerente de Proyecto hacia agente de cambio y proveedor de valor de negocio. En la sección 1, se incorporan términos relacionados con enfoques ágiles y entornos iterativos y adaptativos.Los grupos de procesos se mantienen igual que en la versión 5.Cambian de nombre 2 área de conocimiento:
Versión 5 Versión 6 Project Time Management Project Schedule Management* Project Human Resource Management Project Resource Management.

*Me gusta, porque definitivamente el tiempo no se gestiona, podemos gestionar son las actividades.