¿El tamaño importa?
Cada instructor Kanban tiene su propio conjunto de preguntas favoritas que parecen repetirse una y otra vez durante todas y cada una de las clases.
Aquí está mi lista personal:
- ¿Podemos mover las tarjetas hacia atrás en el tablero Kanban?
- ¿Cómo establecemos el límite WIP al principio?
- ¿Cuál debería ser el tamaño de un ticket en Kanban?
- ¿Deberíamos incluir los elementos que se encuentran en el parking dentro de los límites de nuestro WIP?
Si alguna vez te has hecho alguna de estas preguntas, ¡aquí vengo con las respuestas!
Comenzamos respondiendo la pregunta ¿Cuál debería ser el tamaño de un ticket en el Kanban?
Los tickets en un tablero Kanban deben representar elementos de trabajo que sean significativos para el cliente, es decir, que reflejen la solicitud realizada. Si pido una pizza, la tarjeta en el tablero de cara al cliente debe representar una solicitud de pizza. Si es interno del restaurante, el chef le pide a un cocinero que pique cebolla, entonces el servicio que se brinda es cebolla picada y la tarjeta debe representar esta solicitud.
Las tarjetas o tickets siempre deben representar la solicitud realizada por el proveedor de servicios.
El tamaño de un ticket es irrelevante. ¿Cuál es el «tamaño» de todos modos? ¿Es la cantidad de horas invertidas? ¿O quizás los puntos de la historia asignados por los desarrolladores?
Los tickets se incluyen en el tablero y fluyen. Aunque pueda parecer contradictorio, a Kanban realmente no le importa el tamaño de los elementos. Comprender qué tipos de elementos de trabajo tiene en su servicio es una forma más natural de agruparlos que estimar el tamaño del trabajo.
Como regla general, deseamos ver el flujo que el ticket sigue en nuestro sistema. Si un ticket no se mueve en su tablero durante unos días o más y, sin embargo, se está trabajando, entonces tal vez deberíamos considerar un tablero de dos niveles con solicitudes más pequeñas y detalladas que surgen de la petición del cliente (menos desglosada). La clave es ver el flujo y tener tickets que representen piezas de trabajo significativas que se puedan entregar al solicitante.
Entonces, ¿cómo lidiar con la estimación?
¡No estimes!
Este mantra ha sido cierto desde el primer caso de estudio sobre Kanban en Microsoft XIT en 2004. Si habéis leído el libro de David Anderson, ¿recuerdas cuánto tiempo perdieron entregando estimaciones que nunca se cumplieron en lugar de centrarse en el trabajo que generaba valor real?
Es muy fácil decir: «No estimar», pero si no estimamos, ¿qué debemos hacer en su lugar? Con Kanban, para planificar, es necesario utilizar la información histórica de tu lead time. El lead time no se correlaciona con el tamaño o la complejidad porque la eficiencia del flujo es casi con certeza muy baja. La mayor influencia en el lead time son los retrasos y la disciplina en las colas (o la falta de ellas). El tamaño de una pieza de trabajo no es una información útil, incluso aunque la estimación sea muy precisa.
Recuerdo haber trabajado en la creación de productos para el departamento de finanzas. El primer tipo de elemento de trabajo en el que trabajamos fueron «nuevos trabajos». Cuando comenzamos a entregar los incrementos de nuestro producto, comenzamos a recibir comentarios que dieron como resultado un nuevo tipo de elemento de trabajo: solicitudes de cambio. Además, no evitamos los defectos y tuvimos que resolverlos de inmediato, ya que afectaban al producto de cara al cliente. Nos dimos cuenta de todos esos matices analizando los datos del lead time y escuchando los comentarios de los clientes. Observar la distribución del lead time multimodal, el análisis de los datos del lead time y escuchar lo que nos decían nuestros clientes nos mostró que no teníamos un tipo de elemento de trabajo, sino tres. Creamos tres distribuciones de lead time a partir de la original y establecimos SLA basados en ellos. El «tamaño» de estos elementos fue una consecuencia natural de comprender los tipos de elementos de trabajo y agrupar los que eran de naturaleza similar y, por lo tanto, de tamaño.
El siguiente ejemplo de la clase de mejora de sistemas Kanban explica cómo puede identificar y leer datos multimodales.
Normalmente cosas de tamaño dramáticamente diferente serán diferentes tipos de elementos de trabajo. Alguna guía podría ser que, si nunca ve que el ticket se mueve, tal vez sea demasiado grande. O tal vez necesite un tablero a nivel de portfolio o una jerarquía de 2 niveles, para que pueda ver cómo se mueven las cosas.
Puede ocurrir que identifiquemos algún tipo de trabajo consistente, y que este sea enorme. Usemos otro ejemplo. Si construimos cruceros, un ticket para un crucero es lo que incluimos como petición en el tablero. Si estamos en el negocio de la construcción de cruceros, entonces la cantidad de tiempo y energía que nos lleva construir un crucero es algo que conocemos y entendemos. Teniendo un crucero, y el próximo crucero y el próximo crucero, podemos comenzar a construir un histograma de lead time, ya que todos son el mismo tipo de trabajo. Entonces, un día, Richard Branson se pasa por nuestra empresa y dice: “Sabes, estoy pensando en comprar el crucero para mi nueva línea de cruceros Virgin Voyages, y he pensado en hacerte el pedido. Si lo pido esta semana, ¿cuándo estará listo? «
Si sabemos lo que estamos haciendo, porque somos una empresa de construcción de cruceros de nivel de madurez 3 o nivel de madurez 4, podemos darle una respuesta. Quizás podamos decir: “Lo tendremos en julio de 2024, Richard. ¿Qué te parece eso?» Y sabemos que esta es la promesa que podemos cumplir.
Es un cambio significativo entre el Nivel de madurez 1 y el Nivel de madurez 2, que es el momento en el que comienza a ver diferentes tipos de elementos de trabajo.
¿Qué deberías hacer?
Debemos desarrollar habilidades de análisis, prestar atención a nuestro entorno y al lenguaje que usan las personas; puede ayudarnos a identificar los tipos de elementos de trabajo en su proceso.
¡Hay más!
Imagine que tiene una organización con una eficiencia de flujo del 2%. Significa que solo el 2% del lead time es el tiempo de trabajo real, donde las cosas están en la columna de actividad y se están trabajando. El 98% del tiempo es retraso o espera. Por lo tanto, el tamaño del ticket y el trabajo real es una cantidad trivial en comparación con su lead time. Por lo tanto, lo que intenta estimar no es el tamaño del trabajo real, sino el tamaño del tiempo de espera o el desperdicio.
Para el mismo tipo de elemento de trabajo, la eficiencia del flujo producirá más variabilidad que el tamaño en sí.
Entonces, ¿cuál debería ser el «tamaño» de mi ticket?
Centrémonos en algunos consejos prácticos para esta pregunta:
- No se moleste en estimar el tamaño. Deje que un ticket entre en el sistema, analícelo como una opción en su flujo ascendente, use los datos lead time para decidir cuándo comenzar a trabajar en el flujo descendente.
- Comprenda sus tipos de elementos de trabajo. Escuche lo que dice la gente, el lenguaje que usa, cuando habla de sus procesos y del trabajo por hacer.
- El elemento de trabajo debe ser lo suficientemente «pequeño» para permitirle ver el progreso (o la falta de progreso: bloqueador, dependencia de espera). Si su artículo permanece durante unos días / semanas en un estado y pierde la pista de las dependencias, porque está todo el tiempo «en progreso», entonces debería buscar algo más detallado.
- Su elemento de trabajo debe ser lo suficientemente «grande» para no generar gastos generales. Si dedica más tiempo a crear y mover un elemento a través del sistema que a trabajar en él, significa que necesita algo de nivel superior.
- Utilice el diseño del ticket para ayudarle a tomar una decisión segura. De modo que cuando lo mire, sepa «lo que está pasando» y no necesite deliberar sobre ello. Por supuesto, esta perspectiva, como todo lo demás, requiere algo de tiempo para pruebas y sondeos, y es posible que deba experimentar con diferentes enfoques. Sea paciente. Mejorar colaborativamente, evolucionar experimentalmente.
Referencias
Kanban Evergreen: The size of the ticket | David J. Anderson School of Management (djaa.com)
Equipo de Transformación. 24 de junio de 2021.
