En el pasado he sido muy vocal sobre por qué no uso Scrum en mis equipos. Un artículo reciente en acm queue aborda el tema desde una perspectiva que no me había considerado: Scrum lo que está intentando solucionar es un problema de comunicación y, crucialmente, de confianza:
Scrum y sus inconvenientes asociados surgieron porque las personas no confían entre sí y a menudo no se comunican bien. Lo mismo podría decirse de la mentalidad de “todos en Slack”. Los gerentes y Product Owners sienten que deben mantenerse al tanto de cómo van las cosas, ya que así pueden controlar si podrán entregar, a tiempo y dentro del presupuesto, cualquier tarea en la que se suponga que estén trabajando.
Es nuestra responsabilidad como ingenieros de software desarrollar las habilidades de comunicación adecuadas para poder establecer una relación de confianza con personas que no tienen el mismo dominio técnico que nosotros. Recuerda que saber programar ya no te garantiza un empleo (ni te hace especial).
Muchos programadores creen erróneamente que su PM lo que quiere es estarlos chingando con preguntas constantes de progreso, en vez de asumir la responsabilidad que les corresponde para poder trabajar efectivamente en equipo: ayudarle al PM a entender la complejidad real con la que se está trabajando y explicarle, en medida de lo posible, las implicaciones de las decisiones técnicas que se están tomando.
Ser profesionales, pues.
También aplica para los PMs, porque luego hay cada joyita que piensa que su equipo de ingeniería está para decir que sí y ya. Pero ese es un rant para otro día.
Si realmente somos un equipo, todos tenemos que poner de nuestra parte. De nada sirve que el desarrollador se esfuerze por comunicar efectivamente, si el PM no va a hacer el esfuerzo de encontrarlo a medio camino. Desafortunadamente, esto muchas veces tiene más que ver con la cultura de la empresa que con el PM (si miden su performance de forma cuantitativa, no hay nada que el desarrollador pueda hacer para influenciar el comportamiento del PM).
Desarrollar software no se trata únicamente de escribir código. Se trata de trabajar en equipo, y para que un equipo pueda ser eficiente y efectivo, tiene que haber confianza interna. Si personas que están trabajando codo con codo no confían la una en la otra, no importa qué tan bien escribas tu código o comuniques, las cosas van a estar difíciles.
Hace un par de años escribí Los standup meetings pueden estar destruyendo tu equipo, y no te estás dando cuenta:
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.
… siempre y cuando existan los incentivos correctos:
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.
