information radiators

Kanban, una herramienta para el equipo


Una de las herramientas que se combinan habitualmente con Scrum es el tablero Kanban. Mucha gente sabe de lo que hablo, pero no tanta gente conoce lo que verdaderamente hay detrás de Kanban. Kanban es un conjunto de principios aplicables a cualquier proceso productivo que permiten una serie de controles sobre el proceso, no solo un tablero de Post-It.
Kanban se basa en los siguientes 6 principios fundamentales:

  1. Visualiza el flujo de trabajo: A pesar de que el flujo de estados que determinan nuestro trabajo lo tenemos más o menos en la cabeza, hacerlo explícito o escribirlo permite un beneficio inmediato. Todos los integrantes del equipo compartirán una visión común y no habrá pasos que solo algunos hacen.
  2. Limita el WIP: Es un concepto fundamental en Kanban. El WIP es el trabajo en curso en un determinado instante. Cuantas tareas o historias de usuario hay en este momento empezadas y que todavía no se han dado por cerradas, o en un restaurante, cuantos pedidos hay en cocina que aún no han sido servidos. Lo que haremos es establecer límites claros y casi infranqueables en cada estado con el fin de garantizar que hay un flujo continuo de trabajo en el equipo. Por ejemplo si limitamos el WIP en la fase de testing, nos estamos asegurando que el equipo de desarrollo no inunda esta fase con desarrollos sin probar y continua desarrollando nuevos elementos. Es una manera de repartir responsabilidades y de fomentar la colaboración para superar un cuello de botella, ya que si se llega a este límite de capacidad el equipo debe concentrarse en eliminarlo (aunque no sea su responsabilidad directa) o no podrá continuar con su trabajo.
  3. Gestionar y medir el flujo: Nuestro propósito es a la vez que sea un flujo constante de trabajo y mejorar el flujo. En ambos casos necesitaremos un sistema para medir el rendimiento del equipo y el ritmo del flujo. Medidas comunes son el Lead Time o tiempo medio de un elemento en recorrer el flujo, y el WIP o número de elementos medio en progreso. Ambas medidas nos las da el gráfico de flujo acumulado.
  4. Implementa ciclos de feedback: Consiste en definir un sistema de feedback en periodos de tiempo definidos, es decir, no se trata de un proceso estático sino que cada cierto tiempo el equipo se reúne con el objetivo de cuestionar el proceso y de proponer mejoras para la siguiente iteración.
  5. Explicita políticas y procedimientos: Más allá del flujo de trabajo el equipo de trabajo tendrá una serie de reglas no escritas sobre su trabajo y lo que le rodea. En un equipo de desarrollo podemos encontrar ejemplos como cuándo y dónde tienen lugar las reuniones diarias o retrospectivas, cuál es su definición de hecho o definición de preparado, sus políticas internas de comportamiento o código de conducta, etc. Hacerlas explícitas y públicas tiene el beneficio inmediato de que estás seguro que todo el mundo entiende lo mismo por un concepto y evita conflictos.
  6. Evolución continua de forma colaborativa, que consiste en que una vez el equipo tiene una visión clara de cómo funciona el proceso y cuáles son sus límites, el mismo equipo es el indicado para proponer soluciones a posibles problemas o proponer pequeñas mejoras en el proceso. La forma en que se implementan estas mejoras simplemente será introducirlas en el proceso en la siguiente iteración, medir, y con los resultados en la mano decidir si la modificación ha obtenido el resultado esperado y se mantiene o bien si se elimina al no haber aportado ningún beneficio.

Vistos los 6 principios fundamentales, Kanban no pretende imponer una manera única de trabajar, es más, anima a comenzar al inicio tal y como se están haciendo las cosas antes de Kanban y poco a poco introducir las mejoras que se consensuen entre todos para ir introduciendo límites WIP, explicitando políticas, en definitiva ir evolucionando a un mejor desempeño.
Si intentamos poner en práctica imponiendo todos los principios Kanban en un equipo nos toparemos con un rechazo al cambio brusco que seguramente llevará a peores resultados. Ésta debe ser una herramienta para el equipo, que le sirva a los integrantes del equipo a gestionar su trabajo colaborativamente y sin perder el foco de los objetivos comunes, y nunca debería ser una herramienta de gestión o seguimiento para el jefe de proyectos.
Finalmente decir que la forma en que se implementa Kanban en un equipo de desarrollo pasa principalmente por utilizar la herramienta del tablero Kanban, ya que es el instrumento masivamente utilizado y conocido (además de sencillo de entender) y que ha demostrado que da resultados.

