viernes, 30 de junio de 2017

¿Quién presenta el incremento en la revisión de sprint?

Miembro del equipo presentando el incremento en la
revisión de sprint - cortesía de Pixabay
A lo largo de diferentes equipos he visto distintas configuraciones que dan distintas respuestas a esta pregunta.  

Nos encontramos en la revisión de sprint donde, según el marco de Scrum, el equipo es quien enseña lo que ha realizado a lo largo de del sprint. Primero expone el objetivo del sprint para después demostrar el funcionamiento de lo que ha completado al 100%, aquello que entrega y cumple con la definición de hecho (DoD).

Usualmente se recorren una a una las historia de usuario de la pila de sprint, se explica como se abordó cada una de ellas y se demuestra el funcionamiento en un entorno que represente entrega (test, staging, preproducción...). Tratada la historia en curso se pasa a la siguiente. Pero, ¿quién se sienta ante el ordenador y demuestra el software funcionando e interlocuta con los interesados?

La respuesta es el equipo de desarrollo, y es una preferencia del equipo como hacerlo, a veces hay un voluntario, a veces se nomina un presentador de entre los miembros y a veces lo hacen de forma compartida. He visto varias configuraciones que funcionan:
  • El tester hace de presentador: es una opción que funciona muy bien porque el tester habrá efectuado las pruebas a lo largo del sprint, tiene la visión del incremento fresca en su memoria, y por la naturaleza de su especialidad está mas cerca de los usuarios para los que se está construyendo el producto.
  • Un lider que emerge del equipo: siempre suele haber un voluntario con habilidades sociales al que le guste mover cosas y tratar con otras personas. Suele tener más empatía y más comprensión del la solución a nivel holístico.
  • Algunos miembros de forma rotatoria: es una opción que funciona cuando no es obligatoria para todos los miembros, funciona solo si rotan aquellos miembros del equipo que quieran hacerlo de forma voluntaria. Una revisión de sprint presentada por un miembro que siente que no puede hacerlo o no quiere hacerlo, probablemente resulte en una reunión pobre que genere un feedback escaso.
En mi experiencia la mejor combinación es cuando una persona presenta y lleva la conversación con los interesados, y otra persona ejecuta la demostraciones de las funcionalidades en el ordenador. Si además intervienen otros miembros cuando sienten que tienen algo que puedan aportar tenemos la mejor de las opciones posibles

Como siempre suele ser con Scrum, para saber si tenemos una reunión exitosa basta con fijarnos en como interactúan las personas, si el campo emocional es de "buen rollo", las personas hablan como iguales, con respeto y seguras y sin miedo a equivocarse, entonces podemos estar seguros que todo está bien encarrilado.

4 comentarios:

  1. Hola Alexander!!!
    ¿Qué hace el Scrum Master en la Review? Además de facilitar la reunión....

    Creo que la presencia del SM en la Review se dilata cuando el equipo es maduro, correcto?? Cuál es tu experiencia??

    Gracias, muchas gracias! Elvira

    ResponderEliminar
    Respuestas
    1. Hola Elvira,

      Lo más importante es evitar que la revisión sprint se convierta en una demo clásica en la que haya frustración y desmotivación.

      Me explico, en una demo clásica lo que puede ocurrir es el usuario ve lo que están construyendo y hace cambios, mejoras, ajustes y salen a la luz los malentendidos... una lista de cosas que los miembros del equipo apuntan frenéticos sintiendo que el usuario está diciendo que no han hecho un buen trabajo. Luego, con tal de entregar y poder seguir adelante, hacen las modificaciones a contrarreloj al día siguiente, resultando todo ello en un producto mediocre.

      El Scrum Master debería:
      - Concienciar al equipo de lo que significa feedback, es evaluación despiadada del producto, no del trabajo hecho por el equipo, es deseable identificar todas las mejoras posibles y estar abiertos a todo feedback, no es algo personal
      - Concienciar al Propietario del Producto y usuarios, animándoles a ver primero lo que hay, luego expresar al equipo que han hecho un buen trabajo, y luego entrar despiadadamente en ajustes, modificaciones y mejoras siempre sobre el producto, nunca sobre el trabajo hecho por las personas
      - Asegurarse que esa lista de ajustes, modificaciones y mejoras se la lleva el Propietario del Producto e incluye los elementos en la pila de producto en donde toque por valor aportado/negocio, algunas cosas se construirán en el siguiente sprint, otras quizá nunca

      Con la madurez del equipo el Scrum Master se vuelve prescindible en la revisión, quiero invitarte a leer el siguiente post: http://scrum.menzinsky.com/2017/05/los-scrum-masters-son-un-rol-temporal.html

      Espero haberte ayudado :-)

      Saludos,

      Alex

      Eliminar
  2. Sí !!!! de gran ayuda. Al PO le cuesta cambiar la visión que tiene de los SM: "chico de los recados" y el equipo está desorientado.
    Interesante el Post recomendado. Una vez más, GRACIAS!!!
    Un saludo,
    Elvira

    ResponderEliminar