• Saltar a la navegación principal
  • Saltar al contenido principal
Icono Jeronimo Palacios

Jeronimo Palacios & Associates

Transformación digital

  • Agile Academy
    • Scrum Mastery
  • Próximos cursos
  • Scrum.org
    • Applying Professional Scrum
    • Applying Professional Scrum for Software Development
    • Professional Scrum Master
    • Professional Scrum Master II
    • Professional Scrum Product Owner
    • Professional Scrum Product Owner Advanced
    • Scaled Professional Scrum
    • Professional Agile Leadership
    • Professional Scrum with Kanban
  • Kanban University
    • Team Kanban Practitioner
    • Kanban System Design
    • Kanban Systems Improvement
  • Servicios
    • Formación
      • Management 3.0
      • SAFe 5.0
      • Lean Change Management
      • DevOps Institute
    • Agile Coaching
      • Discover and deliver Agility
      • Solicitud de propuesta de servicios profesionales
    • Software
      • Diagnóstico de Arquitectura de Software
    • Recursos
  • Blog
  • Guías
    • Método Kanban
    • Nexus
    • Definitiva Scrum
    • Oficial Scrum
  • Acerca de
    • Videos sobre Scrum y Kanban
  • Contacto
  • Show Search
Hide Search

Método Kanban

Kanban y la transformación digital

Hoy me gustaría compartir con vosotros un error que cometí hace tiempo y que a día de hoy sigue siendo uno de lo que más me encuentro a la hora usar el método Kanban como palanca de transformación en las organizaciones.

Hace pocos días mi compañero Jero nos contó qué es la transformación digital en un post altamente recomendable. Otra de las consecuencias de todo lo que explica Jero en ese post es que en las grandes organizaciones todo empezó a gestionarse con Silos Técnicos. Es muy tentador pensar que así está todo muy bien ordenadito. Front por un lado, backend por otro, middleware y los gestores de infraestructuras por otro. De hecho, puedo externalizar todo cómodamente y controlar la productividad de mis proveedores con puntos función, número de historias de usuario, o cualquier otra métrica de actividad (y no de valor). 

Como ninguno de estos silos es capaz de producir valor al usuario final por sí mismo debemos crear una entidad que aglutine el trabajo de todas estas islas tecnológicas y lo entregue al usuario final. Y así surge la figura del Proyecto. Cuando alguien tiene una idea de negocio solicita a todos los silos el impacto que tienen en el proyecto y una estimación de en qué release podrán tener lista su parte. Tras un mes de reuniones se les comunica si realmente ese proyecto ha sido aprobado en el comité y en qué release esperan liberarlo.

Kanban como solución

Esta forma de trabajar genera miles de dependencias y bloqueos, además de un “Time to market” que, por experiencia personal, supera ampliamente el año. Esta claro que hay que hacer algo. Las organizaciones se suman al carro de la transformación digital y comienzan a apostar por métodos Ágiles.

Uno de los métodos Ágiles más conocidos es Kanban y a las oficinas de Transformación les suele encajar cuando hablamos de un silo tecnológico que da servicio al resto de la compañía.

Pero pensemos por un momento el ciclo de los proyectos. Separaremos en dos alturas cuando hay alguien trabajando en el proyecto y cuando está esperando a que alguien realice otro trabajo:

ciclo vida visión sistémica Kanban

 

Este es el escenario en el mejor de los casos. Generalmente las releases tienen una fecha a la que algunos silos llegarán con el trabajo terminado y otros no. Lo que nos va dejando proyectos incompletos dentro de nuestro sistema durante meses y meses. Esto hace competir a las grandes en la carrera de la innovación entregando al usuario ideas que tuvieron hace más de 12 meses.

 

Obteniendo beneficio limitado de Kanban

Cuando se empieza a trabajar con Kanban en muchas organizaciones se piensa que el problema está en los equipos. Que no sacan el trabajo suficiente  y se pone el foco en mejorar esos pequeños picos de actividad que vemos en la imagen anterior en vez de en los periodos de espera. Trabajar en tratar de mejorar esa eficiencia de recurso en vez de la eficiencia de flujo de todo el proceso nos hace desperdiciar mucho dinero y tiempo obteniendo pocos beneficios.

