Otras reuniones en Scrum para proyectos de Big Data & Analytics

Otras reuniones en Scrum para proyectos de Big Data & Analytics

Avanzando sobre el contenido de la guía de Scrum, y recordando que en el artículo anterior traté sobre la reunión de planificación del sprint en proyectos de Big Data & Analytics, hoy comento sobre el resto de reuniones.

Reunión diaria de Scrum

Se trata de una breve reunión de coordinación al principio de cada día, y considero que es un evento especialmente importante para el funcionamiento de Scrum. Son los miembros del equipo de desarrollo del proyecto de Big Data, Analytics o Business Intelligence, que se supone autoorganizado (no es una reunión de reporte a un jefe de proyecto), quienes intervienen en la reunión. Cada miembro responde a tres preguntas clave:

¿Qué hice ayer (desde la reunión diaria anterior) para colaborar con el objetivo del sprint?

Básicamente es el momento de saber, con cierta autocrítica, si se ha podido conseguir o no el grado de avance esperado, pero centrándose solo en un día. Por ello es fundamental que no se perciba como una reunión de reporte gerencial. Esa circunstancia incentiva el ocultar los posibles problemas o cambios ocurridos.

¿Qué espero hacer hoy para colaborar con el objetivo del sprint?

Hablamos de un punto de alineación entre el estado real del proyecto y el plan vigente. Recordemos, si el objetivo del sprint requiere cambios, es el momento, no habrá penalizaciones por ello. Quizás sea necesaria cierta replanificación, pero no es el objetivo de la reunión diaria. Lo que se recomienda es que haya una reunión posterior, donde se pueda entrar en más detalle, y donde posiblemente haya miembros que no tengan que asistir. De hecho, Scrum entiende que se necesitan más reuniones de las descritas, lo que marca la guía son las reuniones que considera obligatorias.

¿Qué impedimentos he tenido ayer o puedo tener hoy para colaborar con el objetivo?

Para mí es la pregunta clave de un marco de gestión adaptativa. Puede ser que hayan aparecido incidencias inesperadas, que la planificación fuera muy optimista, que exista dependencia entre tareas incompletas, que falten conocimientos técnicos, que surjan malentendidos, etc. Un equipo autoorganizado tiene que aprender a solventar (adaptarse) a este tipo de bloqueos, pero se reconoce la gran dificultad de lograrlo.

En teoría es el Scrum Master quien ayuda a superar posibles bloqueos. Sin embargo, por mi experiencia en data science, y aunque puede ir en contra de los principios ágiles, a veces es necesario que un perfil más directivo priorice ciertas tareas, consiga más recursos, coordine diferentes equipos de Scrum, etc. Siempre que no sea con intención de penalizar errores, ni de realizar microgestión, a mí me parece admisible. Idealmente este perfil directivo no asiste a la reunión diaria, pero se ofrece a colaborar con el equipo después de la misma.

Reunión de refinamiento de la lista de producto

Aunque en la guía se menciona como un proceso continuo, yo creo que tiene entidad suficiente para establecer reuniones específicas. Recordemos que inmediatamente después de finalizar un sprint comienza el siguiente, con la reunión de planificación.

La idea es que durante el sprint actual, sin duda enfocado a trabajar sobre la lista de elementos del sprint en curso, se pueda reservar una pequeña parte del tiempo para trabajar también con la lista de producto (preparando futuros sprints). En concreto estamos hablando de detallar más la lista de producto, reunirse con algún stakeholder si procede, sin duda también con el Product Owner. De esta forma, ir entendiendo mejor las necesidades de los usuarios. Igualmente se pueden anticipar otros prerrequisitos técnicos, como la instalación de una base de datos o de cierto software de Big Data & Analytics, supuesto que sean tareas no abordables por el propio equipo. Así, conseguiremos que la planificación del sprint no se convierta en un punto de bloqueo justo en su inicio.

Reunión de revisión del Sprint

El foco de esta reunión, al final del sprint, es mostrar el incremento de producto funcionando que se ha conseguido, así como entender qué ha quedado pendiente de hacer para futuros sprints. Idealmente no se basa solo en una demostración de nuevas funcionalidades del producto, sino que se pone a disposición real de los interesados, para que puedan realizar sus propias pruebas del software ya funcionando (es admisible por ejemplo que sea un prototipo y no un paso a producción, lo importante es que los usuarios y el Product Owner puedan manejar el software).

De todas formas la reunión no debe quedar solo en la demostración. También hay que revisar una vez más la lista de producto, conjuntamente con el Product Owner, y entender cómo la repriorización frecuente ayuda de manera efectiva al negocio. De nuevo se requiere autocrítica, si hay funcionalidades que no han sido adecuadas, serán necesario modificarlas en siguientes sprints, evitando penalizaciones por ello.

Refiriéndonos a los proyectos de Analítica, Business Intelligence y Big Data, creo necesarias ciertas matizaciones para esta reunión. En concreto, pienso que requiere más tiempo que en otro tipo de proyectos, y no esperar solo al final del sprint. Está muy bien ofrecer un prototipo a los usuarios, pero también hay que considerar si cuentan con la formación suficiente, o es preferible que estén acompañados de alguien del equipo técnico durante sus revisiones.

El Product Owner tiene que velar por mantener un feedback coordinado de los diferentes interesados, ya que cada uno tendrá sus propias prioridades. Otro riesgo típico es que los interesados no entiendan que están viendo un prototipo con algunas limitaciones, lo que requiere una cierta gestión política del proyecto.

Reunión de retrospectiva del Sprint

Si en la anterior reunión se pretendía revisar principalmente el producto, en la retrospectiva se quiere evaluar el propio proceso de Scrum. Esta reunión marca el fin del sprint. Es el momento de hablar sobre lo que ha funcionado mejor y peor en el resto de reuniones, y de establecer alguna mejora concreta. Por ejemplo, se ha podido descubrir que la reunión diaria se extiende excesivo tiempo porque se quiere entrar en el detalle de las incidencias, o porque cada día hay alguien diferente que llega tarde a la reunión.

Otros problemas típicos más complejos abordan la dificultad de formalizar qué se considera un trabajo terminado, o cómo repartirse tareas de forma equitativa. Igualmente se pueden tratar temas sobre barreras en la comunicación, posibles malentendidos, etc.

Pero sería un error dedicarse exclusivamente a revisar puntos negativos. También hay que evaluar puntos fuertes, y reconocer lo que sí está funcionando (ej. sustituir correos electrónicos por reuniones cara a cara), para de esta forma afianzar las prácticas más útiles.

 

Con esta entrada he cubierto ya todos los eventos de Scrum, y anteriormente lo hice sobre los principios ágiles y los roles. En  próximos artículos realizaré consideraciones sobre los artefactos y demás conceptos básicos de Scrum. Permaneced atentos al Blog de datahack.


José Julio López, Business Intelligence, Data Science, IT Project Manager. SCRUM Master, PMP y antiguo alumno del máster de Big Data & Analytics de datahack.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *