|
 Primero fue con los campos de scrum; el scrum entendido y definido por Nonaka y Takeuchi, y que aunque posiblemente es era el mejor marco para implementar ciclos ágiles de desarrollo, lo hemos dejado debidamente domesticado: monopolizado, y atrofiada su evolución.
Tardamos 10 años, en descubrirlos y aplicarlos a nuestros proyectos de software; pero luego, enseguida lo hemos "doctrinalizado"(1).
Ahora parece que queremos repetir un secuestro similar con Kanban; quizá porque hace tiempo que algunos apóstatas se alejan de los dictados de "la doctrina", y la interpretan con su propio criterio y experiencia, modificando con etiquetas de estilo Kanban las prácticas establecidas.
Os comento esto, porque es la inquietante impresión que he sentido al traducir estos días el capítulo 16 de "Kanban and Scrum": "Resumen de Scrum vs. Kanban", y ver tabuladas cuáles son las diferencias entre "Scrum" y "Kanban":
Scrum: Las iteraciones deben ser de tiempo fijo.
Kanban: El tiempo fijo en las iteraciones es opcional.
Scrum: La métrica por defecto es la Velocidad
Kanban: La métrica por defecto es el tiempo de demora.
Scrum: Deben emplearse gráficos Burndown
Kanban: No se prescriben diagramas de seguimiento concretos.
Scrum: No se pueden añadir tareas en medio de una iteración.
Kanban: Siempre que haya capacidad disponible, se pueden añadir tareas
Etc. (El texto original del capítulo está en este post ) Aunque Scrum no es la metodología de la Scrum Alliance, ni Kanban la pizarra de: "pendiente, en curso, terminado...", no podemos resistir la tentación de simplificar. De enseñar "recetas" en lugar de "nutrición". Nos gusta mucho definir y acotar, decir cómo deben ser las cosas, y cómo no deben ser; incluso (o sobre todo) en cosas que ya existían hace tiempo y que para nada hemos creado nosotros.
A las pobres etiquetas y pizarras Kanban que vivían tan tranquilas alejadas de los proyectos de software, ya las hemos abordado ansiosos por diseccionarlas y dejar claro lo que son, para qué sirven y cómo se deben usar. :-(
No hay balas de plata, pero práctica que descubrimos, práctica que nos empeñamos en definir como bala de plata.
El mejor consejo que se me ocurre, antes de leer el libro es el mismo que da en sus charlas Henrik Kniberg (autor del libro): Lo de menos son las herramientas, lo importante son las personas. No dogmatizar acotando lo que es, y lo que no es Kanban. (1) La traducción de un "campo scrum" para proyectos de software hecha por la Scrum Alliance es una buena aportación, pero no es la única forma posible de construir un campo de scrum. La tendencia a monopolizar la interpretación del concepto, e incluso su nombre, está limitando la amplitud de este concepto.
 |
RSS de los comentarios
