Aplicando Scrum

Parte del espíritu de Scrum es la colaboración entre los miembros que asumen cada rol de la implementación. Así que es lógico que esto se cumpla. Pero además de esa “teoría” que nos dice Scrum es colaborativo, está bien compartir experiencias que dan valor de verdad a estas definiciones.

Trabajo colaborativo

Como comenté en una entrada anterior estoy trabajando en un nuevo equipo. El pasado lunes hubo una reunión general de todos los integrantes, donde pasamos a explicar varios temas y cambios en la forma de trabajar. Scrum implica un cambio tanto en la estructura y metodologías de trabajo, como en la forma de encarar el trabajo por parte de cada individuo.

En esta reunión, comentamos sobre algunas herramientas que usamos y vamos a integrar en nuestra metodología de trabajo: Subversion, Trac y Scrum. Subversion (además de ser mi sistema de control de versiones preferido) es el servidor que se viene usando para mantener los fuentes versionados. Trac es un sistema de gestión de tickets (bugs, arreglos, etc.) y un gestor de proyectos con integración con Subversion. Y Scrum, va a ser el framework que englobe todo el trabajo.

Comprobamos que el simple hecho de reunir a la gente, hacerla participar y contar apenas unos conceptos clave de la nueva forma de trabajo (roles, horizontalidad, participación, auto organización, etc) logró cambios en la interacción del equipo. En estos pocos días que han pasado desde el lunes, la comunicación entre todos los miembros del equipo ha sido mucho más fluída. Se escuchan conversaciones del proyecto entre varios miembros, todos participan. Y la colaboración ha sido un punto fuerte también. Hay más personas del equipo trabajando en equipo, pidiendo ayuda y ayudando.

Basado en esta experiencia, puedo afirmar con total seguridad:
Scrum fomenta la comunicación y colaboración de forma orgánica. Esto sin siquiera haber comenzado formalmente la implementación, sin task board, ni daily meetings. Solo un planning improvisado, y una introducción a algunos conceptos en una nueva forma de trabajo.

Acá les dejo un material que repartimos al equipo antes de la primer reunión de planificación de Sprint. El lunes comienza la reimplementación de Scrum. Es para tener una idea general del Sprint Planning, basado en apuntes e ideas obtenidas a lo largo de este tiempo:

Para cumplir con el criterio de Timeboxing, debe definirse una duración inicial para la reunión de planificación. Es importante que se cumpla con esta duración, y la reunión no profundice en temas que no son importantes al momento. El objetivo de esta reunión es obtener la planificación del Sprint.

Duración del Sprint

Mínimo 1 semana, máximo 1 mes.
Esto puede variar a medida que el equipo se adapte a Scrum, o de acuerdo a las entregas que quieran realizarse del producto.

Product Owner

Debe filtrar todos los intereses de jefes, directores, gerentes, de distintas áreas y con distintos intereses hacia el equipo. Para evitar el ruido, el Product Owner es el único que transmite las necesidades del producto al equipo, basado en el retorno de inversión.

Tiene que tener preparado para la reunión el backlog del producto: la lista de funcionalidades que hay que implementar. Durante la primera parte de la reunión, el P.O. explica el backlog.

El equipo

Una vez armado el backlog, el equipo debe seleccionar las funcionalidades con las que se va a comprometer a terminar en el Sprint. El objetivo es tener un producto potencialmente entregable al final del Sprint, y que la funcionalidad sea demostrable. Debe analizar y estimar qué se puede hacer, y despejar dudas sobre funcionalidad con el P.O..

Definiendo el Sprint

El Product Owner y el equipo deben definir juntos el trabajo a realizar en el Sprint. El P.O. es el responsable de elegir la prioridad, y el equipo de elegir cuánto trabajo va a poder terminar en esta etapa. De esta forma, se define el objetivo de cada Sprint. Su éxito será determinado al final del Sprint en una reunión de review. De esta manera, se arma un backlog para el Sprint.

Estimando el Sprint

Una vez definido el backlog del Sprint, cada tarea debe ser estimada, y dividida en partes que puedan ser medidas idealmente en 1 día o menos de trabajo. Cuanto más pequeño sea el alcance de cada tarea, más fácil de estimar.

Duke Trabajando

Hace ya 2 meses que cambié de trabajo.

Hasta ahora los posts relacionados a la implementación de Scrum en este blog habían sido siempre en la misma empresa. El cambio de trabajo debe ser uno de los momentos en que queda más evidente la utilidad de haber hecho este blog plasmando mis experiencias con Scrum.

Si bien no escribí tanto como me hubiera gustado desde mayo cuando empecé el blog, hay muchas cosas útiles que vi en su momento, que aprendí, que apliqué, que me pueden servir hoy en el nuevo trabajo. Links, recursos, artículos y demás. Si bien no ha sido tanto como esperaba, algo se ha ido guardando.

En este nuevo trabajo estamos por empezar una nueva implementación de Scrum. Por lo tanto, a partir de ahora, reimplemento Scrum.

Una de las ventajas es que trabajo con otro Scrum Master certificado. Ya han habido ideas de Scrum y agilidad en la empresa, pero aparentemente no se ha llegado a hacer una implementación completa.

Prometo en esta nueva instancia de implementación de Scrum, comentar más experiencias en el blog.