Tales from the Scrum: Anti-patrones de Sprint

Recordemos: el Sprint es la iteración en Scrum: puede durar una, dos semanas, o un mes. Eso se decide según el proyecto y el equipo. En los primeros tiempos de Scrum se elegía un mes, pero ahora se prefieren sprints más cortos: una de las razones es para responder a cambios más rápidos.

El Sprint se inicia con una reunión de Sprint Planning, donde se expone el estado actual del Product Backlog (la lista de requerimientos del producto que estamos armando), y se arma el Sprint Backlog (la lista de tareas que se eligen para ese Sprint). El Sprint termina con la reunión Sprint Review, donde se presenta el nuevo estado del producto. Cada día, el equipo se reúne, y realiza la reunión diaria de Scrum, para informar el estado y comprometerse a las tareas de ese día. El ScrumMaster va acompañando al equipo para que aplique Scrum de forma efectiva.

De vez en cuando, aparecen, aún equipo saludables, algunas actitudes y actividades que podemos denominar anti-patrones: no están alineadas con los principios de lo ágil y de Scrum. Veamos algunas:

- Tomar demasiadas tareas para el Sprint: el equipo, entusiasmado (o presionado), toma más tareas que las que son materialmente cumplibles. Un equipo maduro conoce su fuerza y capacidad, y sabe hasta dónde puede llegar en cada Sprint.

- No partir bien las tareas del Sprint: Relacionado con lo anterior. Una de las actividades de la Sprint Planning es enumerar las tareas que serían necesarias para avanzar con los items más prioritarios del Product Backlog (armado por el Product Owner). La lista de tareas tiene que estar bien armada (no olvidarse de ninguna). Luego se evalúa el tiempo y esfuerzo necesario para cada tarea. Y acá he visto muchas veces esto: el equipo no parte la tarea en subtareas. Si una tarea no se parte de esa manera, es más difícil evaluarla. Yo recomendaría partir cada tarea en subtareas que puedan evaluarse en tiempo de horas. Si una tarea es “armar los reportes contables”, no dejarlo así enunciada. Pasarla a la lista de subtareas, y evaluar una por una. Por ejemplo: una lista de esos reportes, y a su vez, dividir en programar el reporte, verificarlo, documentar en el manual de usuario, armar el script de instalación, e instalarlo en el servidor de pruebas. Si no se parten adecuadamente las tareas, no podemos evaluar bien el tiempo que emplearemos. No tiene que ser una partición definitiva: se puede ir refinando con el correr del Sprint. El llevar el detalle a subtareas de horas, que puedan realizarse en fracciones de días, tiene también otra ventaja: quedan disponibles para que se tomen en la reunión diaria: la tarea de cada miembro debería ser poder terminada en el mismo día. Sino, debería anunciar qué parte de la tarea toma, y a qué punto de avance se compromete a llegar en ese día.

- Una tarea para un miembro: cada día, debería cada miembro del equipo tomar una tarea, para seguir avanzando en el cumplimiento de lo que se comprometió para este Sprint. Pero puede pasar, que una tarea queda por siempre asignada a un miembro del equipo. No es la idea de Scrum: un miembro no toma esa tarea para él por todo el Sprint. La tarea es del equipo. Que haya un miembro del equipo más capacitado para llevarla a cabo, no implica que sólo él se encargue de la tarea. Debería por lo menos hacer “pair programming”, ir educando a alguien más en el equipo, para no caer en eso de “esta tarea es para Juan” y sólo para él.

- Entregar trabajo no terminado: Iba a poner “o terminado parcialmente”. Pero no debería existir ese concepto en un Sprint. La idea es entregar una tarea, bien terminada, bien hecha. Prefiero que un equipo tome una sola tarea, y la termine bien, a que encare cuatro tareas y finalmente, a cada una le falta algo para ser considerada realmente “hecha”. Muchas veces, el equipo piensa que de esta forma va avanzando: entregar 10 tareas, aunque no estén bien terminadas. Y piensa que así es mejor. Pero la experiencia muestra que el trabajo adicional de revisarlas y completarlas más adelante, no se puede soslayar. O si lo salteamos, habremos entregado producto sin una calidad y terminación adecuada. No hay que “patear para adelante” este tipo de cosas.

