Tablero kanban para trabajo no planificable

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.

One Pingback/Trackback

  • leomarquezd

    Hola José Manuel,

    Gracias por el artículo.

    Creo que lo que expones es fácilmente entendible por todas las partes (peticionario, equipo, product owner, negocio, stake holders…). Sin embargo, donde yo veo un punto de dificultad es en el momento de establecer a que clase de servicio pertenece cada tarea no planificada, es decir, que es fuego, que puede esperar, etc.

    Es posible que haya varios intereses en conflicto, diferentes peticionarios por ejemplo. En este tipo de situaciones, quién crees tú que debe tener la última palabra? El product owner? El peticionario que grite más? El stake holder que pague más?

    Saludos,

    Leo

    • Hola Leo. Muchas gracias.

      Lo que planteas, tal y como explico el apartado “a tener en cuenta”, es un acuerdo de trabajo del equipo con el resto de la organización. Cómo se gestiona esto es muy variable. En general he visto que funciona bien tanto si lo centraliza el PO, como si lo hace el SM o si hay un “encargado” (rotatorio o siempre el mismo). Depende mucho del contexto.

      Desde luego, dar prioridad a quien grite más o quien pague más no es la mejor política. 😉

      Un saludo,
      JMB

  • Patricio Rendon

    Genial explicado José Manuel! Hablando acerca de implementación de Kanban en las tareas diarias te recomiendo probar el tablero Kanban una herramienta online que introduzca este método. Y estoy totalmente de acuerdo que hay que tener cuidado con la implementación de scrum-kanban en nuestras empresas, pero vale la pena sacrificar un tiempo para mejorar nuestro negocio (y, pues, también la vida privada)

    • Hola Patricio. Gracias por la recomendación.

      También hay otras herramientas como LeanKit Kanban, Kanbanflow o JIRA Agile (antiguo Greenhopper). Incluso, si no recuerdo mal, hay plugins para Redmine. Y, por supuesto, puedes usar Trello con algún plugin para Chrome que ayuda a contar el número de tarjetas y tal. Sin embargo, creo que lo mejor para empezar es tener un tablero físico (de cartón pluma o en una pared) hasta que encontrar el layout que mejor se adecua al proceso de trabajo.

      Quizás esto sería adecuado para otro artículo. 🙂

    • Daria Maestas

      Hola Patricio! He escuchado sobre el Tablero Kanban Tool que mencionas. Parece que la gente lo utiliza a diario para manejar mejor las tareas de rutina pero sirve también para grupos de gente en las empresas. Este tablero virtual parece genial porque ofrece muchas opciones tipo visualización de tareas, segumiento de actividades, estadisticas. Parece que facilita la vida de la gente. Por si las moscas os dejo un enlace : http://kanbantool.com/es/

  • Susane Vega Dávila

    Muy bien explicado todo! Yo tuve la posibilidad de probar el tablero Kanban en mi trabajo y me parece una herramienta que permite sacar mucha información útil para gestionar los proyectos y sobre todo reaccionar a tiempo en caso de estancamiento en alguna de las fases del proceso.

  • Pingback: El desarrollo de software son conversaciones (II) – Se hace camino al andar…()