Kanban vs Scrum lo mejor de cada casa y un poco de ScrumBan

Aunque Scrum es por mucho, el marco de trabajo ágil más popular , en los últimos años, muchas organizaciones han estado experimentando problemas con ella y se están moviendo a un modelo Kanban para sus esfuerzos de desarrollo de software.

Hay algunos desafíos válidos con scrum que pueden hacer de Kanban una mejor opción para los equipos. Sin embargo, Kanban viene con sus propias ventajas y desventajas.

Algunos equipos están sacando lo mejor de ambos mundos combinando técnicas de Scrum y Kanban, usando Scrumban o su propia metodología única.

He reunido algunos recursos que describen los desafíos de cada metodología y de paso mostrar algunas maneras de mitigar esos desafíos combinando Scrum y Kanban de varias maneras.

Las diferencias entre Scrum y Kanban

Una comparación de Scrum vs Kanban muestra que son similares en muchos aspectos.

Ambos son modelos empíricos que adoptan principios de desarrollo ágil y ágil. Ambos fomentan la entrega temprana y frecuente, equipos auto-organizados, mejora continua, alta calidad y priorización de requerimientos basados en el valor de negocio

Scrum es mucho más prescriptivo por naturaleza, requiriendo ciertos componentes:

scrum prescriptivo

  • Roles: El maestro scrum, el dueño del producto y el equipo de desarrollo.
  • Artefactos: Cartera de pedidos de productos, cartera de pedidos de sprint, e incremento del producto.
  • Eventos cronometrados: El sprint, que incluye la planificación del sprint, las paradas diarias, las revisiones de sprint y las retrospectivas.

La guía de Scrum da pautas muy específicas para cada uno de ellos y es bastante rígida en la expectativa de adherencia del equipo, con la responsabilidad primaria del Scrum Master en “asegurar que el scrum sea entendido y ejecutado“.

Kanban, por otra parte, no es prescriptivo en absoluto. Sólo tiene tres reglas:

  • Visualizar el flujo de trabajo
  • Limitar el trabajo en curso (WIP)
  • Medir y mejorar el flujo

Con tan pocas reglas, sería muy fácil aplicarlas al scrum. La mayoría de los equipos scrum ya visualizan el flujo de trabajo con el uso de un panel de tareas. Si los equipos aplican límites al trabajo en curso (WIP), miden el flujo, y mejoran el flujo a través de retrospectivas, podrían esencialmente aplicar las “reglas” de Kanban a sus metodologías de scrum existentes, aunque algunos podrían argumentar que el flujo no está optimizado con iteraciones de caja de tiempo.

Desafíos al usar Scrum puro

La Guía Scrum es enfática en que los sprints deben ser clasificados en un mes o menos (con dos semanas siendo más típicos) y que los sprints deben resultar en un producto potencialmente “lanzable” para cada incremento.

Algunos equipos creen que los sprints de scrum de con un timebox frenan al equipo, introduciendo sobrecargas innecesarias.

Además, se pide a los equipos que utilizan scrum que se comprometan a entregar un software de trabajo y calidad de producción al final de cada sprint corto.

A los equipos se les enseña que, debido a que están proporcionando las estimaciones en lugar de tenerlas transmitidas por los managers, y que estarán trabajando a un ritmo sostenible.

Sin embargo, se presiona a los equipos para que diseñen, codifiquen y prueben su código y para que organicen una demostración para los stakeholders, todo ello en un plazo de tiempo muy corto.

Esta presión para entregar código de trabajo y calidad de producción en incrementos cortos puede no ser realista y puede causar más ansiedad al equipo, no reducirlo.

Con scrum, los equipos se comprometen a entregar las  historias de usuarios comprometidas  y añaden a su backlog de sprint.

Sin embargo, es posible que se encuentren con problemas durante el sprint que no pueden resolver, o que se vean interrumpidos por una corrección de errores de alta prioridad u otro problema inesperado que les impida terminar las historias en su backlog de sprint.

Debido a que ya se han comprometido a completar las historias de los usuarios y se espera una demostración, pueden decidir recortar gastos o añadir deuda técnica para cumplir con los plazos de entrega impuestos.

Los defensores del scrum argumentan que las iteraciones cortas y las retrospectivas obligatorias proporcionarán la retroalimentación necesaria para mejorar continuamente tanto los procesos como el producto.

Los sprints cronometrados, aunque desafiantes, también ayudan a proporcionar disciplina y estructura.

En teoría, las fechas límites perdidas ayudarán a los equipos a aprender con el tiempo cómo planificar mejor sus carreras y no comprometerse demasiado. Debido a que los sprints son cortos, cualquier fracaso será aceptado como una oportunidad para aprender y mejorar.

