Kanban vs Scrum: Conoce sus diferencias

Una de las grandes preguntas que abordan las empresas y equipos que quieren ser ágiles es qué metodología escoger.

Aquí surge la cuestión de qué características tiene Scrum y cuáles Kanban para seleccionar la metodología más adaptada a su contexto.

  Qué diferencias hay entre Scrum y Kanban

Para ver las diferencias entre Scrum y Kanban vamos a examinar como  varios factores:

• Tipo de trabajo.
• Roles exigidos.
• Equipos.
• Cadencia de los eventos.
• Necesidad de estimación.
• Tamaño de los ítems.
• Posibilidad de introducción de cambios.
• Periodicidad de entrega.
• Límites al WIP.
• Urgencia de las nuevas peticiones.

El tipo de trabajo al que está orientado Scrum es fundamentalmente proyectos.

Kanban en cambio parece a primera vista que está orientado a servicios. Pero si vemos a un proyecto como un conjunto de servicios, se puede aplicar también a los proyectos sin problemas.

Scrum tiene ciertos roles exigidos para funcionar como Product owner o Scrum Master.

Estos roles realizan funciones muy importantes para el éxito de un equipo. Pero en muchos contextos pueden ser difíciles de justificar como puestos independientes debido a la falta de carga de trabajo. En otros casos, como los de las empresas que ejecutan proyectos para otras, los pliegos técnicos de los procesos de compra incluyen determinados roles (p. ej. jefe de proyecto y excluyen otros).

En Kanban no hay roles exigidos, ya que para facilitar su adopción se respetan los roles y la organización existentes, lo cuál ofrece una enorme flexibilidad para adaptarse a cualquier contexto.

No importa quien sea designado el responsable sino que se adopten determinadas prácticas adecuándolas siempre a cada situación particular.

Respecto a los equipos, Scrum está concebido para ser utilizado en un solo equipo -para más de un equipo hay que ir a otros métodos como Nexus o LeSS- con el personal en principio dedicado íntegramente al mismo, polivalente y autoorganizado.

Polivalencia y autoorganización quiere decir que los equipos cuentan con todas las habilidades para ejecutar el trabajo y la autoridad para tomar todas las decisiones necesarias sin recurrir a otros roles o partes de la organización. Esto, sin duda, ayuda a ser más ágil, pero es una visión maximalista que, indudablemente, dificulta su aplicación restricciones.

Kanban puede utilizarse fácilmente en varios equipos, con recursos compartidos, sin personal polivalente y dependencias jerárquicas y de otros servicios.

La aplicación de Kanban para gestionar varios equipos es trivial. Asimismo tiene prácticas para realizar la gestión de personal dedicado parcialmente y otros recursos compartidos. Obviamente prefiere equipos polivalentes pero no tiene ningún problema en utilizar equipos compuestos por especialistas en un único dominio. Y, aunque prefiere la autoorganización y la interfuncionalidad, gestiona bien las dependencias jerárquicas así como de otros servicios con el objetivo de reducir su impacto sobre los plazos.

La cadencia de los eventos en Scrum está marcada por la duración fija de los sprints que marca una misma periodicidad de ejecución de los mismos (planificación, revisiones y retrospectivas).

En Kanban la cadencia de los eventos está desacoplada. Pueden realizarse todos con la misma periodicidad, con periodicidades diferentes o, incluso, a demanda.

En Kanban las reuniones y revisiones pueden tener una misma periodicidad (p. ej. quincenal) o tener periodicidades diferentes (p. ej. La reposición, semanal; las revisiones, mensuales, etc.). Hasta pueden tener periodicidades a demanda, realizándose según necesidades (p. ej. Reposición cuando queden menos de 5 peticiones en la columna «Next»).

Scrum necesita que se realice una estimación de los ítems para poder seleccionarlos en la planificación de los sprints y para ello cuenta con técnicas de estimación rápida.

Kanban no necesita estimaciones. Pueden realizarse o no, a conveniencia del equipo. Y esto es porque se parte del supuesto de que habrán numerosas peticiones que deben resolverse sin importar su tamaño y que estas pueden requerir un esfuerzo desconocido a priori que generalmente no será muy elevado.

Scrum necesita que el tamaño de los ítems sea muy inferior a la capacidad del equipo durante un sprint.

Kanban puede utilizar cualquier tamaño de ítem, aunque recomienda que sean lo más pequeños posible siempre que tenga sentido desde un punto de vista técnico y de servicio.

Respecto a los cambios en el trabajo previsto y las prioridades, Scrum los evita dentro del sprint -aunque hay que decir que su visión se ha flexibilizado de forma importante en las últimas versiones de la guía y ya no es tan altamente restrictiva como antes.

