Hoy fui al Agile Open Lima, un evento donde se reunen agilistas y gente que quiere aprender sobre el agilismo. En una de las charlas, hablamos de los posibles casos cuando no es recomendable usar SCRUM. Ya que todos hablan de sus beneficios sobre cascada, me pareció interesante también saber cuando no es bueno aplicar SCRUM, aquí les dejo el resumen:
1. Pensar que con scrum haré mis proyectos mas rápidos
No! Esta es la primera distinción a hacer. Scrum, o en general las metodologías ágiles, no significa que serás mas rápido o que terminarás tus proyectos en menos tiempo. Significa que reaccionarás mas rápido a los cambios, que te adaptaras mejor y serás mas flexible ante ellos. Si piensas que con SCRUM harás mas rápido tus proyectos, NO debes usar scrum.
2. Moda
La competencia esta usando SCRUM, así que yo también quiero usarlo. La moda no es un buen motivo para empezar a adaptar agilidad, puede que ni lo necesites, o que por querer forzar su uso termines por aplicarlo mal. Antes de querer usar SCRUM, piénsalo bien, lo necesitas? No lo hagas por moda.
3. Proyectos legales / regulatorios
Scrum funciona bien cuando el alcance o el tiempo es flexible, se puede cambiar. Esto no es posible en proyectos donde hay fechas limites sin posibilidad de cambio o el alcance no se puede modificar, como en proyectos de ley / regulatorios.
4. Pensar que la agilidad es solo del proveedor.
Cuando contratamos un proveedor para que nos desarrolle un proyecto, si piensas que al ver que ellos utilizan metodologías ágiles tu no tendrás nada que ver, no deberías usar SCRUM. SCRUM implica compromiso tanto del proveedor como del cliente. Este es uno de los factores claves de agilidad, un acercamiento mas con el cliente, para entenderlo, para recibir feedback. Si piensas que es un tema solo del proveedor, no uses scrum.
5. Proyectos ya iniciados (en cascada)
Esta fue una experiencia del facilitador. Por lo general los proyectos ya iniciados tienen un presupuesto y fechas establecidas. Querer cambiarlo a agilidad implica invertir tiempo y presupuesto para que el equipo entienda la nueva metodología y se adapte a ella, cosa que puede no agradarle al cliente, por que esa es una etapa inicial. La recomendación es, quieres aplicar SCRUM? Ok, hagámoslo en el siguiente proyecto, desde cero.
6. Pensar que las personas siguen siendo recursos
Si un recurso es ineficiente lo cambias por otro. En scrum, si una persona es ineficiente buscamos entender el porque y tratar de solucionarlo. Puede que sea por falta de motivación, por agentes externos que escapan de su control, falta de capacitación, etc etc. En scrum, un equipo motivado tiene potencial para ser un equipo de alto rendimiento. Si aun piensas que son recursos, mejor no uses scrum, primero hay que cambiar este mindset.
7. Tareas de prioridad alta/cambiante
En scrum los entregables se presentan al final de cada sprint, que puede ser de 2 semanas o 3 dependiendo lo que el equipo defina. Las tareas de alta prioridad no pueden esperar esto, ellos necesitan ser desplegados tan pronto como estén listos. Las tareas de prioridad cambiante no son recomendables para los sprints, en un sprint lo que se busca es que lo que se haya definido en el planning sea lo que se entregue hasta el final del sprint. Para este tipo de tareas kanban tiene mejores resultados.
Fuente: Agile Open Lima IX en UPC