Scrum o Kanban

Scrum o Kanban

Scrum o Kanban? Esa es la cuestión.

En los últimos años, Kanban ha ido ganando cuota de mercado como alternativa a Scrum. Y muchas personas se preguntan si deberían utilizar uno u otro, otras usan Kanban por razones equivocadas y otras se ven obligadas a usar Scrum cuando Kanban sería un enfoque mucho más acertado en su contexto.

En innumerables ocasiones hemos estado involucrados en discusiones sobre cuál es mejor: ¿Scrum o Kanban?

Puedes beneficiarte de ambos. Sin embargo, Scrum y Kanban tienen varias diferencias importantes que debes tener en cuenta al tomar una decisión.

Con este artículo queremos asegurarnos de que cuando elijas entre Scrum o Kanban, lo hagas por los motivos correctos.

Scrum vs Kanban

Podemos ver Scrum y Kanban como herramientas de mejora de procesos, ya que te ayudan a trabajar de manera más efectiva al decirte qué hacer. Ambas son herramientas para mejorar tus operaciones, para hacer que la organización sea más flexible, más rápida y adaptable, para mejorar la agilidad de tu negocio.

Al igual que cualquier herramienta, Scrum y Kanban no son perfectos ni completos. No te dicen todo lo que necesitas hacer, solo proporcionan ciertas restricciones y pautas. Por ejemplo, Scrum te obliga a tener iteraciones y equipos multifuncionales, y Kanban te obliga a visualizar todo y limitar el trabajo en progreso.

Como regla general, Kanban funciona bien en cualquier lugar donde Scrum funciona bien, pero Scrum no necesariamente funciona bien en lugares donde Kanban está funcionando.

Scrum suele ser mejor en contextos en los que existe cierto nivel de estabilidad, como proyectos, MVPs y productos después de ajuste producto-mercado.

Kanban funciona mucho mejor en entornos con alta variabilidad en la demanda y/o alta variabilidad en el flujo. Como, startups tempranas, equipos de innovación, equipos de descubrimiento de producto, Service Desk, Help Desk, DevOps, Operaciones, Sistemas.

Similitudes entre Scrum y Kanban

  • Ambos limitan WIP: Scrum limitando la cantidad de trabajo por sprint y Kanban de muchas maneras diferentes: por clase de servicio, por actividad o usando CONWIP en implementaciones menos maduras
  • Ambos usan la transparencia para impulsar la mejora del proceso
  • Ambos se centran en entregar software temprano y con frecuencia
  • Ambos requieren romper el trabajo en pedazos (aunque ninguno te explica cómo hacerlo)

Diferencias entre Scrum y Kanban

Veamos las principales diferencias entre Scrum y Kanban:

SCRUM KANBAN
Scrum es un sistema push. A pesar del hecho de que los equipos hacen pull de un lote de elementos del backlog hacia el Sprint, eso no significa que sea pull.

En Scrum, planificamos la producción por adelantado en función de una predicción de productividad para un período de tiempo determinado. Eso es push.

Kanban es pull por definición.
Iteraciones (Sprints). El trabajo debe completarse en un período de tiempo predefinido.

Esto es especialmente estresante en entornos donde las prácticas de ingeniería no son las mejores o la integración continua no funciona correctamente.

Kanban desacopla las actividades de priorización, desarrollo y entrega. La cadencia de cada uno puede ajustarse a su propio nivel natural.

Sin embargo, Kanban no prescinde de la noción de una cadencia regular. Los equipos de Kanban aún entregan software regularmente, prefiriendo un corto período de tiempo.

Kanban evita cualquier disfunción introducida al forzar artificialmente las cosas en las iteraciones limitadas por tiempo.

Scrum sólo menciona explícitamente DoD (Definition of Done) como política. Uno de los principios fundamentales del método Kanban es hacer explícitas todas las políticas.
Eso incluye DoD, DoR, políticas entre actividades en el flujo de valor, políticas para bloquear/desbloquear el trabajo, políticas para modelar la demanda, etc.
Aunque no se dice explícitamente en la guía de Scrum, la mayoría de los equipos de Scrum usan la velocidad en los puntos de la historia para la planificación y la mejora del proceso Kanban utiliza métricas básicas de Lean como tiempo de entrega, WIP, envejecimiento o rendimiento para la planificación y la mejora del proceso.
Prescripción de equipos multidisciplinares Kanban no menciona explícitamente los equipos. El objetivo de Kanban es mejorar la prestación del servicio. No importa si ese servicio está compuesto por 3 personas, varios equipos funcionales o varios equipos multifuncionales. Mapeamos el flujo de valor y conectamos todo con un Sistema Kanban.
Programación push de un lote con cadencia (time-box).

El trabajo se planifica por adelantado en función de la velocidad prevista.

Programación pull con flujo de una sola pieza: planificación justo a tiempo (Just-in-Time)
En Scrum existe el compromiso de ofrecer un alcance flexible para una fecha. Los compromisos en Kanban se realizan contra el tiempo de entrega y las fechas de entrega objetivo.

Kanban no hace promesas basadas en algo que es incierto.

