Aplicando Scrum

Como bien dice Alan Cyment en su sitio web, al tomar la certificación de Scrum Master “la travesía del alumno recién comienza”.

El curso de Certified Scrum Master se encarga de hacernos entender la esencia y el espíritu de Scrum, y porqué sirve o no, según el caso, depende. Después sigue una etapa de irse zambulliendo en Scrum. Para esto, nada mejor que leer, estudiar, participar en foros, y obviamente, aplicar Scrum.

Como parte de este camino, se empiezan a investigar nuevas fuentes de lectura, sitios relacionados, etc. A continuación les dejo algunos enlaces que he empezado a visitar seguido, a medida que vaya encontrando más iré ampliando.

Enlaces recomendados:

• Comunidad Latinoamericana de Metodologías Ágiles.

Blogs sobre Scrum y Agile:

En inglés:

• Jeff Sutherland, uno de los inventores de Scrum junto a Ken Schwaber.
• Visual Management Blog, espacio de discusión de ideas y ejemplos de Gestión Visual aplicada a equipos ágiles y gestión ágil de proyectos.
• Implementing Scrum, su nombre lo dice, el autor es Coach (Certified Scrum Practitioner), además publica un conocido cómic con personajes animales que implementan Scrum:
  

  El cerdo y la gallina

En español:

• Café Bar Ágil – Llegué a este blog a través de la lista de correo de foro-agiles. El autor es Martín Alaimo, miembro de la comunidad Ágil Latinoamericana, y el objetivo de su blog es prácticamente el mismo que este.
• Planeta Scrum: El agregador de contenidos en castellano sobre Agile y Scrum. Hay muchos blogs que leía, así que me ahorro ponerlos a mano uno a uno.

El pasado viernes tuvimos la primera reflexión o retrospectiva de Sprint. Por lo menos la primera “formal”, ya que el viernes anterior faltó el Scrum Master (ver entrada anterior para leer más sobre como vamos implementando Scrum ). No he leído de técnicas específicas para la reflexión, así que me basé en la teoría, y debatimos los problemas que habíamos tenido durante el proceso de trabajo.

Este viernes marcaba el final del primer Sprint. Los problemas que saltaron y que se plantearon durante la reunión fueron los siguientes:

• Subestimamos o sobreestimamos tareas.
• No granulamos lo suficiente como para hacer estimaciones más precisas.
• No detectamos falta de documentación en tiempo lo que puede atrasar un poco el trabajo.
• Tuvimos un deploy desordenado.

Pizarrón Primer Planning

Como conclusión llegamos a una serie de implementaciones que pueden ayudar a reducir el impacto de los problemas encontrados:

• Análisis inicial más extenso: extender la duración de la reunión de planning, para entrar más en detalles de análisis de las tareas a realizar, para poder estimar mejor. Esto también permite detectar faltas de documentación sobre el proceso a trabajar.
• Formalizar deploy, con la posibilidad de implementar un servidor de Integración Continua para el proyecto.

El lunes de esta semana ya arrancamos dedicándole un poco más de tiempo. Además tomamos en cuenta implementaciones que traían mucha documentación nueva. Para estas, se ingresó como tarea el análisis y posterior diseño de lo escrito en la documentación, y el martes se hizo un nuevo sub-planning para estas tareas específicamente.

Se notó una diferencia en densidad de análisis respecto al anterior el lunes:

Pizarrón Segundo Planning

El martes se agregaron muchas tareas más seguidas del sub planning. Todavía tenemos pendiente la implementación del Task Board en reemplazo del pizarrón.

Mientras vamos agarrándole el ritmo a Scrum, vamos implementando algunas de las herramientas recomendadas. Entre ellas el Daily Meeting o Daily Scrum, el Planning de principio de Sprint, el review y la reflexión.

Lo que no hemos implementado completamente todavía, es el Task Board. En nuestra primer implementación fallida de Scrum hace unos meses lo habíamos implementado. Usamos un espejo grande en la parte de desarrollo, dividimos con cinta aisladora en columnas, y pegábamos los Post-It ahí. Algunos errores que cometimos:

• No incluir una columna con el Product Backlog. Directamente pegábamos las tareas en “To-Do”. Ahora creo que sería más eficiente tenerla, e ir desprendiendo tareas de ahí.
• No definir el concepto de “tarea lista”. Incluímos una columna de tareas “para testing”, que debían pasar esa aprobación para quedar en “terminadas”. Esto se transformaba en un cuello de botella… nadie quiere testear.
• El pasaje de tarjetas entre columnas se hacía en cualquier momento del día. Esto tiene la desventaja que no todos están atentos, por lo que se pierde en parte el compromiso de definir una tarea como “lista” frente a los compañeros de equipo, y la transparencia, ya que no todos se enteran de los cambios al momento de realizarlos. Por eso es más efectivo, a mi parecer, hacer estos movimientos únicamente en el Daily Scrum.

Todo esto fueron errores que vengo viendo ahora, que en mi opinión son errores, pero pueden resultar efectivos en otro equipo distinto de trabajo, depende.

Hoy en día venimos usando el pizarrón. Los lunes de mañana hacemos el planning anotando lo que hay pendiente en el backlog. De ahí se desprenden tareas y vamos acotando qué partes del backlog entran al Sprint, y que seguirán incluyéndose en siguientes Sprints hasta terminar ese tema.

Task Board Pizarrón

Estimamos por cada uno la cantidad de tareas que se asigna, y el tiempo que le va a llevar. Para eso tenemos el calendario de la semana en columnas, e incluimos un título de la tarea y el nombre del programador el día en que estima que la tarea estará terminada. Algo que aprendimos que puede resultar útil también es incluir la hora aproximada de terminación de la tarea.

En los Daily Scrum revisamos vemos cómo va progresando cada uno con las 3 preguntas. Cuando una tarea debía estar pronta y se atrasó, escribimos un punto rojo. Si se termina en tiempo, se escribe un punto verde. En caso de haber sobrestimado la tarea, y terminarla antes, se agrega al punto verde y un “+n” siendo n la cantidad de días a favor.

Por ahora es lo que nos viene sirviendo, pero probablemente re implementemos el task board con los post it a corto plazo. Tampoco estamos llevando por el momento gráficas de burn down, pero posiblemente lo hagamos también.