¿Scrum o Kanban?

En estos más de dos años trabajando en desarrollo de soluciones de I+D hemos probado diferentes metodologías, algunas las hemos desechado y otras las hemos adaptado, siempre con el objetivo de ser más productivos.

De las metodologías que conocíamos y tras un estudio muy ligero, descartamos las siguientes:

• Dynamic Systems Development Method (DSDM): Metodología ágil más veterana y la que más se aproxima a los métodos tradicionales, su implantación incluso permitiría alcanzar un nivel 2 de madurez según CMMI.

Descartada por veterana, ¡Hacemos innovación!

• Extreme Programming (XP): La metodología ágil más radical y popular. XP se centra en el ciclo de vida del desarrollo de software.

Muy centrada en desarrollo, necesitábamos más gestión.

• Agile Modeling: Metodología para el modelado y la generación de documentación que se encuentra alineado con los principios del desarrollo ágil y que puede ser utilizado como substituto del UML estándar.

Documentación??? No gracias, solo la justa.

• Feature Driven Development (FCC): Metodología de desarrollo de software orientada a la generación de valor para el cliente.

Excelente metodología, pero no teníamos clientes con los que validar.

Llegados a este punto… ¿Scrum o Kanban? Pues comenzamos con Scrum.

Scrum es una metodología muy conocida con lo que fue fácil comenzar. Teníamos que empezar a trabajar en iteraciones, crear equipos multifuncionales, nombrar un Product Owner y un Scrum Master, así como, fijar reuniones de planificación, decidir la duración de nuestros Sprints, juntarnos todos los días para hacer actualizaciones de estado y crear demos para el final de cada Sprint. Los beneficios de la metodología Scrum son indudables. Pero a los pocos Sprints nos dimos cuenta de que no nos funcionaba, o al menos no como nosotros necesitábamos.

• Trabajo en equipo: éramos muy pocos (4) y realmente cada miembro del equipo tenía sus propias tareas (desarrollo, interfaz, sistemas, pruebas, etc.) y se encargaba de decidir el alcance de su propio módulo. No necesitábamos un Product Owner.
• Sprints: No teníamos entregas, si acaso demos y cada miembro del equipo sabía autogestionarse. No necesitábamos un Scrum Master.
• Dailys: Cada miembro del equipo tenía su propia tarea, con lo que la coordinación entre miembros del equipo no era crítica y además gran parte del grupo tele-trabajaba. No necesitábamos vernos todos los días.

¡Necesitábamos una metodología que se adaptara mejor a lo que hacemos!!

Migramos a Kanban

¿Qué es Kanban? ¿en qué consiste? Hay dos objetivos que rigen este método productivo: por un lado, lograr un producto de calidad, al obligar a cada fase del proyecto a finalizar su tarea correctamente, y acabar con el caos, saturación o cuello de botella que puede darse en una fase del proyecto en condiciones normales en las que prima la rapidez por encima de la calidad del producto.

Cuatro son las reglas o principios básicos de Kanban para conseguir estos propósitos:

1. Empieza con lo que haces ahora: Kanban es un método de producción, no un sistema que te dice cómo hacer tu trabajo.
2. Acepta el cambio: todos los miembros del equipo tienen que estar dispuestos a aplicar cambios constantes para mejorar sus rutinas de trabajo, siempre y cuando se haga poco a poco y con sentido común.
3. Respeta el proceso en curso, los roles y responsabilidades de cada uno: es imprescindible que cada miembro del equipo sepa qué tiene que hacer y cuáles son sus funciones. Para que el método Kanban funcione esto tiene que estar claro. No se trata de que todos hagan todo, sino que cada cual sepa qué hacer en el momento adecuado.
4. Liderazgo en todos los niveles: Tener iniciativa y gestionar correctamente tu tarea es otro elemento básico a tener en cuenta.

Y cinco son los elementos que deben darse en un sistema productivo que aplique bien el método Kanban.

Panel Kanban del proyecto Play

1. Visualizar el flujo de trabajo: Parece algo básico pero no siempre vemos realmente las fases por las que pasa un proyecto ni qué personas trabajan en qué. El método Kanban recomienda usar un panel con tarjetas que definan cada tarea dividiéndola en columnas que indican cada fase del proyecto.
2. Limitar el trabajo en curso: Hacer muchas cosas pero dejarlas todas a medias no sirve de nada. Si empiezas algo terminalo antes de empezar otra cosa, ése es un principio básico del método Kanban.
3. Gestión del flujo: Además de visualizar el flujo de trabajo hay que controlar su funcionamiento, ver en todo momento si las piezas están funcionando o si alguien tiene problemas y solucionarlos.
4. Dejar claras las reglas del proceso: Para aplicar bien un método hay que entenderlo.
5. Mejora en equipo: Uno de los pilares del método Kanban es la mejora constante. En este sentido, la mejora debe ser acordada en equipo, aportando la experiencia de todos los miembros del equipo.

En resumen, no hay una metodología mejor que otra, se trata de encontrar la metodología que mejor se adapta a tu proyecto y a tu equipo.

Autor: Luis Roldán