Retrospectivas Ágiles: No sólo Accionables

Retrospectivas Ágiles: No sólo Accionables

Para que una sesión de Retrospectiva de Scrum sea efectiva debe tener como resultado mejoras a implementar durante el próximo Sprint. ¿Si..?

Una pequeña reflexión para mejorar tus Retrospectivas de Scrum.


Último día del Sprint. Viernes 5pm. Estás facilitando una retrospectiva y hay muchas discusiones sobre distintos temas interesantes. Todavía quedan 20 minutos para cerrar y te empezás a inquietar. Si bien las discusiones son interesantes no hay ninguna tarea concreta que alguien del equipo se comprometa a realizar. Te enseñaron que sin acciones claras como resultados de una reunión, fue todo una pérdida de tiempo.

Querés facilitar la discusión para lograrlo. Querés "A-CCIO-NA-BLES" - tareas específicas que alguien del equipo se compromete a ejecutar y que (a más tardar) en la próxima retrospectiva vas a verificar si se pudo completar la tarea y si tuvo el impacto esperado.


Ejemplo de Accionable: "Acordar con el equipo una Definition of Done y ponerla visible en el tablero de tareas"

Ejemplos no Accionables:
"Mejorar los ambientes de prueba."  (inespecífico)
"Más Pair Programming" (inespecífico)
"Tuvimos muchas interrupciones de otras areas." (problema / queja)
"Que haya menos interrupciones" (expresión de deseo)
"Mejores estimaciones" (expresión de deseo)

Ya quedan 10 minutos....

- "Y bueno equipo ¿qué podemos hacer distinto el próximo Sprint?"
- "bueno, creo que cuando alguien de Marketing nos venga con un requerimiento, en lugar de tomarlo, deberíamos derivarlo al Product Owner para que lo coloque en el backlog".

Y ¿esta tarea? Es accionable? Quien la toma? Qué pasa si durante el siguiente Sprint, nadie de Marketing se acerca a pedirnos algo, cumplimos o no?

Esto más que una tarea, parece un nuevo aprendizaje de equipo!

Acuerdos de Equipo


Para el objetivo de mejorar, no todo son tareas accionables. También se mejora con aprendizajes para adoptar formas más efectivas de comportamiento. Estos aprendizajes implican un cambio de hábito en nuestro trabajo. Lo podemos llamar "Buenas Prácticas del Equipo" o "Acuerdos de Trabajo" (En Inglés Working Agreements).


Ejemplos de Acuerdos de Equipo


"Si hay una interrupción de una persona externa al equipo pidiendo una tarea, explicarle que lo tiene que hablar con el Product Owner. No tomar el trabajo."

"Tomar los Bugs antes de tomar una nueva tarea"

Cómo darnos cuenta si un acuerdo de equipo, está siendo tratado como una tarea:


- Un acuerdo de equipo no se puede asignar a un responsable, todo el equipo queda asignado.

- Un accionable se pasa por los estados "pendiente, en curso y completado". Un acuerdo de equipo no tiene esos estados o quedaría "en curso" durante todo el Sprint.

- Es posible que el acuerdo no se llevó a cabo, porque no se dieron las condiciones. Por ejemplo: este Sprint no hubieron interrupciones o no reportaron Bugs.

Conclusión:


Una retrospectiva efectiva tiene como resultado tareas accionables y/o nuevos acuerdos de equipo.
Saber diferenciar ambos tipos de resultados hace el proceso más efectivo.

Cuando un tema de la retrospectiva es inespecífico y no accionable, se debe seguir profundizando en el problema hasta encontrar si se resuelve con una acción específica o con un acuerdo de equipo.

Para Seguir Leyendo:





Twitter: @dbuo





Entradas populares de este blog

Visual User Story Mapping Aplicado

Historia de las Metodologías Ágiles en Contexto

Los Bugs en Scrum