Una situación muy habitual dentro de las compañías es el uso de una metodología que permita organizarse de manera ágil. Aquí es donde aparecen Scrum y Kanban, las metodologías que, de algún modo u otro, terminan estando entre las finalistas. En este post verás las diferencias principales entre ambas metodologías. Scrum vs Kanban.
¿Cuáles son sus roles y responsabilidades?¿Scrum vs Kanban?
En Kanban existe el Delivery Lead, quién es el encargado de asegurarse que el equipo sigue la metodología Kanban de manera correcta y continua. Realmente es un rol que no debería existir dentro de los equipos más maduros que utilizan Kanban, pero en líneas generales es un rol muy importante que ayuda a que la aplicación de esta metodología ágil sea un éxito.
En Scrum existen 3 roles. El Product Owner, quién es el encargado de priorizar el Product Backlog y de maximizar el impacto del equipo de Desarrollo. Luego está el Scrum Master, el encargado de evangelizar el uso de la metodología Scrum dentro de una organización. Y por último el Equipo de Desarrollo, conformado por personas que se encargan de construir el producto.
Más allá de que en Kanban existan menos roles, y eso parezca positivo por una cuestión de «menos recursos», la realidad es que los roles no deben ser un factor determinante en la elección de una metodología u otra. En Scrum los roles pueden ser compartidos, y más que los roles es la mentalidad detrás de la metodología.
¿Qué diferencias hay en los plazos de entrega?
Scrum define plazos de entrega, o simplemente entregables, dentro de los Sprints que se definan en la metodología (lo más normal es que sean de 2 semanas). Al final de cada Sprint, se realiza una Demo a los Stakeholders y se decide si lo que se ha acabado va a producción o no (esto lo decide el Product Owner). Luego de la Retrospectiva, comienza el siguiente Sprint.
Esto quiere decir que cada final de Sprint existen «deadlines» que deberíamos cumplir.
Sin embargo, Kanban apuestas por el «Continuous delivery», es decir, que el equipo está continuamente construyendo el producto y cogiendo tareas del Board de Kanban sin necesidad de ceremonias que sí existen en Scrum.
Esto puede sonar muy positivo para Kanban, ya que existe ese desarrollo continuo, y menos ceremonias, que terminan resultando en más tiempo invertido en reuniones. Sin embargo, esto suena muy bonito pero suele funcionar muy bien en equipos más maduros, en caso contrario aparecerán gaps o reducción de la velocidad por una reducción de la inspección. Esta es la principal razón por la que existe un rol de Delivery Lead en Kanban.
¿Cómo miden el rendimiento del equipo?
En Scrum, el rendimiento del equipo se suele medir en términos de la velocidad del mismo durante cada Sprint, básicamente los puntos quemados en cada iteración (si estimamos en puntos de historia, también pueden ser horas).
Una reducción de la velocidad puede ser fácilmente detectable, y se pueden hacer sesiones para intentar mejorar los procesos.
En Kanban no existe tales ceremonias, por lo que la medición del rendimiento viene en reuniones semanales / quincenales con todo el equipo para alineamiento y hacer una puesta en común del estado del proyecto.
Scrum está más enfocado a la inspección en cada Sprint, para asegurar un ritmo de entrega de valor controlado. Kanban suele controlar el rendimiento cuando se finaliza un hito, o periódicamente para hacer un seguimiento del estado del producto.
En líneas generales, la elección de una metodología en base a la medición del rendimiento dependerá del estado de madurez del equipo. Scrum suele ser la elección más común, y a medida de que el equipo madura se va migrando a Kanban.
Sobre transparencia, inspección y adaptación
Aquí ambas metodologías comparten lo mismo, puesto que la transparencia, inspección y adaptación son valores culturales que van más allá de la metodología ágil que se elija. Ninguna funcionará si no se mantienen estos pilares fundamentales.
En Scrum, sin embargo, las ceremonias y artefactos aseguran estos pilares, por lo que si el cambio no solo es en la metodología sino también en la parte cultura, te recomendamos que comiences por aquí.
Kanban funciona mucho mejor en equipos maduros, que tienen estos pilares ya consolidados.
Por ejemplo, Scrum no permite cambios en el Sprint Backlog durante un Sprint (dentro de un Sprint no habría que adaptarse), pero la adaptabilidad es uno de sus pilares. Sin embargo en Kanban el equipo se adapta muy rápidamente ya que simplemente poniendo la nueva card más prioritaria en la parte superior del Board hace que el equipo tenga que adaptarse y poner foco a esa nueva tarea cuando acaben lo que están haciendo.
Otro ejemplo: En Scrum la transparencia e inspección se practica mucho en las Daily meetings, en 15 minutos todo el equipo ha contado lo que ha hecho ayer, lo que hará hoy y cualquier bloqueo que tengan. Sin embargo en Kanban las Daily meetings como tal no existen, y la transparencia aparece en el Board de Kanban, donde se ve en qué está trabajando cada miembro del equipo.
Al final, los pilares son los mismos para ambas metodologías ágiles, pero cada una de ellas lo usa de una manera distinta. Lo importante es que sepas que si no tienes ese cambio cultural, es igual la metodología que elijas, no funcionará.
¿En qué equipos se adapta mejor cada metodología?
Scrum vs Kanban. Aquí la opción es mucho más clara.
Si tu equipo está implementando por primera vez una metodología ágil, o tienes muchos miembros del equipo sin experiencia previa, nuestra recomendación es que empieces con Scrum. Los roles, ceremonias y artefactos tan bien definidos y articulados ayudarán a construir esos primeros pasos dentro de una metodología ágil.
Para equipos más maduros, o con un nivel de seniority mucho más alto, Kanban es la mejor opción. Solo equipos muy maduros cogen la responsabilidad de las tareas, de refinarlas, de desarrollarlas y de presentarlas sin necesidad de ceremonias pre-establecidas. En este caso es muy fácil que aparezcan problemas en la gestión del board, lo que repercute en la transparencia y despierta la necesidad de inspección en el equipo. La madurez es un aspecto clave para elegir Kanban, ya que parece la opción «más sencilla de implementar», pero requiere un nivel de ownership muy alto.
Conclusiones Scrum vs Kanban
La elección entre una metodología u otra depende mucho del estado de tu empresa. Si recién estáis empezando, lo ideal es Scrum (aunque esto pueda ser subjetivo). Kanban suele funcionar bien en equipos más maduros, ya que su implementación es sencilla pero su continuidad con el paso del tiempo es mucho más difícil de sostener, ya que se necesita una gran dosis de responsabilidad y madurez por parte del equipo.
Cualquier decisión que tomes deberá ir acompañada por un cambio o madurez cultura, ya que sin transparencia, inspección y adaptabilidad ninguna metodología ágil funcionará.