¿Qué es Scrumban?

Scrumban es un híbrido de Scrum y Kanban - una mezcla de las ceremonias de Scrum, con los aspectos visuales, los límites de trabajo en progreso, sistemas pull, y flujo continuo de Kanban. Una combinación como esta es particularmente útil para compañías que están haciendo la transición de Scrum a Kanban, o para aquellas que nunca han usado metodologías Ágiles, pero están interesadas en cambiar a un flujo de trabajo pull.

El término Scrumban fue acuñado por Corey Ladas, autor de “Scrumban: Essays on Kanban Systems for Lean Software Development”.

Scrum y Kanban en pocas palabras

Scrum fue desarrollado como un marco de trabajo para llevar a cabo diferentes tareas de ingeniería en la industria del desarrollo del software. Sus metas eran aumentar la velocidad de entrega de los productos y mejorar la capacidad de responder a los cambios constantes en las condiciones de mercado y requerimientos de los clientes. Scrum divide el trabajo en iteraciones de entre 1-4 semanas llamadas sprints, luego de cada uno de estos, debe haber un producto funcional disponible. En Scrum, los equipos son pequeños y polifuncionales, y todo el trabajo que se hace en determinado sprint es seleccionado por un dueño del producto.

Kanban tiene su origen en la manufactura, y una de sus características principales son los límites al Trabajo en Progreso. Los equipos que usan Kanban se enfocan en mantener un flujo de trabajo continuo, visualizado en forma de tarjetas Kanban en un tablero dividido en etapas de trabajo. Cada etapa tiene un límite determinado de Trabajo en Progreso, ayudando a gestionar el rendimiento, monitoreado regularmente para asegurar la eficiencia y predictibilidad del proceso.

¿Qué es Scrumban?

El híbrido Scrumban permite que los equipos usen lo mejor de ambos enfoques para satisfacer sus necesidades particulares. A veces se recomienda que los equipos más maduros cambien de Scrum a Kanban, y Scrumban es una buena forma de completar esta transición, a pesar de que de vez en cuando, los equipos eligen quedarse con Scrumban. En cierta forma, Scrumban está más alineado con Kanban que con Scrum, en el sentido de que es más fácil de ejecutar en varias aplicaciones, ya que es menos restrictivo que Scrum.

Los orígenes de Scrumban: La dificultad de adoptar Scrum

Hacer la transición hacia las metodologías Ágiles es difícil para la mayoría de los equipos. A veces requiere un cambio completo de paradigmas que puede ser muy difícil de adoptar. Además, debido a la popularidad de Scrum, muchos gerentes piensan automáticamente en Scrum cuando se trata de metodologías Ágiles, a pesar de que hay otros muchos marcos y metodologías que se pueden implementar, tales como Kanban, Programación Extrema, Desarrollo de Sistemas Dinámicos, entre otros..

A pesar de que hay muchas historias de éxito sobre equipos que han implementado Scrum, si pudieras hablar con esos equipos, posiblemente te dirían que alcanzar el éxito con Scrum no ha sido fácil. Para las compañías más exitosas, a veces ha tomado de 12 a 16 semanas desarrollar la disciplina necesaria para hacer que Scrum funcione. Es común que las compañías requieran seriamente de ayuda externa con esto, principalmente usando asesores o consultores. Los negocios suelen tener problemas para encontrar los nuevos roles requeridos de Product Owner (Dueño del Producto), Scrum Master (Dueño del Proceso) y Team (Miembros del Equipo de Desarrollo). Para muchos, esto suele ser un desastre de Recursos Humanos.

Además, calcular los story points y medir la velocidad – a pesar de que no se requiere como parte de la metodología, según la guía oficial de Scrum – esto se ha venido convirtiendo casi en una necesidad. A la mayoría de los equipos les cuesta entender esto, por lo que los Scrum Masters suelen quejarse de lo difícil que es hacerlo adecuadamente. Scrumban hace posible evitar toda esta confusión innecesaria.