Desafíos al usar Kanban puro

Kanban, por otro lado, proporciona muy poca estructura. No es realmente una metodología, sino más bien una técnica. Si no empiezas a usar un enfoque más disciplinado, es probable que los nuevos equipos fracasen.

Por esta razón, los coaches a menudo recomiendan que los nuevos equipos ágiles empiecen con una metodología más prescriptiva, como el scrum.

 Otra crítica a Kanban es que es demasiado lineal. 

Desde que se utilizó por primera vez en Toyota en una línea de fabricación, muchas personas sienten que es más relevante en situaciones que tienen procesos repetibles en lugar de sistemas complejos como el desarrollo de software.

A menudo se recomienda el Kanban para trabajos de mantenimiento en lugar del desarrollo de nuevas características.

En The Problem with Kanban, Rob Williams señala que a su equipo le gusta la simplicidad de un enfoque lean sobre el scrum, pero todavía tienen problemas.

Sin las retrospectivas necesarias, también existe el riesgo de que el equipo no se tome el tiempo para reflexionar y mejorar regularmente.

Dicho esto, los principios lean sugieren que el equipo pasa regularmente por un PDCA (plan-do-check-act), y muchos equipos que practican Kanban continúan con la práctica de realizar retrospectivas regulares, aunque no son obligatorios como lo son en scrum.

Combinación de Scrum y Kanban o mejor dicho ScrumBan

Corey Ladas fue el primero en describir una metodología híbrida scrum/Kanban, acuñando el término “Scrumban”. Ladas es el autor del libro Scrumban: Essays on Kanban Systems for Lean Software Development 2009. En un ensayo, describe el enfoque, sugiriendo comenzar con scrum y luego optimizar hasta un punto en el que las ceremonias de sincronización ordenadas por scrum ya no son necesarias.

Scrum puede ser un andamio útil para mantener a un equipo unido mientras se construye una solución más optimizada. En algún momento puedes desprenderte del capullo y permitir que el sistema de tracción extienda sus alas y tome vuelo. Corey Ladas

Sin embargo, eliminar los eventos de caja de tiempo no es la única interpretación de Scrumban.

En el libro The Scrumban[R]Evolution: Getting the most out of Agile, Scrum, and Lean Kanban, Ajay Reddy abre con:

Aunque Scrumban ha evolucionado como marco de referencia a lo largo de los años, no tiene una guía o definición definitiva. De hecho, como se destaca al principio de este libro, varias fuentes “autorizadas” no están de acuerdo sobre lo que Scrumban realmente representa.Ajay Reddy

El modelo de Reddy, en lugar de mezclar scrum y Kanban, se describe como “un marco de gestión que surge cuando los equipos emplean scrum como su forma elegida de trabajar y utilizan el Método Kanban como una lente a través de la cual ver, entender y mejorar continuamente cómo funcionan”.

El modelo de Reddy de Scrumban sugiere iteraciones cronometradas cuando es apropiado, pero también sugiere equipos y funciones especializadas junto con una priorización económica deliberada.

De hecho, muchas organizaciones tienen equipos, como los equipos de mantenimiento o los equipos SysAdmin, que utilizan Kanban sin timebox, y otros, como los equipos de desarrollo de nuevas características, que usan scrum con sus respectivos timeboxes.

Las grandes estructuras empresariales como el Scaled Agile Framework (SAFe) y el Disciplined Agile Delivery (DAD) utilizan modelos scrum y Kanban, dependiendo del contexto.

Encuentrar un punto de partida, luego seguir el camino.

No es de extrañar que los expertos ágiles no estén de acuerdo en la definición de Scrumban.

¿Cómo puede haber un enfoque definitivo a cualquier metodología ágil cuando una de las reglas primarias es adaptar la metodología para sus propios propósitos?

Lo importante es recordar que los equipos necesitan estructura y disciplina al menos como punto de partida antes de poder adaptarse y mejorar.

Aunque el scrum es mucho más prescriptivo que Kanban, los equipos recién formados se benefician típicamente de la estructura y disciplina de una metodología más definida.

Otros a quienes les gustaría la estructura y el aprendizaje continuo proporcionado por scrum pero que quieren más del flujo continuo proporcionado por Kanban podrían beneficiarse de un híbrido scrum/Kanban, quizás empezando con un enfoque Scrumban.

Los expertos ágiles pueden tener opiniones divergentes sobre las especificaciones o la terminología, pero la reflexión y las mejoras regulares son algo que todos están de acuerdo en que es beneficioso y común a todas las metodologías ágiles.

Comience por entender los conceptos Lean y ágiles subyacentes detrás de Scrum y Kanban, antes de implementar una metodología definida, y es improtante recordar regularmente reflexionar y mejorar.