Ahora que hemos hecho un repasito a las metodologías Agile y hemos conocido un poco más a fondo dos de ellas, Scrum y Kanban, toca ampliar la imagen de ese tablero imaginario que hemos creado y poner una frente a otra. Face to face, si lo prefieres in English.
Pero empecemos por un pequeño resumen, no vaya a ser que nos dispersemos. Scrum y Kanban son dos de las metodologías Agile adoptadas mayoritariamente por empresas especializadas en desarrollo de software, agencias de marketing y de diseño, start-ups y un largo etcétera. Su punto fuerte es que nos ayudan a gestionar la creación y entrega de productos y servicios. Y aunque normalmente se suelen utilizar de manera excluyente, ambas tienen ventajas que pueden completar todo el proceso de trabajo.
Pero para verlo de una manera más clara, vamos a eludir por una vez ese dicho de que las comparaciones son odiosas y vamos a enfrentarlas en un ring. Tranquis, este será un combate pacífico, no va a doler. Que aquí venimos a aprender, no a pelear.
Así pues, ¿Scrum o Kanban? ¿Con cuál te quedarías?
Recuérdame qué es Kanban, por favor
¡Ay, esa memoria! El método Kanban tiene como objetivo poder controlar cómo se van completando las tareas. Toyota fue la pionera en su uso, donde se aplicaba a los procesos de fabricación de coches, y, con el tiempo, también pasó a usarse por desarrolladores de software.
Kanban tiene un método de trabajo basado en el desarrollo y entrega de forma continua (pin, pan, pin, pan… un no parar, Mari Carmen), donde se abordan un número pequeño de tareas de manera fluida y simultánea. Emplea una herramienta de planificación visual o tablero Kanban donde se muestra cada proyecto en una tarjeta (y quien dice tarjeta dice LetsGo) y se va moviendo por columnas que representan las diferentes etapas hasta la finalización. Si un equipo tiene un flujo de trabajo continuo, este es el mejor método, ya que permite una gestión mucho más sencilla.
Y ya que estamos, repasemos qué es Scrum
¡Claro que sí, cari! Lo que tú necesites.
Scrum también es una metodología Agile orientada a mejorar el trabajo colaborativo entre equipos (hasta aquí, nada nuevo). El objetivo es conseguir los mejores resultados a la hora de desarrollar proyectos. Suele ser utilizado por equipos de desarrollo, aunque también puede aplicarse a otros departamentos que requieran de trabajo en equipo. Vamos, que lo uses como quieras y re-quieras (guiño, guiño; codazo, codazo).
Característico de este método es el sprint (no, no estamos hablando de carreritas de atletismo ahora, céntrate), donde cada parte del proyecto se planifica de antemano. Y una vez finalizada esa fase, se revisa el trabajo efectuado y validado previamente. Mediante este análisis, el equipo puede saber en qué momento algo no ha funcionado bien, qué recursos son necesarios y planificar los siguientes sprints (¿otra vez? ¡Que te olvides del atletismo!) de forma efectiva.
Hecho el repasito rápido, vamos al turrón: ¿cuáles son las diferencias principales entre ambos métodos?
- Scrum está pensado para maximizar el valor en el desarrollo de un producto. Sin embargo, Kanban permite optimizar el flujo de trabajo.
- Podemos encontrar roles en Scrum, cosa que no sucede igual en Kanban.
- En Scrum se utilizan los sprints (interacción de tiempo. ¿Qué hemos dicho ya de las carreritas atléticas), mientras que en Kanban el trabajo es continuo.
- En el método Scrum no se realizan cambios en el proyecto durante su desarrollo, sino al final. Sin embargo, en Kanban se pueden hacer cambios en todo momento.
- Con Scrum se hace evidente un sprint blacklog, en el que un product owner prioriza las tareas que deben realizarse (toma anglicismos; para que veas que sabemos inglés); mientras que en Kanban, es el cliente el que indica cuáles son esas tareas y no existe la priorización.
- Los sprint en Scrum han de contener una lista de tareas a realizar en un periodo de tiempo, pero en Kanban el flujo de trabajo es continuo y cada petición del cliente es una nueva tarjeta en el tablero.
- El tablero en Scrum se renueva cada vez que se pone en marcha un sprint, aunque en Kanban no tienen inicio ni fin (y sin haberlo deseado, nos ha salido un pareado).
- Y ya que estamos con los tableros, en Scrum se realiza el seguimiento de trabajo mientras se avanza por las etapas, y se indica qué tareas se hacen en todo momento. Pero en el tablero Kanban, las columnas se pueden flexibilizar y no tiene por qué señalar el estado del trabajo (indica el trabajo en sí).
- Con Scrum se han de hacer reuniones diarias para conocer continuamente el estado del desarrollo y tener una idea global de las tareas terminadas y pendientes dentro del equipo que lo lleva a cabo (más reuniones, Pulpi, ¿en serio?).
- Por el contrario, en Kanban no existen dichas reuniones, porque se sabe qué hay que hacer en todo momento.
- Y para acabar, los equipos de trabajo pueden ser distintos. Con el método Scrum se exige que sean multidisciplinares, pero en Kanban los equipos pueden estar compuestos por especialistas en una única materia.
¿Existe el Scrumban?
Yes, oui, sí (en tres idiomas, para que quede más clarito).
En este caso, hablaríamos de una metodología Agile que es un híbrido entre Kanban y Scrum. Obviamente, su nombre procede de la combinación de ambos métodos. El Scrumban se creó como solución para que los equipos hicieran adecuadamente una transición de Scrum a Kanban y pudieran emplear lo mejor de cada metodología. Después de todo, se busca optimizar los recursos para crear valor que interese al cliente.
Scrumban aúna la estructura de Scrum con los métodos de flujo de trabajo y visualización de Kanban. Hace que los equipos consigan la agilidad de Scrum y la simplicidad que ofrece Kanban sin tener que actualizar los roles; y, además, es más cómodo de adoptar. Un Frankenstein monísimo y superpráctico, oiga.
Con Scrumban, el trabajo en equipo se lleva a cabo en pequeños pasos y se controla con la ayuda de un tablero visual. Las reuniones de planificación bajo demanda tienen lugar cuando conviene saber qué historias de usuarios y tareas se van a completar en el próximo paso o iteración.
Además, para mantener iteraciones reducidas, se emplea el método de límite de trabajo en progreso (WIP o Work in Progress, por sus siglas en inglés). Si WIP cae por debajo de un nivel determinado (los dioses no lo quieran, Mari), se crea un activador de planificación bajo demanda para que el equipo conozca cuándo planificar después.
A poco observador que se sea, es fácil comprobar que existen evidentes diferencias entre Scrum y Kanban, aunque no son realmente significativas si nos paramos a pensar. De ahí que pueda existir ese híbrido llamado Scrumban, que es la criatura nacida de ambas metodologías. Bondades del mestizaje, ya se sabe.
Si el objetivo de Kanban y Scrum es lograr un desarrollo óptimo del producto, no pueden ser metodologías excluyentes; normal que haya nacido el amor entre ellas. De este modo, si un equipo está cómodo con la metodología Scrum, se puede usar un tablero Kanban para conseguir mantener al equipo de trabajo bien organizado. Y todos felices y contentos.
Porque aquí lo importante es tener una forma de trabajo y una herramienta que ayude en el desarrollo del proyecto que se tenga entre manos, independientemente del método empleado. O lo que es lo mismo, disponer de un sistema de gestión flexible. Ahora te toca a ti decidir con cuál te quedas.
Ahora que ya conoces en qué consiste esta metodología de trabajo, no te vuelvas loco pensando qué juego de LetsGo necesitas para ponerla en práctica. Somos como los mosqueteros: un juego de LetsGo Agile para todas y todas para uno. Vamos, que puedes utilizar todos los productos LetsGo para poner en práctica cualquier sistema de trabajo. Así de versátiles somos, ya ves.