Un sistema Kanban implica un acuerdo de que habrá una entrega regular de trabajo de alta calidad. Kanban no ofrece un compromiso sobre una cierta cantidad de trabajo entregado en un día determinado. Ofrece un compromiso con un nivel de servicio, lo que significa entrega predecible y regular, transparencia, flexibilidad en la priorización y mejora continua en la calidad, el rendimiento, la frecuencia y el tiempo de entrega.

Estimación es requerida No hay especificación en Kanban para estimar. La mayoría de los equipos lo hacen como una inercia del pasado, pero dejan de hacerlo tan pronto como se dan cuenta de que no es necesario para mejorar y aumentar la previsibilidad.

Kanban utiliza métricas de flujo para predecir la entrega y establecer SLAs.

Con la distribución del Lead Time puedes pronosticar la entrega de elementos individuales y la simulación Montecarlo sobre el histórico de la tasa de entrega puedes ejecutar pronósticos probabilísticos en múltiples elementos o proyectos.

Un tablero Scrum o Scrum Backlog es propiedad de un equipo Un sistema Kanban puede estar compuesto por más de un equipo (horizontal) o niveles dentro de la organización (vertical)
Prescribe tres roles (Scrum Master, Product Owner y Team) No prescribe ningún rol, aunque algunas personas en la comunidad Kanban comenzaron a mencionar los roles de Service Delivery Manager y Service Request Manager.

Entre tu y yo, el Service Delivery Manager es un tipo de Scrum Master o Delivery Manager, y el Service Request Manager es un tipo de Product Owner.

Prescribe un backlog priorizado En un sistema de pull no hay priorización. Las cosas se hacen a medida que se introducen en el sistema. Lo que debes definir son las políticas para introducir elementos en el sistema.

Piensa en un Sistema Kanban como un aeropuerto en hora punta. No hay un “Propietario del Aeropuerto” que ordena/reordena y estima a las personas cuando llegan al aeropuerto.

Cada persona tiene una clase de servicio y se dirige automáticamente a su cola específica donde serán procesados en el orden de llegada (VIP, Tripulación, Personal, Viajeros de negocios, Familias, Discapacitados, Objetos especiales, Viajero normal)

Métricas:

  • Velocidad
  • Capacidad Proyectada

Gráficos:

  • Burndown
  • Velocidad de Equipo
Métricas:

  • Lead Time y Cycle Time
  • Tasa de Entrega
  • Trabajo en Curso
  • Eficiencia de Flujo
  • Deuda de Flujo

Gráficos:

  • Diagrama de Flujo Acumulativo
  • Histograma de Lead Time
  • Diagrama de Dispersión de Lead Time
Reuniones obligatorias:

  • Sprint Planning
  • Daily Scrum
  • Sprint Review
  • Sprint Retrospective
Reuniones Recomendadas (También conocidas como Cadencias Kanban):

  • Kanban Meeting
  • Replenishment
  • Delivery Planning
  • Service Delivery Review
  • Operations Review
  • Risk Review
  • Strategy Review

Scrum vs Kanban – Falacias

El Equipo Maduro

Hay quien afirma que Kanban es para equipos maduros que ya tienen una fuerte experiencia en Agile. No lo creo. He trabajado con equipos más y menos experiencia con Kanban y todos mejoraron bastante rápido.

Scrumban

No existe tal cosa como Scrumban. Déjame decirte por qué, con algunos ejemplos:

  • Si estás haciendo Scrum con un carril para trabajo urgente, está haciendo Scrum con interrupciones.
  • Si estás haciendo Scrum pero limitas el trabajo en progreso dentro del tablero para implementar pull dentro del Sprint, ¿adivina qué? Todavía estás haciendo Scrum, porque no estás implementando la programación pull, que es una piedra angular de Kanban.
  • Si está haciendo Scrum porque tienes un Scrum Master, haces retrospectivas y tienes una backlog de producto, pero está implementando la programación pull, limitando WIP y desacoplando la planificación de la entrega, entonces no estás haciendo Scrum, estás haciendo Kanban.

En otras palabras, Kanban es pull y Scrum es push, no puedes hacer ambas cosas al mismo tiempo. Me temo que tienes que elegir.

“¡Tenemos postits en la pared! ¡Hey, estamos haciendo Kanban!”

¿Cuántas veces habré escuchado decir esto? Muchas veces los equipos, cansados de Scrum e incapaces de beneficiarse de él, creen que al eliminar las iteraciones y las ceremonias de Scrum serán más rápidos y productivos. Pero, lo que sucede en realidad, es exactamente lo contrario, terminan peor que antes.

El Método Kanban se implementa con un Sistema Kanban que tiene pocos pero fundamentales principios y prácticas. Como políticas de visualización, diseño de tickets, flujo de trabajo, políticas de pull, clases de servicio o límites de WIP.

“Nuestra organización está haciendo SAFe, por lo que nuestro equipo no puede hacer Kanban”

Esta afirmación es incorrecta. SAFe permite a los equipos usar Scrum o Kanban.

SAFe también implementa una especie de Upstream Kanban a nivel de portfolio.