• 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

scrumban

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.

Scrum y Kanban, lo peor de los dos

No se en cuantas ocasiones es escuchado -y me han preguntado- si la solución a un equipo de soporte es hacer Kanban en lugar de Scrum, o si un equipo que recibe muchas interrupciones debería de pasarse a un sistema Kanban en lugar de Scrum, o hacer Scrumban.

Scrum bien hecho. Scrum mal hecho.

Scrum tiene una serie de premisas:

  • Tienes un producto con un Product Owner que se encarga de maximizar su valor.
  • Tienes un equipo de desarrollo que trabaja para ese producto.
  • Tienes un Scrum Master que gestiona Scrum y sirve al equipo de desarrollo.

Si no tienes un producto, no vas a obtener valor de Scrum. Si no tienes un Product Owner, no vas a obtener valor de Scrum. Si no tienes un equipo de desarrollo, no vas a obtener valor de Scrum. Si no tienes un Scrum Master, no vas a obtener valor de Scrum.

Sí, vale. Puedes hacer Daily Scrums, o Retrospectivas. Pero eso no es Scrum. Simplemente, no lo llames Scrum. Scrum es gratuito y libre para su useo, pero para hacer Scrum necesitas tres roles, tres artefactos y cinco eventos. Puedes hacerlo sin Definition of Done, Sprint Goal o Refinamiento y aún así seguiría siendo Scrum. Pero eso son los básicos.

Kanban bien hecho. Kanban mal hecho.

Kanban necesita una serie de premisas:

  • Tienes un flujo de trabajo que puedes visualizar
  • Puedes limitar el trabajo en curso (p.e. decir NO cuando algo que alguien considera urgente entra al flujo)
  • Tienes control para cambiary gestionar ese flujo de trabajo
  • Puedes establecer políticas explícítas (Clases de servicio, Cadencias, etc…)
  • El ritmo de llegada de nuevo trabajo es similar al ritmo de salida del trabajo.

Si no tienes un flujo de trabajo, Kanban no te va a aportar valor. Si tienes que decir que SI a todo el trabajo que te entra, Kanban no te va a aportar valor. Si no tienes control sobre tu sistema porque otro decide como funciona, Kanban no te va a aportar valor. Si no puedes decidir sobre las políticas del sistema, bueno… creo que ya está claro.

Si, puedes tener un tablero con Post-its y moverlos de un sitio a otro, asignando avatares y haciendo Daily Stand-ups y simulando que eres ágil. Pero si no cumples esas tres condiciones, a pesar de que hagas un Proto-kanban, nunca obtendrás ningún valor.

Scrumban: Lo peor de lo peor, junto.

Cuando la gente me pregunta por Scrumban, siempre me temo lo peor. El caso genérico, con ciertas variaciones es:

“Scrum no funciona para nosotros porque no tenemos un producto, nosotros trabajamos por proyectos. El Product Owner es un Project Manager reconvertido que se encarga de hacer una lista de las cosas que hay que hacer. Además tenemos un SLA y salen un montón de bugs durante el Sprint que tenemos que arreglar, así que hemos incorporado un carril de urgentes en el Sprint Backlog en el que además de hacer los bugs, vamos metiendo lo que se la ha olvidado al Product Owner. Los Stakeholders no vienen a nuestras “demos” y las retrospectivas son para el equipo de desarrollo y para el Scrum Master.

Vemos que es muy difícil saber cuanto estimar en el Sprint Planning y las cosas no salen nunca, por eso empezamos a usar Scrumban.”

Esto no es Scrumban, no es Kanban y tampoco es Scrum.

Lamentablemente esta no es una situación que se arregle con ningún método ágil, así como ningún consultor o Scrum Master va a ser capaz de hacer nada por esta organización.

La solución

El primer paso para arreglar un problema es aceptar que existe un problema. Generalmente en este tipo de organizaciones tienen claro en todas las capas que las cosas van mal, pero hay poca voluntad de solución.

Los problemas aquí deben ser atacados desde la parte ejecutiva de la organización. De nada sirve que un equipo lo haga mejor si la cultura es: “Lo quiero, y lo quiero para ayer”.

Todo lo demás son castillos en el aire.

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