Si comenzamos a trabajar con Kanban solamente a nivel de silos seguramente habremos ganado en visualización de nuestro trabajo, gestionaremos mejor los riesgos y hasta podremos aumentar nuestra tasa de entrega. Pero lamentablemente esto apenas impactará en el time to market global, en que el número de bloqueos baje o en que generemos más valor. En definitiva, nuestro impacto en aumentar beneficios en la empresa será prácticamente nulo.

 

¿Cómo podemos lidiar con esto?

Un buen Agile Coach debe buscar la visión sistémica y ayudar a la organización a entregar más y más valor al usuario. Agile es un medio para maximizar revenue, gestionar riesgos y aprovechar oportunidad de mercado. Pero Agile no es un fin en sí mismo. Hay que tener cuidado de caer en la trampa de tener una lista de checks de si los equipos tienen tableros o no, si hacen dailies o no, si hacen retrospectivas o no, y quedarnos ahí. Cuidado con la vanidad de las métricas de actividad. (Aquí te dejo el enlace a nuestro Kanban Metric Layout por si te interesa)

Soluciones hay muchas y depende del contexto. Te puede ayudar:

  • Que la organización sepa hablar de “flujo” a todos los niveles. Y entiendan cómo funciona.
  • Tener métricas orientadas a flujo: Lead time, throughput, tiempo medio de bloqueo, etc.. en los equipos, y a nivel programa o portfolio.
  • Poner el foco en eficiencia de flujo en vez de en eficiencia de recurso.

Entendiendo el concepto de flujo, visión sistémica y usando correctamente el método Kanban se puede obtener un alto impacto en un tiempo reducido. Si quieres saber más:

  • Aquí puedes ver nuestra guía Kanban.
  • Aquí más posts sobre Kanban.

 

Entendiendo la guía de Kanban para equipos Scrum: ¿Por qué este fregao?

[fusion_builder_container hundred_percent=”no” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” overlay_color=”” video_preview_image=”” border_size=”” border_color=”” border_style=”solid” padding_top=”” padding_bottom=”” padding_left=”” padding_right=””][fusion_builder_row][fusion_builder_column type=”1_1″ type=”1_1″ layout=”1_1″ background_position=”left top” background_color=”” border_size=”” border_color=”” border_style=”solid” border_position=”all” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” center_content=”no” last=”true” min_height=”” hover_type=”none” link=”” first=”true”][fusion_text columns=”” column_min_width=”” column_spacing=”” rule_style=”default” rule_size=”” rule_color=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=””]

Hace unas semanas actualizamos en Scrum.org la guía de Kanban para equipos Scrum a una nueva versión.

El objetivo de esta revisión ha sido incorporar el feedback recogido por las miles de personas que están utilizando Kanban con sus equipos Scrum y clarificar algunos de los principios. Como casi todo, la primera versión de algo no es perfecta y en Scrum.org somos muy críticos con nuestro propio trabajo.

La guía de Kanban para equipos Scrum ha ayudado a entender como trabajar conjuntamente con los dos métodos, evitando algunas de las falacias más comunes. En el blog encontrarás varios artículos que te dejo al final del texto.

Los cambios incluyen:

  • Una reestructuración de la sección de teoría para conectar mejor entre flow, empirismo, introducir las métricas y la Ley de Little.
  • Limpieza de la sección de definición de workflow para que los ejemplos estuvieran en un sitio separado.
  • Políticas más generales para reducir el nivel de prescripción y permitir que el foco esté en los principios y no en las prácticas.
  • El alcance de visualización y accountability sobre la definición de Workflow se han modificado.
  • Una nueva sección sobre como el incremento en Scrum se ve afectado por el Flow.
  • Los Service Level Expectations (SLE) ahora son parte de la sección de workflow.

¿Por qué Scrum.org se mete en el mundo de Kanban?