Los gerentes de Proyecto están acostumbrados a manejar operaciones que tienen fechas definidas de inicio y culminación. A veces éstos están compuestos de equipos polifuncionales que podrían estar juntos por 12 meses o menos. Equipos como estos pueden funcionar bien con Scrumban, mediante el aprendizaje de las estructuras de comunicación basadas en algunas de las ceremonias de Scrum, con sesiones de planificación dedicadas a la discusión de los requerimientos del proyecto.

Además, para muchos proyectos, especialmente los relacionados con infraestructura, no siempre habrá un producto a entregar al final de cada sprint, lo cual es uno de los requerimientos de Scrum. En lugar de esto, los equipos trabajarían continuamente y avanzarían hacia la fase de producción u otra iteración cuando estén listos. De todo esto se desprende que el enfoque Scrumban adopta un sistema o ciclo de vida de producto existente y simplemente le agrega los elementos visuales de Kanban, junto con algunas de las ceremonias de Scrum.

Y lo que es más, con Scrumban, los gerentes de proyecto no tienen por qué encontrar un solo dueño del producto para que controle los retrasos. El rol del dueño del producto es crítico para Scrum, pero, pero en las corporaciones, a veces hay múltiples involucrados con diferentes tipos de solicitudes, lo que hace imposible que una sola persona pueda priorizar las historias o los problemas. Scrumban no pide historias estándar, o que una sola persona se adueñe de la gestión de los retrasos, simplemente les pide a los equipos que se aseguren de que éstos estén a la vista de todos.

Haciendo la transición de Iteraciones a entrega continua

Scrumban permite que los equipos hagan el cambio de tener que apegarse a determinados tiempos de planificación, a planificar solo cuando es requerido. En el proceso de producción, pueden descubrirse nuevas tareas por hacer. A diferencia de Scrum, Scrumban no obliga a los equipos de producto a limitar el alcance de cada sprint a durar entre 1-4 semanas, permitiendo que la producción tome el tiempo que necesite para conseguir los mejores resultados. Mientras que, desde la perspectiva de proyecto, todo termina allí, para la mayoría de las empresas, este es sólo el inicio del viaje. Los proyectos se ejecutan de modo que el cambio temporal iniciado por ellos pueda seguirse llevando y produzca beneficios. Scrumban es muy útil en ese sentido.

Los equipos que han usado Scrum pueden encontrar más fácil cambiar a Scrumban en las etapas finales del Proyecto, cuando hacen la transición del desarrollo al mantenimiento del producto, y toman un enfoque de flujo continuo.

Entonces, ¿En que se diferencian Scrumban y Kanban?

Típicamente, los equipos que usan tableros Scrumban dividirán el flujo de trabajo en más etapas de las que usarían en un tablero Kanban. Esto, con la finalidad de mostrar un proceso de naturaleza más gradual, derivado del enfoque similar al sprint aplicado a la planeación del proyecto. Con frecuencia, un tablero de Scrumban sigue incorporando una etapa de sprint o una etapa dedicado a las “Historias”, sin importar si el equipo trabaja de manera continua.

Además, los equipos de Scrumban suelen tener más libertades para priorizar ítems en las columnas, que quienes trabajan con Kanban, que tiende a apegarse al orden FIFO (también conocido como cola).

Conclusión

A medida que las compañías se dan cuenta que necesitan avanzar hacia un uso mayor de las metodologías Ágiles, Lean Scrumban es una forma fácil de hacerlo, gracias a que remueve cualquier tipo de desorden producido por Scrum, que muchos en las empresas no van a necesitar. También permite a las compañías seguir trabajando de una manera que les resulte natural, pero – al mismo tiempo – implementar las mejores prácticas de las metodologías Lean y Ágiles específicas para entornos de flujo continuo.

Scrumban puede darte justo la cantidad de rigor necesaria, junto con la flexibilidad, eficiencia y visibilidad de Kanban y Lean.

Los beneficios principales del uso de Scrumban son:

• mayor calidad del trabajo terminado y toma de decisiones sobre la marcha
• aumento en la velocidad de procesamiento
• minimización de los desperdicios
• aumento del empoderamiento de los equipos, lo que se traduce en un aumento en la felicidad de éstos
• mejora continua de los procesos.