Ir al contenido principal

Retrospectiva ¿Punto de encuentro PMI-Scrum?

En un post anterior, hablabamos acerca de las semejanzas o diferencias entre el Scrum Diario y las Reuniones de Estatus estilo PMI. En esta oportunidad hablaremos sobre la ceremonia o reunión de retrospectiva desde ambos puntos de vista.

Comencemos por un punto en común que creo que todos coincidimos: ¿Si hay que sacrificar una actividad o ceremonia, cuál es la elegida?.. es correcto! tanto pmistas como scrumistas sabemos que el candidato a sacrificar es: La reunión de retrospectiva.

La restrospectiva tiene como finalidad identificar oportunidades de mejora, así sea repitiendo algo que nos dió buen resultado o mejorando algo que no nos funcionó como esperabamos, en otras palabras, se trata de la mejora continua del proceso.

A pesar de que el pmbok 4  en ningún lado menciona la palabra "retrospectiva", en el grupo de proceso de cierre se consigue lo siguiente:
  • ..Realizar un revisión tras el cierre del proyecto o la finalización de una fase
  • Registrar los impactos de la adaptación a un proceso
  • Documentar las lecciones aprendidas..
Es decir, por supuesto que es una buena práctica del PMI realizar una reunión de retrospectiva al finalizar una fase o proyecto, donde se revisan las lecciones aprendidas que se han ido documentando a lo largo del mismo. También se puede conocer esta reunión como lessons learned meeting o reunión de lecciones aprendidas.

En el caso de Scrum la podemos identificar más fácilmente, ya que una de las cuatro ceremonias es la Restrospectiva del Sprint (recuerden que Scrum utiliza el término Sprint como iteración). Se trata de una reunión, en general más informal que las otras, donde el  equipo y el ScrumMaster conversan aceca de lo que salió bien y lo que se debe mejorar en el siguiente sprint. La asistencia del Product Owner no es obligatoria.
 
Debido a que en Scrum la retrospectiva es una ceremonia explícita del marco de trabajo, se obvia en menor porcentaje que en el caso de la gestión de proyecto tradicional, pero sin embargo, al hacer un sondeo acerca de esta reuniones en ambos casos podemos observar que es la más propensa a eludir.

Seguramente esto pueda mejorar si concientizamos al Sponsor o a los miembros del equipo, del valor que agrega esta actividad para poder implementar las mejoras de las que siempre hablamos.

Estas reuniones también son conocidas como post-mortem, y si hacemos la metáfora del espejo retrovisor,  se trata de ver el camino que dejamos atrás, para evitar los huecos y hacer el recorrido más placentero; y puede ser que también aplique: "Objects in Mirror are Closer than They Appear".

Nos seguimos leyendo.





Comentarios

Daniel Sachi dijo…
Por experiencia, esta reunión de retrospectiva no debiera obviarse nunca en Scrum, porque además se revisa la velocidad del team, y la performance individual, por lo cual es muy necesaria para poder elaborar un mejor planeamiento del próximo Sprint.
Otro tema no menos importante es que el PO no debiera participar de estas reuniones, para que el equipo pudiera tener la intimidad necesaria para decir lo que piensa y reconocer errores.
Gracias por compartir!!
Gustavo Bonalde dijo…
Daniel, muy de acuerdo contigo "no debería obviarse".. sin embargo sucede. Tu otra observación es muy interesante y pudiéramos hacer todo un foro de discusión acerca de esto, no consideras el PO como miembro del proyecto? y al SM? yo considero que la presencia del PO en esta reunión puede ser opcional.. Saludos. Abrazo.
Silvia Rebelo dijo…
Buen articulo profesor!

Aun no he encontrado un lugar aqui donde no hagan estos meetings. No solo las hacen internamente sino tambien con el cliente (las llaman "Lessons learned").

Todas las personas que estuvieron envueltas en el proyecto tienen que asistir, así hayan puesto solo una linea de código! sin excepción :)

