Había una vez una analista senior de banca, que llamaremos Sarah, que quería ascender a jefa de proyecto. Se le presentó la oportunidad cuando, un buen día, su jefe le propuso cambiar de departamento e ir a otra ciudad, para ser Product Owner en un proyecto Scrum. Sarah no sabía nada de Scrum, pero eso de ser «jefa» le atraía, así como la posibilidad del ascenso (que iría acompañado de una subida de sueldo). De esta forma se cambió de ciudad y se presentó a su nuevo jefe y a su nuevo equipo. Lo único que Sarah sabía de Scrum era que todos los días se reunía el equipo. Empezaron a hacer reuniones diarias al más puro estilo Cascada, donde Sarah revisaba los avances del equipo, recordándoles que las fechas de entrega eran inminentes. Sarah también repartía las tareas y asignaba tiempos. El equipo, al ver que no llegaba a la fecha de entrega, empezó a hacer horas extra.
La organización tenía muchos equipos trabajando con Scrum, por lo que escalaron e implantaron SAFe. Para asegurarse de que se ponían en práctica las recomendaciones de Scrum, enviaron a un Scrum Master, al que llamaremos Robert, para que fuese el Scrum Master del recién formado equipo de Sarah.
Robert era un experimentado Scrum Master, y se asombró mucho de las reuniones diarias del equipo. El equipo estaba formado por un jefe de equipo y siete programadores, todos pertenecientes a la misma consultora. Los programadores obedecían al jefe de equipo con sumisión, pues dicho jefe sería el que evaluaría su rendimiento. El jefe de equipo cedía a las presiones de Sarah, y mantenía las asignaciones y las estimaciones que la jefa de proyecto hacía. Además, era dicho jefe de equipo el que hablaba en nombre de sus subordinados. Robert le tenía que recordar que, en la reunión de sincronización, hablaban todos. Además, al revisar el backlog, descubrió que este no existía. Así que Robert vio claramente que urgía dar un curso al equipo, incluida Sarah, sobre los fundamentos de Scrum. Se lo propuso a la Product Owner, y cuál fue su sorpresa cuando ella se negó en redondo, aduciendo que no había tiempo que perder, pues la fecha de entrega del primer hito estaba próxima, y el equipo estaba ya haciendo horas extra.
Robert empezó a sentirse frustrado, pues tenía ante sí a una Product Owner que no hacía su trabajo, que no sabía nada de Scrum, que no tenía ningún interés en aprenderlo, y que tenía al equipo exhausto, haciendo horas extra. Robert, que era un agilista convencido, sabía perfectamente que el agotamiento conducía a los errores, a la enfermedad y a la falta de creatividad (Este tema lo desarrollo en mi segundo libro «El Ciclo del Estrés Laboral».
Un enfrentamiento directo entre Scrum Master y Product Owner no beneficiaría a nadie, por lo que Robert entendió que lo primero era entregar el primer hito, que urgía bastante, y que después ya habría tiempo para dar un curso. Robert también se dio cuenta de que no se había trabajado nada en el Product Backlog. Sin un buen Product Backlog, el equipo estaba perdido, por lo que le ofreció a Sarah ayudarla en su elaboración, y arrancó de ella la promesa de que, tras el primer hito, se acabarían las horas extra. Robert se dio cuenta de que Sarah dedicaba mucho tiempo a reuniones y que era muy complicado encontrar momentos para trabajar juntos en el Product Backlog. Tras semanas de esfuerzo, Robert logró que hubiese suficientes historias de usuario para crear un Sprint. Pero estimar las tareas y preparar el sprint requería una reunión con el equipo, lo que era visto por Sarah como una pérdida de tiempo, por lo que la Product Owner empezó a boicotear dichas reuniones, amenazando al equipo con expulsarlos del proyecto, si no cumplían los plazos.
Tras un mes de frenético trabajo consiguieron entregar el primer hito. Las consecuencias fueron la entrega de un código poco probado y con fallos, el cual no contenía pruebas unitarias. Además, todos los miembros del equipo fueron cayendo enfermos con resfriados. Estos resfriados se los iban pegando unos a otros, pues iban enfermos a la oficina (una práctica irracional y poco productiva que estuvo muy de moda en algunas empresas, hasta la llegada de la pandemia por COVID-19). Además, Sarah gestionaba mal su tiempo y no ponía el foco en lo importante, por lo que estaba todo el día reunida y sin una visión clara de hacia dónde iba dirigido el proyecto. Robert era consciente de toda esta situación, pero se centró en dar formación al equipo y a Sarah, tal y como habían quedado para cuando se cumpliera la entrega del primer hito.
Robert dio el curso, y rápidamente lo entendieron algunos miembros del equipo, pero otros estaban asustados y les daba miedo asistir a tantas reuniones: sincronización diaria, retrospectivas, revisiones de Sprint, planificación de Sprint… El miedo les impedía ver el potencial de Scrum. Sarah no pudo asistir al curso, aduciendo que tenía una reunión con su jefe. Robert le propuso darle el curso en privado, a lo que ella respondió con largas. En las empresas, los equipos Scrum suelen depender de directivos, por lo que a Robert sólo le quedaba escalar el problema e ir a hablar directamente con el directivo del que dependía Sarah. Por ello, le dio un ultimátum a Sarah: o se dejaba enseñar en los fundamentos de Scrum, o tendría que escalar el caso.
El ultimatum surtió efecto y Sarah encontró un par de horas para recibir un curso de Robert. Tras el curso, Sarah comprendió que el backlog era importante y que había que mantenerlo, pero ella, en modo reactivo, dijo que no tenía tiempo para eso y que «no le daba la vida», por lo que delegó el mantenimiento del backlog en Sophie, la analista funcional del equipo. Por lo menos Sophie era más accesible y no invertía tanto tiempo en reuniones, así que pronto hubo un backlog en condiciones del que podía salir un Sprint.
Se inició el primer Sprint y Robert descubrió que Sarah, por las tardes, cuando el Scrum Master ya se había ido a casa, se dedicaba a meter presión al equipo y a introducir nuevas tareas, fruto de las reuniones que ella había mantenido durante el día.
Robert habló con Sarah, recordándole que las tareas del Sprint eran sagradas, y que no se podían estar cambiando constantemente, pues afectaba al foco del equipo y a la determinación de la velocidad de este. Quedaba claro que no se podía seguir un marco de trabajo Scrum, por lo que Robert empezó a pensar en crear un flujo de trabajo constante que permitiese mayor flexibilidad: es decir, empezó a pensar en Kanban. Si las reuniones de Sarah daban lugar a nuevas tareas muy prioritarias, éstas entrarían en el backlog y ocuparían las primeras posiciones. El equipo de Sarah producía informes muy concretos que atendían a las demandas de los directivos, por lo que el trabajo no se podía planificar a dos semanas vista.
Robert le comunicó al directivo que supervisaba a Sarah, y a ella misma, la idea de pasarse a Kanban, para eliminar la tensión que había dentro del equipo, lo que fue bien recibido.
Cuando acabaron el primer Sprint, de aquella forma tan tortuosa y agotadora, Robert, en la retrospectiva, le comunicó al equipo que había otro marco de trabajo llamado Kanban, que permitía más flexibilidad a la hora de planificar el trabajo. El equipo, que estaba exhausto y presionado por todos los lados, recibió con alegría la posibilidad de pasarse a Kanban, pues veían en esto la forma de ganar flexibilidad, dentro de un marco Agilista. Como Kanban no requería de la figura de un Scrum Master, la figura de Robert ya no haría falta, así que este sería trasladado a otro equipo Scrum de reciente formación.
Tras el paso a Kanban y la salida de Robert, Sarah siguió con su forma caótica de gestionar el proyecto. No había backlog y ella estimaba las tareas, como hacían antaño los jefes de proyecto. Se puede concluir que Kanban se utilizó de excusa para dar vía libre a Sarah, habida cuenta de su rechazo al Agilismo.
Esta historia que les he contado está basada en hechos reales, solo que he cambiado los nombres. Esta historia se da hoy en día en las empresas que adoptan el agilismo. Obligan a emplear un marco de trabajo agilista a gente que no está preparada para ello. El Agilismo requiere excelencia (en otro post ya hablé de esto: «Exigencia vs. Excelencia»). El paso al agilismo ha de nacer de la voluntad del equipo, después de haber recibido un buen curso. Sólo así obtendremos el compromiso.
Por otro lado, la figura del Product Owner es clave, pues es quien determina dónde ha de poner el foco el equipo. El Product Owner ha de ser el primer agilista, pues necesita la templanza de centrarse en el backlog y delegar en el equipo la extracción de tareas y su consecución (ejecución por «pulling», y no por «pushing»).
Si hubiese sido usted el Scrum Master, ¿qué habría hecho? ¿Y si hubiese sido usted el directivo?
Simplemente maravilloso. Un perfecto ejemplo de lo que se da hoy día en muchas de las llamadas consultoras, en las que suelen poner al mando de la gestión a gente claramente inexperta y sin ganas de querer escuchar. Por otra parte, me alegra que haya posibilidades de arreglar situaciones tan caóticas y desesperadas como la que se comenta en el ejemplo.