Muchas veces, a la hora de empezar a trabajar con un equipo, tenemos que decidir si usar Scrum o Kanban. Ya sea el framework Scrum o el método Kanban, ninguno te obliga a cambiar la organización, sin embargo, la organización sí puede marcar esta decisión por la implicación que cada uno de ellos tiene. En este artículo hablábamos de tomar esta decisión en base a lo que queramos mejorar
Implantando Scrum
Si queremos hacer Scrum, hay una cosa que tenemos que tener en cuenta, el cambio es más fuerte. Scrum, lo primero que enseña es que necesitamos una serie de elementos: roles, artefactos y eventos. Los artefactos son bastante fáciles de conseguir, ya sea consiguiendo licencias de algún software como Jira o usando tableros físicos que nos podrían valer desde una velleda blanca hasta un trozo de una ventana. Por otro lado, aplicar los eventos es sencillo, al menos en una versión primigenia. Puede que conseguir que vengan stakeholders a la Sprint Review sea difícil, pero desde luego es invitarles a una reunión más, puede ser sencillo.
El problema principal suele aparecer con los roles: ¿De dónde sacamos un Scrum Master, un Product Owner o un Development Team? El Scrum Master es complicado porque hay un cacao tremendo sobre sus funciones. Por ejemplo, muy pocos saben que parte de sus funciones en la transformación de la organización. El Product Owner es una figura compleja, no existe en las organizaciones y su manera de pensar en valor y no tanto en % de avance ya indica un cambio brutal. Otro de los cambios fuertes es que, antes teníamos un Jefe de Proyectos responsable del equipo, pero ahora tenemos dos figuras ¿Está justificado el incremento del coste? Y por otro lado el Development Team, que es mucho más que un grupo de desarrolladores; Hablamos de personas sin etiquetas, autoorganizados y con responsabilidad compartida: ¡esto es muy difícil!
Los roles atacan directamente a las personas, su status en la organización y sus responsabilidades. Todo esto complica mucho la implantación de Scrum y, por eso, muchas veces fallamos.
Implantando método Kanban
Con Kanban la cosa es diferente, y quizás sea el gran argumento a favor: empieza por donde estés y empieza a mejorar. Este principio del método Kanban es clave, trata de ser menos disruptivo en su incorporación a la organización. Para ello, cuando construímos nuestro tablero, tratamos de reflejar la situación actual, no un idílico. Kanban encima no prescribe roles, y aunque sí eventos, no te dice con qué cadencia hacerlos.
Kanban no entra de manera tan fuerte, trata de que visualices tu trabajo para encontrar puntos de mejora: retrasos, cuellos de botella, dependencias, exceso de trabajo del sistema… Para apoyarnos y conseguir esto, el método Kanban propone muchas métricas que nos permitan tener datos de cara a descubrir la calidad del servicio que prestamos. Nuestro objetivo, ser capaces de fluir como un río evitando las piedras.
También, en Scrum parece que muchas veces (y a mí me ha pasado) parece que es más importante seguir el framework que entregar valor. Sin embargo, el método Kanban lo tiene muy claro: propósito para el servicio. ¿Qué tal es el servicio que prestamos? ¿Somos capaces de dar un buen servicio? ¿Cumplimos las expectativas de los clientes?
La contrapartida de todo esto es que, al ser menos disruptivo, puede que no cambie nada. Al no provocar tanta disrupción, en ciertos contextos, acabaremos haciendo lo mismo con post its y no siendo capaces de mejorar. ¡No todo iba a ser bonito!
Conclusiones
A medida que adquiero experiencia en Scrum y Kanban, me doy cuenta de que hablen de cosas muy parecidas. Parece que personas diferentes han llegado a la misma conclusión a través de sus experiencias en entornos completamentes alejados. Aún así, a la hora de implantarlo, es probable que Kanban sea menos disruptivo. También es verdad, que en ciertos contextos tenemos que ser disruptivos, tenemos que dar un “golpe encima de la mesa” si queremos provocar un cambio. Así que, no pienses en que uno es mejor que otro, piensa que son dos herramientas y qué es lo que tienes delante, a partir de ahí, decidid que puede ayudaros más.
Tabla de contenido
Entradas relacionadas
¿Es la agilidad para todos?5 (1)
Comentarios recientes