MANUAL TE GP AGILES

MANUAL GESTIÓN DE PROYECTOS ÁGILES

comprometido a cumplir el sprint y tenemos al equipo 100% dedicado a ello pero no podemos decir que no a nuestro cliente y su concurso.

En general en Scrum vamos a tener problemas con replanificaciones necesarias a mitad de sprint, mientras que en Kanban estaríamos trabajando con un tablero y unas clases de servicio que se adaptarían a esta situación sin excesivo problema, ya que nada nos impide poner las reparaciones en marcha en cuanto tengamos capacidad en el sistema eso si, a costa de replanificar las tareas que estuvieran en nuestro “pendiente”. Por otro lado, cuando podemos cerrar el foco y trabajar sin interrupción en un proyecto (o varios) sin tener que dar soporte urgente ni atender a “expedites”, la limitación temporal de Scrum crea un pulso muy fuerte que insta al equipo a trabajar de manera ágil y muy alineada lo que hace que la planificación de un proyecto en base a Sprints sea más sencilla, y, llegado el caso, más sencilla de negociar con un cliente, desde un punto de vista contractual. En mi empresa, empezamos trabajando con Scrum hace cosa de un año pero dada la naturaleza cambiante y poco predecible del trabajo en el mundo publicitario éramos incapaces de trabajar con sprints de manera correcta. Las replanificaciones son constantes, los proyectos muchas veces llegaban y se entregaban en mitad de una Sprint impidiendo además la finalización del Sprint Backlog. Llegamos a trabajar con distintos tableros de Scrum, con distintos plazos de sprints y con el mismo equipo... un lío. Por el contrario en el tiempo que llevamos trabajando con Kanban, tenemos una sensación mucho mayor de control y orden. No hay verdades absolutas, no es mejor Kanban o Scrum o Scrumban, es mejor uno concreto para un equipo y contexto específico. Conozcamos las herramientas y usemos la más adecuada.



Lo mejor de cada casa

Vamos a ver cómo podemos utilizar Scrumban para intentar obtener los beneficios de ambas metodologías aplicando un método que ya conocemos. Scrumban es una mezcla de ambas metodologías pero esta mezcla no es exacta, Scrumban requiere de una adaptación aplicada a nuestro contexto y a nuestro equipo. Para realizar esta adaptación nos podemos valer de un método que ya conocemos: La gestión evolutiva del cambio con Kanban.

Para mí es más sencillo ver Scrumban como un scrum potenciado con los conceptos de flujo y límites del WIP: apliquemos Kanban a nuestro Scrum.

240

European Open Business School