Scrumban no existe, son los padres

Photo by Joao Tzanno on Unsplash

«Scrumban es una mezcla entre Scrum y Kanban». ¿Qué significa eso? Por desgracia, generalmente quiere decir que estamos haciendo mal Scrum y poco o nada de Kanban.

Scrumban: pseudo-agile a la desesperada

Lo que la gente suele entender por Scrumban, muy erróneamente, es la adopción de algunas cosas de Scrum y otras de Kanban. Pero tener un tablero con postits y hacer retrospectivas no es Scrum, ni tampoco es Kanban, ni va a ser un framework agile distinto a los dos anteriores solo por llamarlo “Scrumban”.

Es común empezar a utilizar un híbrido de Scrum y Kanban cuando sentimos que llevamos a cabo todas las ceremonias de la guía Scrum y que hemos puesto otro nombre a ciertos roles de la organización, y aún así nuestra productividad no mejora o no vemos cambios en absoluto. Lógicamente, algo más profundo en nuestros procesos y nuestra manera de trabajar no está funcionando, y la solución es mucho más compleja que empezar a hacer reuniones y llamar Product Owners a nuestros Project Managers.

De hecho, si alguien se encuentra en esta situación, no vamos a mejorar las cosas con ningún método ágil, ni tampoco va a poder ayudarnos ningún Agile Coach o Scrum Master: tiene que existir una voluntad de cambio real por parte de la organización, y llevar a cabo una transformación agile que implique a todas las capas y elementos del proceso.

¿Qué es realmente Scrumban?

Scrumban nació como metodología de transición del framework Scrum a Kanban. Lo que realmente debería ser Scrumban: hacer un uso correcto de Scrum como framework para entregar valor, y una implementación del Método Kanban para visualizar y gestionar el flujo de trabajo. Esto implicaría:

  • Tener equipos Agile, empapados y convencidos de sus valores: respeto, transparencia, veracidad, confianza y compromiso.
  • Tener una cultura kaizen de mejora continua.
  • Asumir los roles de Scrum: un Product Owner que se encarga de maximizar el valor en cada iteración; un equipo de especialistas que trabaja de manera autoorganizada; y un Scrum Master que gestiona el proceso y sirve al equipo de especialistas.
  • Utilizar los artefactos y realizar los eventos de Scrum con el objetivo de maximizar el valor entregado en cada iteración y de mejorar la manera de trabajar de manera continua.
  • Tener un flujo de trabajo que puedes visualizar, gestionar (limitar el trabajo en curso, obtener métricas) y cambiar. Si solo puedes visualizarlo pero no tienes capacidad de cambiar las cosas que no funcionan, el Método Kanban no te servirá de mucho.

Entendiendo Scrumban de esta manera, vemos que no consistiría en una mezcla de algunos aspectos de cada framework para dar a la desesperada respuesta a problemas más profundos. El uso de un Scrumban real implicaría la adopción completa de sus padres: Scrum, con todos sus valores asumidos y sus roles, artefactos y eventos implementados; y el Método Kanban, para gestión y optimización del workflow.

Sobra decir que esta combinación suele ser bastante difícil de implementar, ya que el primero de los padres solo funciona si tenemos un producto, y el segundo solo nos servirá si contamos con un flujo de trabajo sobre el que tengamos capacidad de cambio.