- No verificar el trabajo: En el trabajo de cada, se va cumpliendo con las tareas, pero no se verifican. Así, puede pasar que lo que un miembro consideró como terminado, en realidad le falta algún detalle. Hay que recordar que el trabajo debe ser entregado de forma tal, que tenga la menor cantidad de errores o problemas al usarlo. No es cuestión de “termino tal tarea, cualquier problema me lo van a informar en el próximo Sprint”. No es la idea. El espíritu es

- Tener un Sprint de “estabilización del producto”: Como las tareas se fueron entregando de forma no “totalmente hecha”, se elige un Sprint para “pulir” el producto, revisando lo entregado, para mejorarlo y corregir pequeños temas. De nuevo, no es la idea: no debería haber, en lo posible, este tipo de “estabilización”. En vez de haber entregado esas tareas de forma parcial, se deberían haber entregado menos tareas, pero bien terminadas. Como digo, el producto de cada Sprint debe venir “en paquete con moñito”: evitar la entrega parcial.

- No hacer “pair programming”: si bien Scrum no exige esto, he visto que es común que alguna disciplina ágil, como la programación de a pares, se saltea siempre. Ya sea porque el equipo es pequeño y hay muchas tareas, o por la razón que sea, todas las tareas se ejecutan individualmente. El trabajo de a pares facilita la terminación de la tarea, dos cabezas piensan más que una, hasta se verifica mejor el trabajo entregado, y tiene un beneficio adicional: la integración del equipo.

- Demasiados cambios en los requerimientos, entre Sprints: Esto va más allá del Sprint, pero puede pasar: de Sprint a Sprint, los items del Product Backlog y sus prioridades, van cambiando demasiado. Lo que era prioridad hoy, mañana ya no es. Lo que se pidió para este Sprint “porque era importante”, resulta que para el próximo sprint ya no se tiene en cuenta. Tal cantidad de cambios, es indicación de una falta de rumbo. Y puede llegar a desmotivar a un equipo: ve que cada cosa que va armando, al final, no se usa, y se tiene que dedicar a cada momento a otra cosa.

- Olvidarse de la retrospectiva: una reunión importantísima del marco de trabajo Scrum. Parece que esta reunión muchas veces queda en el camino. Con el gusto diario de hacer tareas, con la concentración que implica el Sprint Planning, con la excitación de la entrega en el Sprint Review, al final, no hay tiempo o nos olvidamos de hacer la reunión de retrospectiva. Un gran error: es la gran oportunidad del equipo para reflexionar sobre lo que está haciendo y sobre la salud del proceso.

- Saltearse algún Daily Standup Meeting (la reunión diaria): Alguna vez, por temas de tiempo, de organización de un día en particular, se saltea esta reunión. Si una parte del equipo no puede asistir (ejemplo: fue a una reunión de capacitación), se debe acordar: o la realizamos igual, aunque sea con dos miembros, y luego, si se reintegra el resto del equipo, hacemos una sincronización; o la pasamos ese día a otro horario. Pero les recomendaría no saltearse esta reunión.

El primer paso para ir corrigiendo estas situaciones, es darse cuenta: esa es la función de la retrospectiva. El segundo paso: no corregir todo de una, sino ir encarando problema por problema: comprometerse mejorar en un punto, y revisar la mejora en la próxima retrospectiva.

Post relacionado: Tales from the Scrum- Anti-patterns de la reunión diaria

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10549, 2752. Bookmark the permalink.

One Response to Tales from the Scrum: Anti-patrones de Sprint

  1. Román Mussi says:

    Angel, sobre esto:
    “Demasiados cambios en los requerimientos, entre Sprints”
    Esto no estaría dependiendo del Product Owner? Y en ese caso… como puede intervenir el ScrumMaster para mitigar el problema?
    Muy bueno el artículo, como siempre.
    Saludos
    Román Mussi

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>