Scrum vs Kanban: Una comparación de metodologías ágiles

Las empresas deben ser ágiles. Las empresas deben ofrecer servicios digitales rápidamente; deben alinearse con las necesidades cambiantes de los clientes. Las startups lean son la moda en la era del VUCA. Pivotar en respuesta a las tendencias del consumidor ya no puede esperar a procedimientos de cambio monolíticos y burocráticos. Los profesionales del sector tecnológico han priorizado dos enfoques, Scrum y Kanban, en busca de esta agilidad.

Veamos las principales diferencias entre Scrum y Kanban. Ten en cuenta que no son opuestos: no es uno u otro. De hecho, tú puedes Obtén el mayor beneficio al usarlos juntos.

Scrum

Kanban

Historias de origen

La forma en que se originaron Scrum y Kanban pone de manifiesto sus diferencias.

Scrum se originó con un artículo de HBR de enero de 1986, The New New Product Development Game, escrito por Hirotaka Takeuchi e Ikujiro Nonaka. La premisa principal era alejarse de un enfoque secuencial para el desarrollo de nuevos productos. En cambio, los desarrolladores debían adoptar un proceso holístico, rápido y flexible. (Takeuchi y Nonaka tomaron prestado del rugby, de ahí el nombre Scrum.)

Ken Schwaber y Jeff Sutherland adoptaron estas ideas, presentando Scrum y su aplicabilidad al desarrollo de software en la conferencia de Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones (OOPSLA) de 1995. En 2001, Schwaber y Sutherland participaron en la famosa reunión de la estación de esquí donde se elaboró el Manifiesto Ágil. Ambos posteriormente escribieron la Guía Scrum, en 2010, que hoy está reconocida como el Cuerpo Oficial de Conocimiento de Scrum.

Kanban se originó décadas antes, cuando los dueños de tiendas japonesas usaban carteles en calles concurridas para anunciar sus productos y diferenciarlos de la competencia. El nombre Kanban proviene de dos nombres japoneses , Kan que significa 'signo' y Ban que significa 'cartel'.

En 1956, un joven ingeniero industrial de Toyota, Taiichi Ohno, creó un sistema que utilizaba tarjetas de papel para señalizar y controlar la demanda en su fábrica, llamando al nuevo sistema Kanban. Beneficios como la reducción de stocks, la mejora del rendimiento y la alta visibilidad del proceso impulsaron este enfoque hacia el éxito. El sistema se incorporó a toda la organización en 1963 y pasó a formar parte del Sistema de Producción de Toyota.

En 2004, David J. Anderson fue el primero en aplicar Kanban a TI, desarrollo de software y trabajo del conocimiento.

Ideologías

Las personas utilizan el marco Scrum para abordar problemas adaptativos complejos, mientras entregan productos de mayor valor de forma productiva y creativa. Scrum se está basado en la teoría empírica del control de procesos, que sostiene que el conocimiento proviene de la experiencia y de la toma de decisiones basadas en lo que están conocido. Tres pilares sostienen este enfoque:

• Transparencia. Aspectos significativos del proceso deben ser visibles para quienes participan en los resultados.
• Inspección. Los implicados deben inspeccionar frecuentemente los artefactos y avanzar hacia el objetivo.
• Adaptación. Si algún aspecto de los artefactos o progreso no está satisfactorio, hay que hacer ajustes lo antes posible.

Kanban están una forma de mejorar el flujo y provocar la mejora del sistema mediante la visualización y el control del trabajo en curso. Tiene cuatro principios fundamentales:

• Comienza con lo que te hacer ahora.
• Aceptar perseguir un cambio evolutivo.
• En un principio, respeta los puestos, responsabilidades y títulos actuales.
• Fomenta actos de liderazgo en todos los niveles.

Prácticas

Scrum denota cinco eventos basados en el tiempo para gestionar la entrega del producto de forma iterativa e incremental, maximizando las oportunidades de retroalimentación. Estos son:

