Sprints cortos para riesgos muy altos
Una de las características en cualquier proyecto que trabaja con el framework Scrum es definir el tiempo que tendrán los Sprints. Recordemos que un Sprint es un periodo corto de trabajo donde se desarrollan las características que le brindarán valor al negocio y cumplirán con la satisfacción tanto de la empresa como de usuarios finales así como del equipo que lo desarrolla.
Sin embargo, hay una gran discrepancia en cuanto al tiempo que deben tener los sprints en los proyectos. Algunos autores refieren a que deben durar de 2 a 4 semanas, otros de 1 a 4 semanas, y otros tantos de 4 a 6 semanas. Esto es a elección de cada proyecto y de cada negocio, así como de la adaptabilidad que tenga el equipo de trabajo. Lo más sano y recomendable es trabajar sprints de 4 semanas. Con ese tiempo puedes conocer al equipo, ver la velocidad de trabajo que tiene, la actitud que toman ante los cambios, gestionar los riesgos de una forma más "tranquila" y tener más visibilidad del trabajo.
Pero, ¿qué pasa si el proyecto es muy corto y definen sprints muy pequeños, por ejemplo, de una semana? La respuesta es:
- Los riesgos serán demasiado altos y críticos de manejar y gestionar.
- El manejo de los cambios estresará al equipo y, por ende, el rendimiento disminuirá.
- No todas las personas se adaptan rápido a los cambios. Todos tienen una curva de adaptación acorde a su naturaleza y la velocidad de respuesta depende mucho de la misma.
- Los requerimientos deberán estar super bien definidos para poder atenderlos y que éstos estén alineados a los objetivos del negocio y además se encuentren dentro de la Visión del Proyecto. Es indiscutible que esto esté bien trabajado por parte del Product Owner para que el equipo entregue lo solicitado.
- El equipo deberá tener la capacidad y entrenamiento respectivos para poder entregar en tiempo y forma lo solicitado con tal de cumplir con los objetivos internos y externos.
Si bien las organizaciones indican el tiempo que durará el proyecto, lo que no llegan a percibir es el tiempo que están asignando para el desarrollo del mismo, afectando muchas cosas, y esto ocasiona el que se regrese a una gestión tradicionalista. Se ha comprobado que del 100% de los proyectos cuando empiezan a trabajarse de forma ágil, tienen asegurado el 98% de los riesgos y problemas más grandes, graves y fuertes que pueden darse, tales como rotación del equipo constantemente, bajo rendimiento, excesiva frustración y estrés, descontento del negocio, etc.
Por ello es importante que si se ejecutarán sprints muy cortos en tiempo (de 1 o 2 semanas), es importante considerar que el equipo de trabajo debe tener un nivel experto para cumplir con las expectativas del proyecto, del cliente y la satisfacción del mismo. Además, es necesario recalcar que los riesgos estarán visibles en un 95% durante el tiempo que viva el proyecto, afectando constantemente al equipo y, por ende, exigiendo mayor compromiso por parte de todos los involucrados.
Si bien se busca que haya una auto-organización en el equipo, no siempre suele darse, y el llevar a cabo sprints muy cortos es considerarse como parte de los riesgos.
Hasta la próxima.