Hace poco estuve trabajando en la revisión de una implementación de SCRUM en una empresa acostumbrada a trabajar con metodología predictiva.
En uno de los proyectos, quizás el más grande, un desarrollador con muchos años de experiencia, había asumido el papel de Scrum Master.
Debido a que él era el contacto principal en el sitio del cliente, sin saberlo, durante el proyecto se había convertido en el receptor de todo lo que normalmente recae sobre un PM, y más.
Si bien había estado en el rol de líder técnico antes y tuvo que lidiar con los problemas que normalmente acompañan a los desarrolladores, en ese momento también se estaba ocupando de problemas más administrativos como conseguir reemplazos de personal, asistencia técnica, facturación, gestión general del cliente, e informes periódicos predefinidos, entre otras tantas cosas.
Una suma de tareas que le generaban estrés y preocupaciones y lo alejaban de su tarea de Scrum Master, como facilitador, y veedor de la buena salud de la metodología.
Cuanto más tiempo pasaba, más lo veía evolucionar, sin quererlo, hacia la mentalidad de un PM y al final de ese proyecto, le guste a él o no, su cerebro había sido reconfigurado para pensar como un PM y no como un Scrum Master.
Solicitudes de la empresa para fijar fechas de largo plazo, disconformidad con la premisa de equipos sin jefe, presión para tener todo el proyecto planificado al detalle, presión para cambiar las prioridades en el trabajo de los equipos sin consultarlos, presión para asignar él mismo las tareas según su buen saber y entender, y otras tantas presiones propias de un PM, gestionando un proyecto bajo metodología predictiva.
La resultante fue un cúmulo de malas experiencias: la idea de que las metodologías ágiles no funcionaban, la generación de expectativas no cumplidas en los miembros de los equipos, la vulneración permanente de las reglas de la agilidad, el cansancio producido a este buen muchacho por estar entre lo que sabía que tenía que hacer como Scrum Master y lo que le pedían que haga, la desazón por los incumplimientos, el quite de esfuerzos por parte de la gente del equipo que no entendía los cambios de mensaje, una crisis constante por tratar de bloquear cambios de requerimientos y planes, y algunos otros desaciertos.
Nuevamente me había encontrado con más de lo mismo en esto de tratar de llevar la agilidad a las organizaciones: la falta de entendimiento sobre el corazón de estas metodologías, y la ingenua idea de que todo el resto puede seguir funcionando burocráticamente como siempre, sin afectar nada.
Por supuesto, no niego la necesidad de metodologías predictivas en proyectos que lo ameriten (de hecho, estoy certificado en ellas y soy instructor de Project Managers), pero está demostrado que la agilidad funciona mucho mejor para obtener buenos resultados cuando hay cambios constantes de requisitos, escenarios o variables que afectan al proyecto, y esto es una constante hoy en día.
Plantear usar metodologías ágiles como una forma de estar a la moda o hacer lo que hacen otras organizaciones, sin tener el convencimiento profundo de hacer lo debido que implica esto, es un error muy grande, y lamentablemente muy común.
La agilidad plantea un cambio de paradigmas en la cultura de las organizaciones y no puede tomarse a la ligera.
Así que sería bueno que no sigamos vistiendo Project Managers de Scrum Masters, porque no estamos en una fiesta de disfraces, sino, ante un cambio de filosofía en la vida de las organizaciones, e implementar la agilidad puede redundar en múltiples beneficios, pero solo si nos tomamos el tema muy en serio.
#PM, #proyecto, #metodología, #agilidad, #ScrumMaster, #burocracia, #gestióndelcambio, #planificación
Nuestros servicios relacionados:
Comments