Kanban

También te puede interesar...

Crea ya tu lista de impedimentos en Scrum El rol del Scrum Master incluye eliminar impedimentos, pero ¿qué son los impedimentos en Scrum concretamente?¿Qué debe hacer el Scrum Master?¿cuáles d...
Resumen Scrum by Jeff Sutherland Tenía muchas ganas de leer este libro. Ya no solo porque era leer sobre el framework Scrum que utilizo a diario en mi trabajo, sino porque me lo había...
Los 7 desperdicios LEAN del software (y II) Este post es la continuación al post anterior Los 7 desperdicios del desarrollo de software donde describía los primeros 3 desperdicios del desarrollo...

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

11 ideas sobre “Kanban, una herramienta para el equipo

    • samuelcasanova Autor

      Hola Cristhian,
      Es correcto, la fase de ToDo no se puede acabar hasta que la historia está lista para QA. Lo que significa que la historia debe estar subida o bien a una máquina de pruebas o bien en el entorno de integración para que la persona de QA pueda pasar el juego de pruebas.
      La historia no vuelve atrás, sinó que es el desarrollador el que se mueve a QA en el caso de que hayan errores.
      Espero haberte respondido, gracias por comentar.

  • Luis

    Gracias por este artículo.
    Yo en mi anterior empresa, el equipo usabamos la herramienta Trello, donde documentabamos todo lo que se iba haciendo pero se nos quedó bastante corto debido a la gran cantidad de contenido que metíamos diariamente.

    • samuelcasanova Autor

      Me parece curioso que te hayas “acabado” Trello por el volumen de contenidos que manejáis diariamente. ¿de cuántos elementos diarios estamos hablando? También siento curiosidad por saber por cuál herramienta lo sustituiste.
      Gracias por el comentario Luís.

  • Karina Toala

    Buenos días,

    Quisiera conocer bien, si a diferencia de Scrum, en Kanban existen roles para los miembros del equipo o no?, de las lecturas que he realizado he podido entender que no?, pero cómo es el trabajo entonces?, Cómo se hace para pasar de una fase a otra? Se valida con una reunión de trabajo y actas de reunión, o qué documentos existen?

    • samuelcasanova Autor

      Hola Karina.
      Estás en lo cierto, Kanban no prescribe roles como Scrum. De la misma forma tampoco prescribe reuniones (daily, planning, demo…) ni artefactos (backlog, burndown chart…). Por este motivo es común combinar Kanban con otras herramientas de otras metodologías para suplir esa “falta de directriz”. Si necesitas un daily con Kanban, hazlo. Si necesitas sesiones de planning, adelante. Si necesitáis tener las características de un producto priorizadas en algún sitio, cread un backlog. Lo que sea que os funcione. Kanban prescribe una reglas fundamentales que funcionan en los flujos de trabajo, pero el cómo lo debes definir tú, no te da nada hecho. No sé si me he explicado o todavía lo he liado más :-)

      • Karina Toala

        Gracias Samuel por su pronta respuesta, sin embargo aún algunos puntos no me quedan claros,(soy nueva en el tema), Kanban no puede ser usado por sí solo y va a requerir el apoyo de otras metodologías o herramientas que permitan el desarrollo de la misma, y lo que me da son más bien lineamientos generales a seguir?, es decir, ¿Cómo defino que puedo seguir a otra etapa?,¿Cómo se realiza la distribución de tareas?

        • samuelcasanova Autor

          No es que no pueda ser usado por sí solo, pero al ser tan poco prescriptivo notarás enseguida que necesitarás soporte de artefactos, reuniones, documentos, etc. que o bien copias de otras metodologías o bien los creas tú. ¿Que cómo defines cómo seguir a otra etapa? Pues debe ser un consenso con todo el equipo. Lo que te dice Kanban es que decidas lo que decidas, lo hagas explícito. Un ejemplo típico es definir los criterios por los cuales una tarea pasa de una columna del tablero Kanban a otra y dejarlos escritos en la columna, a la vista de todos. Finalmente la distribución de tareas no suele existir en Kanban, ya que al ser un método pull es el mismo equipo el que se autoorganiza. Cuando alguien termina una tarea va al tablero y coge (pull) la siguiente tarea priorizada que puede coger.