Tablero kanban para trabajo no planificable

Tiempo aproximado: 4 min.

Cuando la organización no puede permitirse el lujo de tener “en una urna de cristal” al equipo que está haciendo Scrum y debe asignarle trabajo no planificable suelo recomendar que apliquen Kanban para manejar este último.

Trabajo no planificable

Definamos antes “trabajo no planificable” como aquel que, por su naturaleza, no somos capaces de tratar dentro de nuestro proceso Scrum habitual. No necesariamente se trata de trabajo imprevisible, es decir, que no sabemos cuándo va a aparecer la necesidad de abordarlo. A veces tenemos que dar salida a actividades que conocemos con antelación,  pero nos resulta difícil abordarlo con Scrum porque no forma parte de ningún “product backlog” y hacerlo nos provocaría una burocracia que no compensa. Por ejemplo, cuando tenemos que atender modificaciones sobre un producto que se entregó hace tiempo, pero al que estamos obligados a atender en razón de un contrato de garantía sobre el mismo.

Scrum-ban

Antes de continuar, debo advertir que se dan dos usos diferentes al término Scrumban:

  1. Corey Ladas escribió este artículo en 2008 y luego un libro titulado “Scrumban” donde explicaba el uso de Kanban como una manera de ayudar a los equipos a adoptar Scrum.
  2. Angel Medinilla realizó esta presentación en 2010 sobre la idea de una técnica a la que también denominó Scrumban y con la que pretendía combinar el trabajo planificado de Scrum y el no planificable.

En este artículo emplearé siempre la segunda interpretación.

Cómo atendemos la demanda no planificable

El trabajo planificado lo seguiremos manejando con nuestro tablero Scrum como si nada. Para el trabajo no planificable ampliaremos el tablero Scrum con una extensión como la que sigue:

scrumban-extended-board-800x400

Tablero Kanban

La idea básica de un tablero Kanban es visualizar el trabajo que hacemos, no sólo para ayudarnos a nosotros mismos a enfocarnos sino también para comunicar con los demás. Así, el tablero Kanban más sencillo es el que tiene tres columnas:

  • trabajo previsto,
  • trabajo en curso, y
  • trabajo acabado.

Si para manejar el trabajo no planificado fuera imprescindible alguna otra actividad, añadiríamos la columna correspondiente. En la práctica nunca la he necesitado.

Clases de servicio, políticas y prioridades

Una clase de servicio, según el método de gestión Kanban, es una clasificación de tareas que deben ser gestionadas de una manera similar. Por ejemplo, una clase de servicio puede ser “urgente” y el SLA (acuerdo de nivel de servicio) que aplicamos a las tareas que clasificamos como “urgente” es diferente al que aplicamos a una tarea “normal”, por lo que las trataremos de manera diferente.

Un tablero Scrum es un tablero Kanban donde todas las tareas son de la misma clase de servicio y están priorizadas de más valor a menos. El equipo se compromete a resolver las tareas según la política que establece Scrum, es decir, no empezar nunca una tarea de una historia de prioridad más baja a la actual hasta que la historia no esté acabada (siempre que sea posible, claro) y siempre respetando el orden establecido por el dueño de producto (el orden en el que están dispuestas las historias de usuario en el tablero).

Para el trabajo no planificado funcionan muy bien las siguientes clases de servicio:

  • “FUEGO” o “YA”, que se atienden como si de un incendio real se tratara, es decir, el equipo o alguien del equipo deja de hacer lo que está haciendo (deja su tarea en curso como bloqueada) y atiende esta petición,
  • “PRIORITARIO” o “CUANDO ACABES LA TAREA”, que se atienden sólo cuando algún miembro del equipo acaba su tarea en curso,
  • “ASAP” o “CUANDO ACABES EL SPRINT”, que se abordan sólo cuando el tablero de Scrum está completado.

Al final de cada iteración, podemos contabilizar el número de tareas no planificadas y ayudarnos en la retrospectiva a reducir su número o a establecer políticas diferentes para mitigar el impacto sobre el trabajo planificado.

Aspectos a tener en cuenta

  • Antes de poner este tablero en uso es necesario advertir de la nueva política a los peticionarios para que sepan cómo deben actuar. Es un acuerdo de trabajo y como tal debemos explicitarlo, darle la publicidad adecuada y estar dispuestos a revisarlo.
  • Es frecuente incluir en las tarjetas del tablero Scrumban el identificador de la petición porque suelen estar asociadas a un sistema de helpdesk. También es frecuente incluir la fecha de entrada y el nombre del peticionario a efectos de seguimiento.
  • Es importante recordar que las tareas que se clasifican como FUEGO provocan una interrupción en el flujo de trabajo y que deben ser evitadas a toda costa.
  • Si las tareas que planificamos en Scrum son muy largas, podemos incumplir el SLA de las peticiones PRIORITARIAS. Si hacemos que nuestras tareas duren una mañana o una tarde como mucho, esto no debería ser un problema.
  • Si sobreplanificamos en Scrum, las tareas ASAP no tendrán salida. Esto suele ser asumible si hacemos iteraciones muy cortas, por ejemplo 1 semana.

Impedimentos

Cuando la persona que está resolviendo una tarea se encuentra con un impedimento, por ejemplo, le falta información, está esperando un pase a producción, etc… lo marcará como BLOQUEADO (normalmente con una etiqueta o un post-it de color rojo). En un tablero Kanban, las tarjetas nunca retroceden. Por tanto, dejaremos la tarjeta señalando el bloqueo en la columna EN CURSO.

Los impedimentos son la marca más importante que tenemos en nuestro trabajo de mejora continua porque en la reunión diaria el equipo TAMBIÉN revisa el tablero de trabajo no planificado para evitar que haya tareas que se queden atascadas.

Si queremos sacar mayor partido a esta técnica también podemos limitar el trabajo en curso, es decir, evitar comenzar una nueva tarea si hemos alcanzado un cierto límite de tareas en curso y bloqueadas que nos hemos dado. Esto nos sirve para impedir que sigamos aceptando trabajo no planificado y dejando tareas sin acabar. Sobre este tema escribiré más adelante un artículo específico.

Otras aplicaciones

Este tipo de gestión de prioridades también se pueden aplicar a nuestras tareas personales.

Referencias

Además de las indicadas más arriba de Corey Ladas y Angel Medinilla, también es interesante la experiencia recogida por Carlos Iglesias en esta sesión de la Conferencia Agile-Spain 2013.