Categoría: Scrum

Hoy revisaremos una parte que aunque no está explicitada la utilización directamente en la guía de Scrum está implementada en la mayoría de los equipos que utilizan Scrum. Se trata del tablero Kanban , también conocido como el sitio donde los agilistas ponen los postit :)

Los tableros Kanban están muy extendidos y aceptado por los equipos Scrum siendo un elemento de transparencia e inspección que se convierte en una herramienta muy potente si sabes hacer uso de ella. Tenéis que tener en cuenta que el Kanban utilizado en Scrum es una versión reducida y adaptada con la intención de que los dos se complementen formando un tándem muy poderoso.  

Recordad que la unión hace la fuerza ( siempre que se tenga un objetivo común o un buen Sprint Goal 😛 )

Os dejo el link a la guía Kanban para Scrum.

Con la intención de engancharos a Kanban (desde la visión de Scrum) te resumo en unas líneas y de manera muy general los beneficios y mas abajo (para los mas cafeteros ) entro de manera mas técnica aportando datos:

Kanban ayuda en todos los eventos de Scrum, aportando motivos de conversaciones en la Daily para tomar consciencia del estado real del sprint. Aporta conocimiento sobre la capacidad de trabajo del equipo en la Planning. Ayuda al Producto Owner en la review quitando incertidumbre y poder estimar el alcance de la próxima entrega de valor. Entrega información para poder motivar al equipo con la mejora o encontrando los “pain points” en la retrospectiva para evolucionar en la mejora continua de todo el equipo Scrum.

Ahora sí, esta parte es mas técnica y la intención es en próximos posts explicaros que son cada una de las partes así como el funcionamiento del tablero.

Kanban en los diferentes eventos de Scrum:

1. Sprint Planning
   1. Kanban ayuda entregando métricas del Flow de sprints anteriores y así ayuda a todo el equipo Scrum a entender su capacidad de trabajo, siendo este un valor clave para la planificación del siguiente Sprint.  ¿Cuánto valor podemos entregar en un Sprint?, ¿Cuántos PBI (Tareas, Historias de usuarios, casos de uso, etc…) podemos incorporar al Sprint Backlog?

2. Daily Scrum
   • Es un gran generador de conversaciones sobre el estado real del trabajo involucrando a todos los Developers y haciéndoles reflexionar sobre el camino hacia el Sprint Goal.

3. Sprint Review
   • Las métricas pueden crear oportunidades de conversación y proveer de información adicional al Product Owner para priorización de Product Backlog así como para estimación de próximas entregas de valor.

4. Retrospectiva
   • Las métricas aportadas sirven para motivar al equipo revisando la evolución del “average cycle of time” , “average througput” y del WIP del equipo utilizando el “cumulative flow diagram”).
   • Podemos definir mejoras en el tablero para mejorar en el entendimiento del equipo:
     • ¿es necesaria la utilización de “políticas”?
     • ¿Es necesaria la utilización de “Clases de servicio”?
   • Viendo la evolución de las métricas podemos saber si el equipo está en un estado de mejora.

Por hoy me despido y espero haber sido capaz de transmitir un poco de la potencia de Kanban.

Como siempre ¡sed curiosos! Y hasta pronto.

Hola de nuevo, volvemos otro día con una nueva píldora y hoy me voy a meter en un buen lío (yo solito). Voy a hablar de… Scrum vs Kanban a vista de pájaro (of course).

La intención que tengo no es explicar todo sobre ellos, ni mucho menos, pero sí intentaré que entiendas para qué se puede utilizar cada uno, ya que son para cosas muy distintas.

Como siempre ras i curt!

Scrum: 

Visualizamos cómo puede ser el producto y vamos entregando con control de tiempo y de manera iterativa un incremento utilizable (compuesto siempre de los elementos (pbi) del Product Backlog de más valor en ese momento). No estamos buscando entregar el producto final acabado al 100% si no que vamos aportando partes / funcionalidades que aportan valor en base al mercado (controlando PKIs de control) y siempre con el cliente final en el foco, lo cual puede hacer que nuestro producto sea muy diferente a lo proyectado pero que tenga siempre el mayor valor para el usuario final.

Podemos decir que Scrum abraza y acepta la incertidumbre y nos entrega reglas para poder ir despejándola aportando además control sobre cuándo y qué partes del producto van a ser entregadas. También como resumen os escribo los pilares de Scrum (lo que dicen mucho de él) Transparencia, Inspección y Adaptación (siempre desde el empirismo).

Kanban: 

Busca visualizar todos los estados por los que tiene que pasar el valor o producto, para poder visualizar la información de lo que se está realizando en todo momento.

La intención es tener una transparencia total del proceso y poder mejorarlo haciéndolo más fluido (bajar el Lead Time), siendo una herramienta muy buena de detección de “cuellos de botella” y de ajuste de los mismos.  

En este aspecto Kanban busca la mejora en la producción y no la mejora en el producto ya que este está definido de inicio. 

Es una herramienta muy pero que muy versátil y puedes establecer priorización de tareas introduciéndolas en carriles, saber estados de carga de trabajo de personas o de equipos, limitar el número de tareas que hay en un determinado punto del proceso (valores máximos o mínimos y definir reglas que se aplicarán cuando se llegue a estos valores), mezclar varias métricas, etc… Es por ello que Kanban es muy poderoso.

Be smart!

Por regla general y creo yo que de manera muy inteligente, dentro de los equipos de desarrollo de Scrum se utilizan los tableros Kanban durante el Sprint (aunque creo que Kanban es «ese gran desconocido») ya que uniendo estas dos poderosas herramientas obtienes un pack inmejorable de transparencia y mejora continua.

El equipo utilizando Kanban puede controlar de muy buena manera el estado del Sprint Backlog (el trabajo que tienen pendiente de acabar dentro de ese Sprint) además de saber todo lo que hay en proceso para poder controlar las dependencias.

Pues hasta aquí la chapa del día de hoy 🙂 y espero que os sea muy muy útil.

Saludos y ¡hasta muy pronto!