Contacto +34 93 737 62 70
           
Contacto +34 93 737 62 70
Metodología activa de aprendizaje del método Kanban

Tiempo medio de lectura: 6 minutos.

Este artículo te da a conocer las diferencias entre Scrum y Kanban, permitiéndote comprender los factores que hay que considerar para escoger entre una metodología ágil u otra.

También sugiere que esa disyuntiva puede ser innecesaria al poderlos aplicar conjuntamente. 

Cursos relacionados

FechaCiudadCurso
26/10RemotoCurso de Fundamentos de Kanban

Artículos relacionados

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 elegir aquella 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 está inicialmente orientado a equipos o conjuntos  servicios. Pero como un proyecto es 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 prefiere un único equipo -para más de un equipo ver otros métodos como Nexus o LeSS- con el personal 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 utilizar sin dificultad equipos diferentes -no un único equipo-, con personal dedicado parcialmente así como recursos compartidos. Prefiere equipos polivalentes pero no tiene ningún problema en utilizar equipos compuestos por especialistas en un único dominio. Y prefiere la autoorganización pero tiene claro que seguramente habrán  dependencias jerárquicas que pueden suponer un alargamiento de los plazos.

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

En Kanban la cadencia del trabajo es continua. Las reuniones pueden tener una misma periodicidad fija (por ejemplo quincenal) o cada evento puede tener una periodicidad fija diferente (p. ej. La reposición (priorización del próximo trabajo), semanal; las revisiones, mensuales, etc.). E incluso los eventos pueden tener periodicidades que no sean fijas se realicen según necesidades (p. ej. Reposición cuando queden menos de 5 peticiones en la columna de los próximos ítems a realizar).

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 por su parte permite cambios en cualquier momento para adaptarse a la aparición de nuevas prioridades.

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 trabajo 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.


Comparación entre Scrum y Kanban

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.

¡Si has llegado hasta aquí, comparte este artículo!

Deja un comentario

¿Podemos ofrecerte más información?

Newsletter mensual

Cada mes enviamos una newsletter a más de 1.000 personas con contenido interesante que hemos encontrado en Internet, artículos nuestros y nuestras novedades. Queremos ofrecer contenido de calidad y no saturarte con muchos correos.

Formulario de contacto

Si crees que podemos ayudarte con alguna duda o necesidad de soporte, no dudes en contactar con nosotros. Estaremos encantados de ayudar.

Ir arriba

Newsletter mensual

Un boletín mensual. Respetamos tu privacidad.