Cuando se publicó la guía de Kanban para equipos Scrum y el curso Professional Scrum with Kanban (PSK) hubo revuelo en ámbas comunidades. Por un lado, miembros de la comunidad de Kanban, dividida entre los que trabajan pro Kanban University y los que tomaron la decisión de escindirse de la organización, pusieron el grito en el cielo.

La pugna entre Scrum y Kanban ha beneficiado ampliamente a ámbas comunidades, por un lado porque el debate genera nuevo conocimiento y por otro -el malo- debido a que los acalorados enfrentamientos normalmente provocan beneficio económico para aquellos que viven de prescribir métodos.

Hubo fervientes creyentes de Scrum pensaron que esto era una perversión que haría caer Scrum en pro de otras cosas y veían amenazada sus creencias más profundas.

Y luego, existía una gran mayoría, más silenciosa y centrada en los resultados que siempre ha creído en la construcción de puentes entre comunidades cuya misión es la misma, mejorar los entornos de trabajo a través de la mejora de resultados.

La elaboración y difusión de la guía fue una iniciativa personal de Steve Porter, quien creía que la comunidad de Scrum tenía mucho que aprender de Kanban.

Un año y medio después, tras formar a cientos de alumnos en decenas de clases, no puedo más que darle la razón. La publicación de la guía y el trabajo que Scrum.org y los trainers hemos hecho en torno a la difusión de la misma ha resultado en mejores resultados en los equipos que aplican Kanban como parte de su trabajo con Scrum.

A lo largo de este año hemos compartido muchos artículos sobre Kanban, Scrum y las métricas que se pueden utilizar al combinar ámbos.

  • Simula un flujo de Kanban con esta herramienta
  • Scrum y Kanban, lo peor de los dos
  • 4 maneras de beneficiarte de Scrum y Kanban juntos

En especial, estos dos artículos escritos por mi compañero Nacho Navarro describen muy bien la potencia que se puede alcanzar a través del uso de las métricas utilizando Scrum y Kanban conjuntamente.

  • Kanban Metric Layout (I)
  • Kanban Metric Layout (II)

El futuro de Scrum y Kanban

Como todo futuro, siempre es incierto. La incoporación de Kanban al mundo de Scrum.org ha traido beneficios tangibles y apenas desventajas. Aunque hay quien piensa que los conceptos que se enseñan en la guía de Kanban para equipos Scrum ya formaban parte implicimante de Scrum. Otros pensamos que desarrollar principios que amplifiquen y publicarlos ayuda a generar más debate.

¿Y tu? ¿Que opinas? Déjanos un comentario para abrir el debate.

Si quieres saber más scrum como utilizar Kanban con tus equipos Scrum, aquí tienes nuestra próxima clase de Professional Scrum with Kanban.

[/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container][fusion_builder_container hundred_percent=”no” hundred_percent_height=”no” hundred_percent_height_scroll=”no” hundred_percent_height_center_content=”yes” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” status=”published” publish_date=”” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” enable_mobile=”no” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” video_preview_image=”” border_size=”” border_color=”” border_style=”solid” margin_top=”” margin_bottom=”” padding_top=”” padding_right=”” padding_bottom=”” padding_left=””][fusion_builder_row][fusion_builder_column type=”1_1″ type=”1_1″ layout=”1_1″ spacing=”” center_content=”no” link=”” target=”_self” min_height=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_image_id=”” background_position=”left top” background_repeat=”no-repeat” hover_type=”none” border_size=”0″ border_color=”” border_style=”solid” border_position=”all” box_shadow=”no” box_shadow_blur=”0″ box_shadow_spread=”0″ box_shadow_color=”” box_shadow_style=”” animation_type=”” animation_direction=”left” animation_speed=”0.3″ animation_offset=”” first=”true” last=”true”][fusion_events cat_slug=”professional-scrum-with-kanban” past_events=”no” number_posts=”1″ columns=”1″ column_spacing=”43″ picture_size=”auto” content_length=”excerpt” excerpt_length=”” strip_html=”” pagination=”no” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” padding_right=”” padding_left=”” /][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Kanban Metric Layout (II)

En el primer post de la serie Kanban Metric Layout hablamos sobre los indicadores más importantes. En este post vamos a ver las gráficas dónde podremos ver e interpretar esos indicadores.

Gráficas

Cumulative Flow Diagram (CFD)

 

 

El CFD es una gráfica muy completa que nos permite leer multitud de indicadores y analizar tendencias.

 

 

Lead time: Si trazas una línea horizontal desde la línea que representa el punto de compromiso hasta la línea que representa que el elemento está entregado tendremos el Lead Time Medio medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).

