Primero Scrum, luego Kanban

Hace tiempo comenté que se nos iba relajando Scrum y que quizás Kanban nos fuera mejor. El motivo era que el Scrum se nos hacía muy difícil en las condiciones actuales de nuestros proyectos: fases finales, con el código prácticamente acabado a falta de corregir bugs, integrar con hardware, probar, etc. Estimar cuánto vas a tardar en arreglar un bug es muy difícil y estimar cuántos bugs vas a encontrar en las pruebas peor, por lo que planificar sprints se nos hacía poco menos que imposible.

Sin embargo, hay muchos artículos que critican a los que dicen "Nosotros no podemos aplicar Scrum" o "En nuestros proyectos no se puede aplicar Scrum", así que la decisión de cambiar de Scrum a otra cosa me dejaba mal sabor de boca. Me daba la impresión de que era más un problema de incapacidad e inexperiencia nuestra que un problema real con Scrum.

Pero el otro día leí un artículo en Dos Ideas: Iterar primero, fluir después. La idea básica que exponen es que en las fase de desarrollo del proyecto se puede usar algo como Scrum, cuando el código está sin hacer, cuando se debe hacer un seguimiento de cómo se va, cuando se puede hacer un listado de historias de usuario, estimarlas y hacerlas. Pero en las fases finales, cuando ya casi todo está hecho y sólo queda corregir errores o hacer mejoras/cambios, Kanban puede ser mas adecuado. Hay que priorizar esos bugs/cambios e ir haciéndolos. Cada vez que se termina uno, se coge el siguiente. No se planifica nada y las cosas están cuando estén.

La verdad es que esa idea me gusta mucho. Aunque quizás mi opinión es muy subjetiva, porque justo esa idea es la que me quita el remordimiento de conciencia de no poder haber aplicado Scrum y apoya mi idea de pasarnos a Kanban dadas nuestras circunstancias. Creo que merece la pena intentarlo.

Así que a la vuelta de vacaciones (por eso escribo poco estos días), cogeré a mi grupo de tres personas con seis proyectos faltos de tiempo a cuestas y les haré la propuesta, a ver qué opinan.