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
Excelente post!
Opino lo mismo.
Excelente post. Una pregunta, que es 'kanban'? Nunca lo había escuchado.
Upvoting por el espiritu curioso :) kanban es otro framework ágil orientado más al trabajo continuo, uno de sus principios es no cambiar todo drasticamente sino ir de a pocos, y siempre buscando la mejora continua. Talvez sea motivo de otro post, pero te dejo el link por si quieres saber más. Saludos. http://kanbantool.com/es/metodologia-kanban
Respecto del punto 7 ¿Qué pasa si en los criterios de aceptación de una historia de usuario o tarea, está que debe ser probada en todo nivel, documentada y subida a producción?
Cuando Scrum dice que al final de cada Sprint debemos entregar incrementos de valor, no quiere decir que todas las tareas de desarrollo o procesos deben esperar hasta fin de Sprint para implementarse. De hecho, el Sprint planning se trata de hacer una definición lo suficientemente robusta del Sprint Goal de modo que, siendo transparentes (Uno de los pilares del empirismo) y previendo todas estas posibilidades, podamos establecer las condiciones de cumplimiento y el plan más acercado a la realidad de acuerdo con las necesidades más inmediatas de nuestro Backlog para el próximo Sprint.
Qué bueno encontrarnos con este tipo de debates por acá.