Kanban permite cambios en cualquier momento para adaptarse a la aparición de nuevas peticiones urgentes e inesperadas.

Esto no quiere decir que se admita cualquier cambio. Se intentará ser adaptable pero al mismo tiempo evitar la disrupción del sistema priorizando los cambios de acuerdo con las políticas definidas en las clases de servicio. Asimismo es recomendable conformar la demanda para evitar una llegada injustificada de peticiones urgentes.

Respecto a la entrega Scrum la redacción de las guías anteriores parecía indicar una periodicidad de entrega en lotes con la periodicidad de los sprints lo cuál no es cierto porque esto impediría el despliegue e integración continua y sería poco ágil. Lo que sigue el ritmo de los sprints es más la revisión del incremento realizado que la entrega del mismo.

Kanban tiene una entrega potencialmente continua.

Respecto a los límites al WIP (trabajo en curso), Scrum introduce un límite por sprint, que es el conjunto de ítems del sprint backlog.

Kanban establece límites al WIP por aquél objeto que sea más pertinente: por fase, por recurso (equipo, persona,…), por tipo de ítem, por clase de servicio,…

Finalmente, respecto a la urgencia de las nuevas peticiones, Scrum supone que los nuevos ítems pueden esperar -con contadísimas excepciones- hasta los próximos sprints.

Kanban, en cambio, realiza una priorización continua por valor y se amolda perfectamente a contextos en los que hay frecuentes ítems que no pueden esperar a los próximos sprints.

&nbsp Cuándo aplicar Scrum y Kanban

Con los ajustes adecuados, Scrum y Kanban se pueden aplicar en muchos contextos, pero aquí hay unas reglas generales, a tomar con toda la precaución de las excepciones que pueden surgir en cada situación concreta.

 

Tipo de trabajo

Scrum aplica mejor a equipos que realizan proyectos. De hecho, es habitual que si los equipos Scrum realizan servicios, los gestionen al margen de Scrum. Entonces, cuando estiman su disponibilidad para el proyecto en la planificación del sprint quitan la dedicación prevista a los servicios.

Kanban más a equipos que prestan servicios (p. ej. Mantenimiento), que combinan una alta proporción de proyectos con servicios o que realizan un flujo de peticiones que proceden de diferentes proyectos.

 

Tiempo de respuesta esperado por los clientes y necesidad de cambio de las prioridades

Scrum es apropiado si los clientes pueden esperar un período relativamente largo a ver sus peticiones atendidas -como mínimo se acabe el sprint.

Si la incertidumbre de la demanda hace que sea necesario cambiar frecuentemente el trabajo a realizar, el funcionamiento por Sprints se ve seriamente perturbado.

Kanban, en cambio, se adapta mejor a un entorno más fluido (o directamente caótico) de peticiones, donde una cierta proporción de éstas debe responderse en un plazo relativamente corto y donde prima la flexibilidad ya que puede ser difícil mantener una planificación de trabajo incluso a corto plazo.

 

Grado de cambio organizativo

Scrum exige introducir nuevos roles (product owner, Scrum Master). Es más fácil de aplicar en equipos o departamentos que tienen una alta independencia en su gestión o bien un gran apoyo de la Dirección para hacer cambios organizativos.

Si no existe esta alta independencia, un gran apoyo para los cambios o bien se considera que demasiados cambios son un riesgo que puede reducir la capacidad de entrega

 

Mejora continua

Tanto Scrum como Kanban incorporan la mejora continua en sus eventos y reglas. Scrum insiste mucho en que el equipo sea altamente independiente como medio para conseguir la agilidad pero a partir de aquí guía bastante poco sobre cómo y dónde mejorar.

Kanban en cambio, supone que el equipo tendrá dependencias del resto de la organización y del cliente y que esto, que nunca se resolverá totalmente, será una fuente de problemas. Por esto Kanban tiene una “ideología” respecto a qué provoca los problemas y cómo solucionarlos, lo que proporciona una orientación muy poderosa para la mejora.

 

  No es necesario escoger entre Scrum y Kanban: Scrumban

¿Significa todo lo anterior que hay que hay que escoger entre Scrum o Kanban?

No necesariamente.

Hay ciertos contextos en los que una metodología va mejor que la otra (y viceversa), existen muchos otros donde se pueden aplicar ambas con éxito. Y aplicarlas combinadas, para aprovechar lo mejor de cada una.

En ese caso estaríamos aplicando Scrum con Kanban o Scrumban.

Pero esto será objeto de otro artículo.

 

¿Quieres saber más?

Puedes profundizar en las prácticas de Kanban con nuestro curso de Kanban.