Cycle Times: Podrás obtener el cycle time medio aproximado si trazas una línea horizontal desde dónde empezamos el trabajo (In progress en el ejemplo) hasta que hemos terminado (ready to approval en el ejemplo).

Throughput: La pendiente de la línea de completados es el throughput medio en ese intervalo de tiempo.

 

 

 

WIP: Trazando una línea vertical desde el estado completado hasta el primer estado de trabajo de nuestro flujo obtendremos el WIP en ese momento.

Para equipos que aún no han limitado el WIP esta parte puede ser muy útil para establecer una conversación sobre el tema (extra: ¿Cómo elegir un buen WIP limit?). La relación entre WIP, Lead TIme y Throughput está queda bastante clara en el CFD:

Para que el Lead Time no se dispare debemos terminar el mísmo número de elementos que empiezo. De manera que las líneas en el CFD del trabajo comenzado y terminado deberían ser paralelas:

 

 

Si tenemos dos líneas divergentes significa que estamos empezando más trabajo del que estamos acabando, por lo que nuestro lead time aumentará y nuestra predictibilidad bajará. Esto es justo lo que intenta evitar Kanban limitando el trabajo en curso.

 

 

Cycle time Scattlerplot

Es la principal gráfica para visualizar y analizar los Cycle Times. Los equipos pueden fácilmente comprender las tendencias.

 

Una de las herramientas más poderosas de este gráfico son los percentiles. Son las líneas horizontales discontinuas que terminan en un porcentaje. La más alta de todas, la del 95%, significa que el 95% de los puntos de la gráfica están por debajo de esa línea. Estos percentiles nos permiten saber, por ejemplo, que el 50% de las veces el cycle time está por debajo de 7. También, con los datos que observamos en la imagen, si alguien nos pide un desarrollo en 16 días, estaremos en situación de decirles que se lo entregamos con un 85% de posibilidades en el plazo solicitado.

Además, se podían usar colores para distinguir entre tipos de trabajo, clases de servicio, etc… y tener datos de cada uno de ellos.

Histogram Cycle Time

Los histogramas son gráficas claras y sencillas de leer. Por eso, el histograma de Cycle Time es muy utilizado.

Los datos que podemos ver son los parecidos a los del Cycle time Scattlerplot pero agregados por frecuencia. Esta vez, en vez de ver toda la nube de puntos observaremos la frecuencia de cada uno de los valores de cycle time

 

Tal y como nos pasaba con el Scatterplot, el histograma nos permite entender como funciona nuestro Cycle Time, detectar valores anómalos y observar percentiles. La gran diferencia es que este gráfico, al no tener un eje temporal, no nos permite analizar tendencias. Pero, para muchos, es el que muestra los datos de forma más clara y permite analizar los datos de forma más sencilla.

Throughput Run Chart

Para analizar tendencias en nuestro Throughput podemos usar un Run Chart dónde podremos ver los elementos terminados por unidahttps://www.pqsystems.com/qualityadvisor/DataAnalysisTools/run_chart.phpd de tiempo. Esto, junto con el trazado de una línea de la media, nos permite ver claramente tendencias en nuestro Throughput.

En el siguiente ejemplo podemos ver los elementos terminados en 100 días agregados por semana.

 

 

Aging Work in Progress

La edad de los ítems dentro del sistema es uno de los datos más usados a la hora de tomar decisiones pull. Es importante tener en cuenta cuando entraron en el sistema para intentar garantizar los SLA o SLE.

