El standup meeting (o daily meeting) es una práctica común en la industria del software. Los miembros de un equipo exponen avances en su trabajo, usualmente respondiendo las siguientes preguntas: ¿qué hiciste ayer? ¿Qué vas a hacer hoy? ¿En qué estás atorado?
La intención es integrar al equipo, revisar progreso, y desbloquear posibles trabas en el flujo de trabajo. Lo que realmente sucede es que entras a la llamada, pero únicamente pones atención cuando escuchas tu nombre, y durante el tiempo que te toca hablar. Fuera de eso, lo que dijeron tus compañeros te pasó de largo, y saliste de la llamada sin haber aprendido más de lo que ya sabías.
¿Te suena? A continuación quiero exponer algunos factores que tal vez no habías considerado, pero que están influenciando la forma en que tu equipo colabora. Al final, te comparto algunas preguntas para ponderar.
El standup meeting en empresas que se dedican a terminar tareas
Para una empresa que se dedica a terminar tareas, como una consultora, es tan importante cumplir con el plazo que le prometió a su cliente, que casi seguro el equipo va a tener un Project Manager asignado. Y seguro va a estar presente en el standup meeting.
El PM, como tiene que reportar progreso, es el único presente y atento durante la duración completa de la llamada, mientras todos los demás se van pasando la batuta de la atención y presencia cada vez que les toca hablar — y únicamente cuando les toca hablar.
Entras, esperas 10 minutos a que tus compañeros den su reporte de estado; cuando es tu turno, prendes tu micrófono y tu cámara, recitas lo tuyo, y vuelves a lo que hubieras preferido no dejar de hacer en primer lugar.
De acuerdo con el PMBOK, el standup meeting es “una llamada colaborativa corta, en la que el equipo revisa progreso del día previo, declara intenciones para el día en curso, y resalta los obstáculos encontrados o anticipados”. En realidad, cuando el standup meeting sucede en servicio de una sola persona, rara vez es corta o colaborativa.
El rol del Project Manager en todo esto
El standup meeting que más se practica en la industria es en servicio del PM, no del equipo.
Desafortunadamente, el PM suele ser una figura contenciosa ante el equipo de desarrollo. Muchos desarrolladores ven a su PM no como un aliado, sino como un antagonista externo al equipo que pone los intereses de todos los demás — el cliente, finanzas, ventas — antes que el del equipo de desarrollo. No es respetado, sino temido. Y en algunos casos, hasta resentido.
Ahora observa la dinámica del standup meeting a través de este lente. Si el único que realmente se beneficia de tener esa llamada es el PM, con todas las connotaciones antes mencionadas, no es de sorprenderse que tú y tu equipo vean esto como una enorme pérdida de tiempo. ¿Qué ganaste habiendo atendido esa llamada, y por qué le tienes que rendir cuentas a alguien externo?
Este sentimiento de frustración puede crecer lentamente en el resto del equipo, hasta convertirse en un problema de desgaste crónico: burnout.
Afortunadamente, la apreciación de la figura del PM es algo que se puede mejorar: si el PM busca maneras de integrarse más en el equipo, y demuestra que sí tiene sus intereses en mente; y si el resto del equipo amplía un poco sus perspectivas para entender los incentivos de la empresa que hacen que el PM se comporte de esa manera.
Requiere tiempo, dedicación, e intención. Pero se puede.
El standup meeting en empresas de producto
Empresas que se dedican a resolver problemas (usualmente empresas de producto), en algunos casos, también se comportan como consultoras: optimizando para la finalización de tareas. Siguen los mismos patrones organizacionales que las consultoras (un PM por equipo, con standup meetings y Scrum), sin darse cuenta de que los incentivos bajo los cuales están operando son fundamentalmente incompatibles con cómo están organizadas.
Desarrollar soluciones robustas es una labor altamente matizada y dependiente de contexto. Así que es probable que por varios días seguidos la contribución de alguien en el standup meeting será algo como “sigo investigando lo mismo de ayer”; las reuniones dedicadas a realmente avanzar la solución del problema involucran personas con el contexto necesario para apreciar los matices del problema.
Rara vez, todo el equipo tiene algo que aportar ahí.
¿Entonces los equipos de producto no deberían de tener standup meeting?
No quiero decir que los equipos de producto no deberían de tener llamadas para sincronizarse o colaborar. Quiero resaltar que seguir un formato y cadencia de llamada que dicta el libro de Project Management, sin considerar las implicaciones y necesidades del equipo, es una mala idea.
En los equipos de producto más exitosos en los que he tenido el privilegio de participar como desarrollador no teníamos standup meetings diarios. Teníamos llamadas semanales donde se comentaban las cosas más importantes a nivel estrategia del producto: ¿qué hito estamos cerca de cumplir? ¿Quiénes se podrían ver afectados? ¿Tenemos los planes de lanzamiento listos?
Como Engineering Manager, he traído esa práctica a mis equipos con un alto nivel de éxito. Los miembros del equipo se sienten con la autonomía y confianza de ejercer su juicio y sentido de agencia para comunicar lo que crean pertinente, sin forzar una estructura ante el equipo. Dejamos espacio para que sean las necesidades del equipo definir nuestras dinámicas.
Por otro lado, trabajar en una empresa de producto que opera como consultora, de la manera más cuadrada posible, fue una de las experiencias profesionales más frustrantes y desmoralizantes de mi carrera.
¿Cómo hacer que los standup meetings sean útiles y aporten al avance de las iniciativas?
Los standup meetings se usan sin realmente saber en servicio de quién — o qué — estamos teniendo la llamada. Y esto es un problema
Así como cualquier framework en tu lenguaje de programación favorito, al momento de elegir alguna metodología de trabajo tienes que tener claro 1) qué problema estás intentando resolver, y 2) si realmente es un problema en primer lugar.
Aquí te dejo algunas preguntas para ponderar. Si eres gerente, manager o director de la empresa:
- ¿Cuáles son los incentivos de la empresa: terminar tareas, o resolver problemas?
- ¿Está mi organización alineada de manera correcta con esos incentivos, o estoy queriendo forzar la metodología de trabajo?
- ¿Los incentivos que influencian nuestra metodología de trabajo son los correctos?
- ¿Cómo podemos balancear la relación del PM, en caso de que haya uno, con el equipo de desarrollo, y viceversa?
Si eres desarrollador:
- ¿Cómo puedo mantener al PM al tanto del progreso de mi trabajo sin necesidad de usar el standup meeting?
- ¿Cómo puedo ser más proactivo en mi comunicación para que el PM no sienta que le estoy ocultando información?
- Meta: ¿qué preguntas le puedo hacer a mi PM sobre su trabajo, para entender sus motivaciones y el contexto en el que él o ella tienen que ejecutar?
Si eres Project Manager:
- ¿Cómo puedo hacerle saber al equipo que mi trabajo es darle visibilidad y estructura al suyo?
- ¿Qué puedo hacer para integrarme más al equipo y que no se me vea como un intruso que solamente llega a pedir cuentas?