El primer tablero Kanban del equipo

Desde la experiencia con varios equipos, hoy me gustaría hablarte de la evolución de un tablero Kanban concreto. Es cierto que las decisiones de unos equipos a otros no se parecen, ni las necesidades o su trabajo. Pero he vivido una serie de momentos que se repiten en el tiempo. Algo así como El día de la marmota para un Agilista

Podríamos llamarlo «los primeros escalones» cuando un equipo empieza a usar cualquier metodología, marco de trabajo o mentalidad Agile. Y el tablero es una de las herramientas más valiosas como comentaba en mi artículo anterior.

De menos a más

Todos empiezan con algo muy sencillo, normalmente por consejo del Scrum Master o el Agile Coach que les esté acompañando. Entonces, lo primero será visualizar el flujo de trabajo del equipo en cuestión. El equipo prepara un tablero y te enseña esto:

Ahora es cuando te toca hacer preguntas. ¿Solo tenéis 3 pasos en vuestro flujo?¿Quién pone esas tarjetas ahí?¿tienen orden alguno o prioridad?… pero voy a hablar de la primera para empezar.

Visualiza tu workflow o flujo de trabajo

Al principio los miembros de un equipo tienen oxidado este tipo de análisis. Porque no suelen analizar como trabajan, sino el trabajo en sí. Así que, a ti, que estás intentando ayudarles a crear un tablero Kanban útil, te costará muchas preguntas, algunos momentos incómodos, un poco de presión y mucha paciencia.

Tras una buena charla con todos los miembros del equipo, incluyendo siempre al Product Owner o Manager que tiene visión de negocio, se han añadido nuevas columnas. Ahora en algunos de los miembros del equipo puedes ver cierto brillo en los ojos, ¡incluso alguna sonrisa!. Esto se debe a que han tratado temas que les suelen doler, porque se atascan, donde no tienen mucho poder y ahora es visible. Así que el equipo trae esto:

Evitemos el caos

Ahora sabemos que hay más pasos en el flujo de trabajo. Pasos que son importantes porque se toman decisiones que no son solo técnicas, sino de negocio.

Al final muchos equipos deciden meter una columna de «Test» para la comprobación de que todo está como debería, pero pocas veces se trata de un test técnico. Es algo que al principio me sorprendía, ahora ya se que es uno de esos «primeros pasos». Duele menos llamar así a la comprobación del Manager o el PO de que ese item es lo que ellos habían pedido.

Añadir WIP limits al tablero kanban

Como puedes observar, en el segundo tablero, hay mas columnas con el mismo número de tarjetas. Y casi todas las subtareas técnicas están en la columna «test» provocando de esta manera, un pequeño embudo que acumula tareas sin terminar. Por otro lado, todas las subtareas ya están en proceso o en test, pero algunas no se están avanzando. Toca sesión de preguntas incómodas de nuevo. ¿Esto es real? ¿se está trabajando en todas y cada una de las subtareas?

Si queremos que el tablero kanban sirva para algo y nos haga mejorar, hay que cambiar de mentalidad. Kanban nos ayuda a trabajar con una mentalidad pull y evitar el empezar mucho y acabar poco.

Hace unos días, mi compañero Nacho Navarro publicó un post interesante que te recomiendo acerca de elegir los WIP limit. Básicamente un WIP limit es un límite del trabajo activo que puede existir. Se puede limitar por columnas, por personas, el sistema completo, etc.. Por ejemplo, un equipo con 3 desarrolladores podrían decidir que no hubiera más de 3 tareas en curso en la columna «doing» a la vez. De esta forma nos asegurarnos de que creamos un sistema pull real.

Gestión del flujo de trabajo

Es importante que el mensaje de la mentalidad pull haya calado. En este tablero mejorado vimos muchos cambios:

• Priorización de los elementos y sus tareas.
• Orden para terminar más trabajo que antes.
• Problemas de estancamiento o embudos.
• Posibles necesidades de mejora para el tablero del equipo.
• Métricas. Ahora podemos medir cuánto tardamos en entregar algo.

Políticas explícitas para usar bien el tablero

Esta vez, y solo para evitar tentaciones, hay que añadir las reglas del juego. Si queremos que esto funcione de verdad, necesitamos ser legales. Nada de decir que una tarea está «casi hecha» en la columna de «Done».

Estas son una serie de requisitos que una subtarea debe cumplir si queremos pasarla a la siguiente columna. Si no los cumple, no está lista para pasar a la siguiente columna. Del mismo modo que si la columna siguiente tiene el WIP limit ocupado, tampoco puede pasar aunque las políticas se cumplan.

Esto nos ayuda a funcionar mejor con el sistema pull de Kanban. Así nos centramos en acabar el trabajo ya empezando en lugar de empezar otra tarea nueva. El equipo entendió que era necesario poner unas políticas explícitas en cada columna de paso. Así se aseguraban un mínimo en la nueva columna. El tablero quedó así:

Mejora continua de verdad

El último paso también es muy importante, ya que nos permite ir viendo estas evoluciones a lo largo del tiempo y los proyectos. Un ejemplo de ello es que en este último cambio, también añadieron algunas clases de servicios con diferentes colores en las tarjetas. Así se aseguraban que si alguna tenía fecha fija o era prioritaria, la vieran antes. Es necesario tomarse un tiempo de reflexión de todo el equipo en conjunto para tratar posibles mejoras.

Por supuesto esto es una versión reducida de un sistema que se puede complicar todo lo que necesitemos. Para ello podéis pasaros a leer la guía de Kanban que tenemos en la web, que es muy completa.

Espero que te sirva de inspiración este pequeño resumen en base a mi experiencia. En próximos post escribiré otros ejemplos, hablaremos de las tarjetas Kanban y de posibilidades dentro de un tablero kanban.