Si además le añadimos zonas de riesgo por colores podremos ver de una forma muy visual aquellos ítems que están en riesgo.

En el siguiente ejemplo vemos el Work Item Age (los puntos) para los elementos dentro del sistema. Además, vemos 5 estados diferentes en nuestro workflow y, para cada uno, tenemos las zonas de menor riesgo (verde) hasta la zona de mayor riesgo (roja). Con esta información podemos saber que en el último estado hay dos elementos en zona de riesgo medio, y dos en zona de riesgo más alto. Cuando hablamos del último estado suele ser fácil saber este tipo de situaciones. Pero la potencia de esta gráfica radica en que ahora sabemos que el ítem en la primera columna está entrando en zona de riesgo alto. Y que en la segunda ya tenemos dos que han entrado y debemos tener una conversación sobre qué hacemos.

Además, esta gráfica suele venir con nuestros amados amigos: los percentiles.

 

Conclusiones

Me gusta pensar en Lean Kanban como una manera de profesionalizar los servicios que un equipo ofrece a sus peticionarios. Esto nos exige continua mejora y la búsqueda constante de nuestra predictibilidad. Solo midiendo las métricas correctas podremos asegurar un flujo continuo, estable, altamente previsible y potencialmente mejorable.

Espero que os sean de utilidad estos posts. ¿Echas de menos alguna métrica o indicador? No dudes en compartirlo con nosotros en los comentarios.

 

Kanban Metric Layout (I)

El objetivo de estos dos posts es establecer el punto de partida sobre un marco de trabajo de métricas para equipos que estén bajo el método Kanban.

La guía viene separada en dos grandes secciones:

  • Indicadores: Qué es lo que queremos medir (primer post).
  • Gráficas: Donde podremos ver estos indicadores y cómo poder interpretarlos (segundo post).

 

Indicadores

Introducción

Cuando hablamos de indicadores usualmente se utilizan términos como leading y lagging. ¿Pero qué significan?

Lagging indicators suelen ser “output oriented”, fácil de medir pero difícil de mejorar o influenciar, mientras que los leading indicators suelen ser “input oriented”, difíciles de medir pero fáciles de influenciar.

Pongamos un ejemplo. Imagina que nuestra meta personal es perder peso. Un lagging indicator claro que es fácil de medir. Te subes en la báscula y obtienes la respuesta al momento. Pero … ¿como podemos alcanzar nuestra meta? Para perder peso podemos establecer dos “leading indicators”:

1.- Calorías tomadas

2.- Calorías quemadas

Estos dos indicadores son fáciles de influenciar pero difíciles de medir. Cuando pides en un restaurante la cantidad de calorías no están señalizadas en el menú. Y la mayoría de las personas no tenemos ni idea de cuántas calorías quemamos a lo largo del día.

También te puede ayudar a pensar en la diferenciación en que los leading indicators suelen ser de actividad, y los lagging indicators de resultado.

WIP (Work In Progress)

El número de elementos de trabajo empezados pero no terminados.

Aquí no estamos hablando del WIP Limit (extra: ¿Cómo elegir un buen WIP Limit?) . El WIP Limit es una política que los equipos utilizan para crear un sistema Kanban restringiendo la capacidad máxima de su sistema. La meta del WIP Limit es reducir la cantidad de trabajo en progreso (WIP).

El objetivo de dar transparencia al WIP es mostrar a Stakeholders, e incluso a toda la organización, como la reducción de WIP impacta en las demás métricas.

Una buena manera de observar el WIP es utilizar el Cumulative Flow Diagram (CFD).

 

Customer Lead Time

La cantidad de tiempo transcurrido desde que un elemento de trabajo es solicitado por un peticionario y un elemento de trabajo está disponible para el usuario.

Este es el tiempo que más interesa al peticionario. El Customer Lead Time está compuesto por cycles time parciales (dentro de cada estado del workflow) y de waiting states entre un paso y otro.  ¡Ojo! El Customer Lead Time puede depender de más de un equipo por lo que el workflow total está compuesto por el workflow de diferentes equipos.

 