1. Planificación de sprints. Una sesión de ocho horas en la que el equipo decide qué entregar en el próximo sprint (a partir del backlog de producto) y cómo hacerlo.
2. Sprint. Un marco temporal de un mes o menos en el que el equipo cumple lo acordado en la sesión de planificación del sprint.
3. Scrum diario. Un timebox de 15 minutos (comúnmente conocido como daily stand up) donde el equipo se reúne diariamente durante el sprint para inspeccionar el progreso e identificar bloqueadores.
4. Revisión de Sprint. Un evento de caja de tiempo de cuatro horas que se celebra al final del sprint. El equipo demuestra el producto/cambios a los clientes y recopila comentarios sobre qué incorporar en el backlog del producto para su entrega en sprints posteriores.
5. Retrospectiva del sprint. Un evento de tres horas de tiempo que se celebra tras la revisión del sprint (y antes de la siguiente planificación del sprint). El equipo revisa su trabajo, identificando oportunidades para mejorar los procesos de trabajo en los sprints posteriores.

Roles

Marco Scrum (Fuente)

Kanban tiene seis prácticas principales:

1. Visualiza el flujo del trabajo. Utiliza tarjetas o software para visualizar las actividades del proceso en las pistas de natación.
2. Limita el trabajo en progreso (WIP). Anima a tu equipo a completar primero el trabajo que tienes entre manos antes de asumir el nuevo. El equipo solo incorpora el trabajo nuevo cuando tiene capacidad para gestionarlo.
3. Gestiona el flujo. Observa el trabajo mientras fluye por los carriles de natación. Aborda cualquier cuello de botella.
4. Haz explícitas las políticas de proceso. Diagrama visualmente las reglas y directrices de proceso para gestionar el flujo de trabajo.
5. Implementa bucles de retroalimentación. Durante todo el proceso de trabajo, incorpora revisiones periódicas con el equipo y los clientes para recopilar e incorporar comentarios.
6. Mejorar de forma colaborativa, evolucionar experimentalmente. Como equipo, buscad e incorporad iniciativas de mejora, incluso mediante experimentos de seguridad para fracasar.

Junta Kanban (fuente)

El scrum define tres roles principales:

• Product Owner. La única persona responsable de gestionar el Product Backlog.
• Scrum Master. Un líder servidor responsable de ayudar al equipo a entender la teoría, las prácticas, las reglas y los valores de Scrum.
• Equipo de desarrollo. Grupo autoorganizado de 3 a 9 profesionales responsables de entregar los productos.

Kanban no tiene roles fijos. Sin embargo, David Anderson aboga por dos roles:

• Gestor de Prestación de Servicios (SDM). La persona que garantiza el flujo de los elementos de trabajo y facilita las actividades de cambio y mejora continua.
• Responsable de Solicitudes de Servicio (SRM). La persona que ordena y prioriza los elementos de trabajo y mejora la gobernanza corporativa con el proceso.

Métricas

En Scrum, la métrica principal de producción está la velocidad. Esta describe la tasa de progreso de lo que el equipo está entregando, basada en la estimación realizada durante la planificación del sprint. El equipo de Scrum utiliza la velocidad como indicador de cuánto son entregando los elementos del backlog de producto en cada sprint, en función del esfuerzo requerido.

Kanban utiliza dos métricas principales:

• El tiempo de ciclo mide cuánto tiempo pasa una tarea en el proceso (es decir, cuánto tiempo permanece una tarjeta dentro de los carriles de natación en proceso).
• El rendimiento mide la cantidad total de trabajo entregado en un determinado periodo de tiempo (es decir, el número de tarjetas entregadas en cada periodo en un tablero Kanban específico).

Usando Scrum y Kanban juntos

Scrum y Kanban pueden usarse juntos, tanto en entornos de desarrollo como en gestión de servicios de TI. De hecho, ha surgido el marco de Scrumban. Scrumban aprovecha ambos marcos para adoptar mejor la agilidad y mejorar lo que está en falta en cada uno. Utilizar ambos marcos aporta muchos beneficios, especialmente desde la perspectiva de las personas: fomentar la colaboración y la mejora mediante la retroalimentación y centrar la atención en entregar valor empresarial.

Recursos adicionales

Para conoce más sobre Agile y desarrollo de software, consulta estos blogs de BMC:

• Introducción a Agile con Scrum: 4 consejos para empezar
• Roles y responsabilidades ágiles
• Feedback de los usuarios de los clientes: la piedra angular del enfoque ágil
• El ciclo de vida del desarrollo de software (SDLC): Una introducción
• Bucles de retroalimentación de DevOps: Una introducción

Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.