¿Quieres empezar a trabajar en Scrum pero te da miedo caer en los típicos errores que se suelen cometer? El propósito de ser ágiles no es suficiente para lograr serlo de forma efectiva. De hecho, en más de la mitad de los casos no se aplican los principios de forma correcta. A continuación, te contamos algunos de los errores al implementar Scrum más comunes.
¿Cuáles son los principales errores al implementar Scrum en una organización?
Cambiar frecuentemente los miembros del equipo
El equipo de trabajo ideal debe ser pequeño, de alrededor de cinco miembros. El hecho de eliminar personas del equipo o añadir nuevos miembros con demasiada frecuencia hará que disminuyan sus posibilidades de éxito. Sin embargo, los equipos estables aprenden de sus propias capacidades, lo que les ayuda a ser más previsivos y aumentar la productividad.
Tener demasiado trabajo en proceso
Cuando existen demasiados frentes abiertos es difícil completar adecuadamente los sprints. Hay que designar a equipos a completar específicamente elementos de alto valor, para así completar más trabajo en menos tiempo, gracias a la fuerza del trabajo en equipo. Una buena definición del Sprint Goal es clave para no perder el foco.
Realizar una inadecuada asignación de tiempo para interrupciones
Es común que surjan imprevistos o cuestiones inesperadas y de última hora que aparecen y esperan respuesta, es inevitable. Esta problemática podría atajarse si en la planificación se reservase la cantidad adecuada de tiempo dentro de cada sprint para hacer frente a cuestiones que no están registradas con anterioridad.
Dejar que los errores al implementar Scrum persistan
Los errores deben ser abordados lo antes posible, tan pronto como se presenten. Cuando este tipo de problemas no se tratan rápidamente, siempre requieren más tiempo para su resolución en el futuro.
Permitir la existencia de impedimentos para continuar
Es necesario identificar el mayor obstáculo recurrente en cada sprint, para resolverlo durante el siguiente. De esta forma, la velocidad aumentará porque los equipos serán capaces de hacer más cosas que en los sprints anteriores. La mejor forma de enfocar esto es considerar los impedimentos como mejoras en los procesos, que deben resolverse tan rápido como sea posible.
Disponer de un Scrum Master a tiempo parcial es uno de los errores al implementar Scrum
Si el Scrum Master está asignado a varios proyectos, es difícil que pueda mantener el foco necesario en ninguno de ellos. Tendría que ser un Scrum Master y equipos muy experimentados, así como proyectos muy pequeños para que pudiera funcionar, de lo contrario, colisionarán sus reuniones y tendrá que priorizar unos equipos y proyectos sobre otros, lo que acarreará ineficiencias que se trasladarán al proceso ágil.
Usar al Scrum Master también como Project Manager
Si el Scrum Master actúa como un responsable de proyecto traslada la imagen al equipo de que poco ha cambiado y de que sigue existiendo una figura representativa de la dirección de la empresa con la que tienen que interactuar y a la que deben pedir aprobación. Un Scrum Master debe ser un especialista en la implementación ágil, no un representante de la organización infiltrado en el equipo Scrum. Este planteamiento puede boicotear el agile, consiguiendo en la forma, pero sin ningún cambio real.
El equipo de desarrollo no está acostumbrado a ser responsable
Los desarrolladores suelen enfrentarse a la sistematización en su trabajo diario y a los clásicos planes de proyecto, por eso, al comenzar con Scrum, tendrán dificultades para asumir la responsabilidad que cae sobre el Development Teams, en cuanto a la auto-organización y la auto-gestión, que son frecuentemente olvidadas. Precisarán tiempo y espacio que vuelvan a tomar las riendas del producto y de su trabajo.
El Product Owner no tiene tiempo para el equipo Scrum
En ocasiones los Product Managers hacen la transición a Product Owners pero no entienden el cambio que eso supone. El Product Owner en Scrum es responsable de optimizar el valor del producto, y eso requiere mantener contacto y trabajar constantemente con el resto del equipo. Sin embargo, muchos de ellos están ausentes y sólo aparecen para el Sprint Review.
Cualquiera de los escenarios planteados anteriormente son situaciones que solemos encontrarnos cuando acompañamos equipos en su cambio a marcos de trabajo ágiles. Si te interesan los contenidos como este, puedes consultar nuestro blog, una consultora situada en A Coruña, experta en aportar valor a las empresas mediante transformaciones agile, innovación e intraemprendimiento,