Saludos!
Gustavo Bonalde dijo…
Silvia gracias por el comentario.
Aprovecho para hacer un sondeo: el PO asiste a la reunión de retrospectiva?
Silvia Rebelo dijo…
En los que yo he asistido han estado siempre presentes :)
MariaT dijo…
Pues si debería asistir el PO, porque no solo el hecho de revisar la velocidad del team o el performance individual depende del desarrollo sino tambien de que bien especificados estén las Historias de usuarios, seguramente el PO también tendrá sus lecciones aprendidas despues de una buena retrospección.
Por otro lado con tu similitud del retrovisor... me dio gracia porque hay un decir que indica "Sabes porque el parabrisas es mas grande que el retrovisor?Porque el camino que tienes por delante es más importante que el que dejas atras" jajajja, pero en proyectos no aplicaría tanto, ya que si vemos bien ese hueco en que caimos por el retrovisor, seguramente estarás mas pendiente de no volver a caer en uno parecido! Saludos.
Gustavo Bonalde dijo…
MaríaT, soltaste el productOwner que llevas por dentro ;) saludos
Gustavo y de mas comentaristas, considero que la ceremonia de retrospectiva no se deberia olvidar o dejar de practicar, porque en esencia representa el feedback del equipo para si mismo. De igual manera, la retorspectiva se encuentra enfocada a el proceso como se desarrollaron los features o tareas del sprint.
En cuanto si deberia estar el PO, comparto contigo que debe ser opcional para equipos poco maduros, ya que esta ceremonia suele requerir de una profunda introspección, lo que a su vez requiere un ambiente seguro, donde nadie se sienta intimidado, de requerir la presencia del PO es por la exigencia del equio. En cambio en equipos de alta madurez es posible que los equipos no se sientan intimidados por la presencia del PO ya que han alcanzado la esencia del Scrum que desde mi humilde punto de vista es el respeto por uno mismo y por los otros, confianza y coraje.

Entradas más populares de este blog

¿Cuál programa tomo? ScrumAlliance vs. Scrum.org

Luego de participar en varias discusiones de foros acerca de las distintas certificaciones que existen de Scrum, me decidí a escribir este post para tratar de aclarar este enredo (CSM, CSPO, CSD, CSP, CSC,CST, PSD, PSF, PSM, PSPO, PMI-ACP) que a veces surge con todo esto.

Resulta que los 2 principales organismos ScrumAlliance y Scrum.org (hay otros varios como ScrumManager.net) que ofrecen los cursos de certificación en Scrum, vienen del mismo origen: Ken Schwaber. En una carta del año 2010, Ken explica por qué deja el ScrumAlliance y decide crear un nuevo instituto: "Este viajeha sido moldeado pordos fuerzas opuestas: el deseo dehacer lo correcto,y el deseo deganar dinero.ForméScrum.orgpara reenfocarmis esfuerzos enhacer lo correcto.".. Lo cierto es que no se puede negar el factor "revenue" para estas empresas, por su cursos, certificaciones y assessment que ofrecen, al igual que su objetivo de divulgar Scrum y mantenerlo por un buen tiempo.

A continuación les dejo…

Borrador de la 6ta edición de PMBOK

Les dejo un extracto de los cambios más relevantes del borrador del PMBOK 6, cuya versión definitiva se prevé para el tercer trimestre del 2017.

La secciones de la 1-3 han sido modificadas, dejando la información importante y agregando nueva información que refleja la evolución del Gerente de Proyecto hacia agente de cambio y proveedor de valor de negocio. En la sección 1, se incorporan términos relacionados con enfoques ágiles y entornos iterativos y adaptativos.Los grupos de procesos se mantienen igual que en la versión 5.Cambian de nombre 2 área de conocimiento:
Versión 5 Versión 6 Project Time Management Project Schedule Management* Project Human Resource Management Project Resource Management.

*Me gusta, porque definitivamente el tiempo no se gestiona, podemos gestionar son las actividades.

Hacer las cosas correctas vs Hacerlas correctamente

"Hacer las cosas correctas" es un aspecto de satisfacción en el producto, servicio o resultado que se quiere hacer, mientras que "Hacerlas correctamente" se refiere más al método utilizado en su desarrollo o implementación.

Existen cuatro combinaciones posibles:

Hacer lo correcto y hacerlo correctamenteHacer lo correcto y hacerlo incorrectamenteHacer lo incorrecto y hacerlo correctamenteHacer lo incorrecto y hacerlo incorrectamenteSi lo llevamos a los conceptos de Management: "Estrategia y Táctica", la combinación quedaría de la siguiente manera:
Se tiene una estrategía y se cuenta con una táctica adecuada (el estado del arte)Se tiene una estrategía y no se cuenta con una táctica (según Sun Tzu “Strategy without tactics is the slowest route to victory" )No se tiene estrategía, pero se cuenta con una táctica adecuada (según Sun Tzu "Tactics without strategy is the noise before the defeat”)No se tiene estrategía, ni tampoco con táctica (al menos …