Más de una vez he escuchado a stakeholders, desarrolladores, mandos intermedios y otras personas de interés hablar de lo mal que les ha ido con Scrum, o de que la agilidad en sus proyectos no sirve. Hay muchas razones por la que se dan anti-patrones que provocan que estos grupos “echen pestes” de este marco de trabajo, aunque hoy me quiero centrar en uno en concreto, el anti-patrón de los roles mal entendidos.
Partamos de la base de que en Scrum el equipo está formado por tres roles diferenciados, a saber, el Product Owner, los Desarrolladores y el Scrum Master. En la guía de Scrum se recalca muy mucho que el equipo de Scrum no tiene jerarquía y que las decisiones se toman de manera consensuada entre todas las partes, no habiendo ninguna que imponga su voluntad por encima de las otras. Pero, si esto es así, ¿por qué vemos cómo los desarrolladores son comandados por el Product Owner o se quedan parados esperando a que el Scrum Master les diga lo que hacer?
En las ocasiones en las que yo he presenciado estos comportamientos, se hace evidente que, en la cultura de las empresas, todavía hay un fuerte componente de gestión en cascada combinado con que el cambio o transición hacia modelos de trabajo ágiles solo se ha hecho en el nombre y no en la esencia. Vemos a desarrolladores (ya sean testers, arquitectos, UX designers…etc.) que esperan que alguien les diga lo que hacer, porque: “aquí siempre lo hemos hecho así, y a mí no me pagan por pensar”, aunque ahora hagan entregas cada dos semanas y tengan que mantener más reuniones en las que apenas participan porque de hablar con los stakeholders y de solicitar feedback ya se encargan el Product Owner o el Scrum Master. Observamos como Project Managers de los departamentos han sido reasignados a roles de Product Owner y Scrum Master sin proporcionarles una formación adecuada, provocando que estos quieran controlar, el qué se hace y el cómo se hace, la planificación, auditando cada coma que los desarrolladores codifican, y “apretando” al equipo en los deadlines. Provocando que los desarrolladores se desmotiven, trabajen de más y creen incrementos de poca calidad y con elevada deuda técnica ya que son otros los que deciden cómo hacer el trabajo y no ellos. Generando malestar en los stakeholders y usuarios que reciben la solución porque no es como se la imaginaban, no se están cumpliendo sus expectativas o no se les está ofreciendo lo que ellos verdaderamente necesitan de la solución. Si tenemos en cuenta todas estas variables, es normal que escuchemos a todos los grupos afectados directa o indirectamente por este hecho, quejarse de que la agilidad es una patraña y que Scrum no vale nada.
Y, ¿cómo podemos solucionar esto o evitarlo desde el principio? No es una tarea fácil, cambiar la manera en la que estamos “programados” para trabajar a otra manera radicalmente diferente es una tarea ardua y difícil, pero créeme, se puede. Tanto a nivel organizacional como a nivel operativo se debe tener claro que, si hemos decidido apostar por la agilidad y por Scrum en particular, es vital definir claramente los roles que forman parte de los equipos de Scrum, pero todavía es más importante si cabe, definir correctamente sus responsabilidades.
Así, y resumiéndolo mucho, el Product Owner, se debe encargar de dar voz al usuario de la solución y velar porque así sea, decidiendo el qué ha de hacerse respecto a la solución, y centrándose en aportar el máximo valor para el cliente. Por su lado, los desarrolladores, son la pieza central de este equipo, ellos deciden el cómo van a traducir ese “qué hacer” del Product Owner en un incremento de funcionalidad en la solución que se está creando y que aporte el máximo valor al usuario final que va a utilizar dicha solución. ¿Y el Scrum Master? El Scrum Master es el responsable de que el proceso sea eficiente, de dar soporte a los desarrolladores y al Product Owner para que pongan foco en el qué y el cómo y en la entrega de valor, es el líder servicial del equipo, el que pone a disposición del mismo todo para que puedan trabajar pero que se retira silenciosamente a una esquina a esperar a que lo necesiten, sin imponer.
Y con estas responsabilidades bien definidas, la organización debe buscar las personas concretas para cada rol. Y debe apoyar a las personas que van a comenzar en este rol con la transición, dándoles herramientas para que puedan llevar a cabo estas responsabilidades y sobre todo, con formación, formación y formación. Y cuando hablo de formación, no me refiero a títulos o certificaciones, me refiero a ofrecerles libros, acceso a otras empresas que han implantado con éxito este modelo, participación en eventos de agilidad y Scrum…etc. Ya lo he mencionado muchas veces, las certificaciones quedan muy bien en LinkedIn pero eso no te hace mejor Product Owner, mejor desarrollador o mejor Scrum Master. Y, sobre todo, es importante que la empresa les deje margen para el error, si no pueden equivocarse, estas personas volverán a encasquetarse sus gorras de Project Managers o desarrolladores no pensantes, simplemente por el miedo a las reprimendas y a no llevar a cabo bien su nuevo rol…y si esto pasa, volvemos a la casilla de salida, a la de “la agilidad no vale un duro y Scrum es una estafa”
Así que si alguna vez estás en una reunión que huela un poquillo a Scrum y veas como un Scrum Master le dice a los desarrolladores qué deben incluir en el Sprint, o veas como un Product Owner se mete a decirle al resto que enfoque técnico han de seguir…puedes estar seguro que estás ante un anti-patrón de los buenos y que ese equipo necesita ayuda “como agua de mayo en la redefinición de sus roles y responsabilidades.
Manager y Scrum Master en una de las Consultoras más importantes del país. Tuvo la suerte de nacer en Sevilla y de poder desarrollar su carrera en esa ciudad. En sus ratos libres podrás encontrarla disfrutando de su pequeña, paseando por las calles de su ciudad leyendo un buen libro.
Escuela de Gobierno eGob®
