Operación Galgo. El primer Sprint.

El lunes 13 de Diciembre de 2010 fue un día importante para Runroom. Por fin, tras meses de investigación y planificación, arrancó el primer sprint de nuestra Nueva Era Ágil. :)

Para ser la primera Reunión de Planificación de Sprint, la verdad es que fue bastante más efectiva y controlada respecto al timebox de lo que esperaba. El timeboxing consiste en delimitar el tiempo de reunión de forma estrictamente acotada. En nuestro caso, por ser la primera planificación de sprint, fuimos un poco más flexibles con la duración de la misma y finalmente dedicamos poco más de 3 horas, durante las cuales todo el mundo aguantó muy bien el nivel de concentración.

El equipo estimó una tras otra, mediante planning poker, las historias de la pila de producto. Cuando el número de puntos de historia rebasó el límite estimado para este sprint, se excluyeron del mismo algunas tareas, postergándolas para próximos sprints.

Como invitado, asistió a la reunión Xavier Vergés, quien pese a acumular una dilatada experiencia en el agilismo en empresas como IBM, reconoció sentirse sorprendido por la dificultad de gestión de la producción del estudio.

La heterogeneidad de los proyectos y los perfiles que en ellos participan, hacen que el nivel de complejidad sea muy elevado, con constantes cambios de rumbo e imprevistos, fuertes dependencias externas, indefinición de requisitos, y un largo etcétera por el cual es prácticamente imposible utilizar Scrum puro.

En nuestro caso, tras evaluar en profundidad tanto Scrum como Kanban, y gracias también a la excelente presentación de Ángel Medinilla en el Agile Open Spain 2010 sobre Scrumban, decidimos finalmente implementar esta metodología en el estudio.

Scrumban, por su mayor versatilidad, está ganando muchos adeptos en entornos de producción con realidades similares a la nuestra.

Sintetizando bastante, Scrumban consiste en aunar un panel Scrum y otro panel Kanban, utilizando el primero para aquellas historias más planificables y el segundo para bugs, tareas imprevistas o de mantenimiento.

Probablemente una de las características más potentes de Scrumban sean las métricas. Tener la capacidad de medir el impacto que supone el bugfixing en el equipo, o aquellas tareas que no estaban contempladas en el panel de Scrum, permite afinar mucho mejor cuál es la “velocidad de crucero” del equipo.

En algún post futuro intentaré explicar con más detalle cómo lo haremos nosotros.

[box icon=paper-warning]Lecturas MUY recomendadas, y en este orden:

  1. Scrum y XP desde las trincheras
  2. Scrum VS Kanban

[/box]