Por qu茅 el standup meeting no funciona en tu equipo

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 鈥渦na 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 鈥渟igo 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 standupmeetings 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?