Lead Time o System Lead Time

Es el tiempo que transcurre desde que un ítem de trabajo entra en un punto de compromiso hasta que se entrega.

El punto de compromiso suele recibir el nombre de seleccionadas, ready o next.

La gran mayoría de las veces las prioridades de un servicio no están estipuladas por el equipo si no por la organización. Imaginemos que un peticionario realiza una petición “A” con una prioridad 3 sobre 5, siendo 1 la más baja y 5 la más alta. Pero cuando el equipo ejecuta el siguiente replenishment ha llegado otra petición “B” con prioridad máxima 5. Esto deja fuera del sistema a la petición A alargando su Customer Lead Time.

Este es el motivo por el que un equipo se compromete a tener un lead time lo más estable posible y suficientemente bajo y muchas veces no puede comprometerse con un Customer Lead Time. El Lead Time representa el tiempo que el trabajo está en la zona que pertenece al equipo. Mientras que el Customer Lead Time depende de factores que escapan al equipo y puede dispararse por razones externas como un cambios de prioridades.

Esta métrica es un “lagging indicator” de flujo. Está disponible sólo cuando un elemento está ya terminado desde la perspectiva del workflow. Normalmente se utiliza, junto con el Cycle Time,  para impulsar trabajo de mejora, así como para poder establecer expectativas internas / externas en cuanto al tiempo de respuesta del equipo en elementos específicos.

 

La métrica más usada para observar el Lead Time medio aproximado es el Cumulative  Flow Diagram.

 

Lead Time medio aproximado (que no tiene por qué parecerse al lead time de PBIs individuales, por ejemplo, cuando haya cosas muy viejas en el backlog).

 

 

Cycle Time

La cantidad de tiempo transcurrido entre que un elemento de trabajo “comienza” desde que pasa un punto de commitment y un elemento de trabajo “termina”. En la siguiente imagen por ejemplo desde que entra en desarrollo hasta que está terminado. También puedes tener cycle time parciales por cada uno de los estados del workflow.

La gráficas más usadas para visualizar y analizar los Cycles Times son:

  • Cycle time scatterplot (control chart)
  • Histograma de cycle time

 

Throughput

El número de elementos de trabajo “terminado” por unidad de tiempo.

Nótese que la medición del throughput es el número exacto de elementos de trabajo, sin ningún tipo de compensación por el tamaño del mismo. El throughput se puede medir en cualquier paso del workflow y generalmente se utiliza el final del mismo.

El throughput se puede observar utilizando:

  • Run chart
  • Cumulative  Flow Diagram

Work Item Age

La cantidad de tiempo transcurrido entre cuando se inició el trabajo y la fecha actual.

Work Item Age complementa el Cycle Time. Si el Cycle Time es un lagging indicator relevante sólo para elementos terminados, Work Item Age es un leading indicator solo relevante para los elementos aún en desarrollo. La idea principal de este indicador es proporcionar transparencia sobre qué ítems están fluyendo correctamente y cuales están algo “atascados”, incluso si no están formalmente bloqueados.

El Work Item Age debería ser transparente en el ticket de cada elemento para facilitar buenas decisiones pull. Además, podremos consultarlo en el Aging Work In Progress.

Medir el Work Item Age permite también reducir los riesgos y mejorar la predictibilidad, mejorando la eficiencia global del sistema.

 

En el siguiente post vemos las gráficas donde analizar estos indicadores. ¡No te lo pierdas! Pulsa aquí para ir directo

4 maneras de beneficiarte de Kanban y Scrum juntos

La semana pasada publiqué un artículo un tanto indendiario que ha suscitado dudas entre mis alumnos de esta semana. Hoy voy a intentar introducir la mejor manera de usar Kanban en equipos Scrum.

En primer lugar, explicar que para este artículo me voy a centrar en Kanban, tal y cómo está originalmente concebido, no en el método Kanban. Para ello, voy a basarme en la guía que publicamos hace unos meses en Scrum.org: “Professional Scrum with Kanban“.

Amplificando Scrum, no modificándolo

Kanban, tal y como lo definimos en la guía, es una estrategia para maximizar el flujo de valor hacia los stakeholders a través de un proceso visual que utiliza un sistema pull con una limitación del trabajo en curso (WIP).

Scrum sigue aplicando en su totalidad. Lo que hacemos es añadir un sistema visual para gestionar el trabajo, limitar el trabajo en curso para crear un sistema que balancea demanda y capacidad, y por último, gestionamos el trabajo dentro de ese sistema.

Utilizamos cuatro prácticas:

  • Visualización del flujo de trabajo
  • Limitar el WIP.
  • Gestión activa del trabajo en curso.
  • Inspección y adaptación de la definición de Workflow.

Empecemos por el final

Definición de Workflow

Optimizar el flujo de trabajo requiere que tengamos uno. Por eso es importante que el equipo Scrum determine cual es su workflow y eso requiere de los siguientes elementos:

  1. Puntos definidos entre los cuales se inicia y se completa el trabajo, potencialmente con estados intermedios de completado del trabajo.
  2. Una definición de cuales son las unidades de trabajo que fluyen por ese sistema que aportan valor al cliente, que pueden ser Product Backlog Ítems
  3. Una definición de los estados intermedios por los cuales fluye el trabajo, de los cuales al menos uno debe ser un estado activo de trabajo
  4. Políticas explícitas sobre como fluyen el trabajo a través de los estados (que pueden incluir contenido de la Definition of Done)
  5. Una definición de como se va a limitar el trabajo en curso
  6. Una determinación de expectative de nivel de servicio fijada (Service Level Expectation, SLE)  que comunique una previsión de cuanto se debería esperar para ver trabajo completado.

Puede que los estados definidos en el flujo no coincidan con los estados definidos en el Sprint Backlog. Aunque pueda ser ventajoso que sean iguales, no necesariamente tienen que gestionar. La definición de Workflow no sustituye al Sprint Backlog.

En la práctica, esto es muy similar a lo que ya vienen haciendo muchos equipos Scrum: Utilizar Kanban con limitación de WIP para mejorar el foco y de esa manera optimizar el flujo de valor hacia los clientes. Lo mejor es cuando además lo podemos combinar con métricas de flujo que potencialmente pueden llegar a eliminar la necesidad de estimaciones.

Métricas básicas de Flow

Una vez que tenemos un sistema pull, es muy sencillo obtener métricas de flow que ayuden tanto a mejorar la previsibilidad, como a incrementar la capacidad de foco y maximizar el valor ofrecido al cliente. Las cuatro métricas básicas que un equipo que utilice Scrum con Kanban debería medir son:

  • WIP: El número de elementos que hemos empezado pero no hemos terminado (de acuerdo a la definición de “Workflow” del equipo Scrum)
  • Cycle time: El tiempo que pasa entre que un elemento empieza y acaba.
  • Work Item Age: El tiempo que ha pasado entre que empezó un elemento y el momento actual.
  • Throughput: El número de elementos terminados por unidad de tiempo. Esta medida es una cuenta exacta mientras que las dos anteriores no tienen por qué serlo.

Eventos de Scrum basados en Flow

Una vez que tenemos una definición de workflow con sus elementos y las métricas básicas, entonces podemos empezar a utilizarlos como artefactos de transparencia dentro del equipo Scrum, lo que finalmente conlleva a mejorar el flujo de valor hacia el cliente.

Me dejo la descripción de los eventos para otra semana.

  • Ir a la página 1
  • Ir a la página 2
  • Ir a la página 3
  • Ir a la página 4
  • Ir a la página siguiente »

Mantente al día a través de nuestra Newsletter Susbribirse

Jeronimo Palacios & Associates

Copyright © 2023 · Jerónimo Palacios & Associates S.L.

  • Aviso legal
  • Condiciones de venta
  • Política de cookies
  • Política de privacidad