4 reuniones para avanzar en proyectos (Scrum)

Para que un equipo avance en sus tareas y mejore constantemente es requerido que cuente con una efectiva, sincera y frecuente comunicación. Además, es clave entregar soluciones de forma temprana y frecuente, ir resolviendo las necesidades más prioritarias lo antes posible, para:

1. Obtener los beneficios prácticos de la implementación temprana;
2. Brindar un mejor clima laboral, ya que facilita la construcción de confianza con el cliente, y también provee satisfacción y motivación al equipo de trabajo;
3. Recibir retroalimentación que permita mejorar tanto en la forma de trabajar como en la construcción de la solución;
4. Tomar decisiones en el momento más beneficioso (es decir, no adelantarse a decidir todo al comienzo del proyecto, sino decidir por períodos cortos, a medida que se va contando con más información de la realidad y habiendo avanzado en el proyecto).

Por eso Scrum propone ciclos de trabajo (sprints, iteraciones) de máximo 4 semanas, donde cada ciclo comience con una Planificación y termine con una Retrospectiva. En la imagen de ejemplo sería un ciclo de dos semanas, los lunes cada 15 días una reunión de planificación, todos los días la reunión de avance, termina el ciclo con Revisión y Retrospectiva.

IR AL ÍNDICE SCRUM

Reunión de planificación (Planning Meeting)

¿Cuáles son sus objetivos?

• Conocer las historias más prioritarias y toda la información vinculada a ellas.
• Realizar estimaciones y asumir compromisos para el siguiente ciclo (sprint).
• Nivelar conocimientos entre los integrantes del equipo.

¿Qué hacer antes de la reunión?

• Sin un trabajo previo, la reunión no logra su objetivo o se extiende más de dos horas.
• El Guardián del producto (Product Owner):
  • Completar, especificar y priorizar el listado de necesidades (Backlog). Si esto no está listo, no se puede iniciar la reunión.
  • En caso que sea necesario administrar un presupuesto, será necesario realizar los cálculos de insumos, costos de estructura, honorarios de colaboradores, contratación de servicios y productos adicionales, etc.
  • Resolver conflictos con los diferentes interesados en la aplicación. Si hay conflictos de criterios o intereses durante la planificación, con discusiones sobre qué hacer y cuáles son las prioridades son una pérdida de tiempo para el equipo.
  • Cuando es requerido, escribir documentos complementarios con especificaciones.
  • Hacer una buena priorización de necesidades y pedidos permitirá realizar entregas en el corto plazo para que los destinatarios de la solución empiecen a recibir beneficios. Es fundamental revisar que cada actividad planificada no implique un esfuerzo y costo mayor que el beneficio potencial que se obtendrá al realizarla. En esta evaluación es importante cuidar y mantener las actividades que previenen o mitigan riesgos.
• El equipo:
  • Investigar el producto, lo que está hecho y cómo. Pueden separarse los módulos en diferentes personas del equipo, no todos tienen que saber todo, sino que el equipo entero tiene que tener el conocimiento necesario para poder estimar cuánto hará en el siguiente ciclo (sprint).
  • El facilitador o alguien del equipo prepara la sala con proyector disponible.

Durante la reunión

• El Guardián del producto:
  • Muestra el Backlog y aclara todas las dudas sobre qué hay que hacer.
  • No especifica cómo resolver las necesidades, pero sí los criterios para considerarse resueltas, cómo serán probadas, cuáles son los criterios de aceptación.
  • Opcional: Escribe un objetivo principal o visión del ciclo (sprint).
• El equipo:
  • Nivela los conocimientos necesarios para responder a las necesidades y los separa en tareas.
  • Estima cuánto esfuerzo le llevará cada necesidad. Para desarrollo de software hay diferentes técnicas, como por ejemplo el Planning Pocker.
  • Asume un compromiso: qué necesidades resolverá al finalizar el ciclo (sprint).
  • Si es la primera reunión, pueden establecer en este momento la agenda de todas las reuniones en los próximos sprints.

Después 

• El equipo arma el tablero de tareas, o bien desagrega las necesidades planteadas por el Guardián del producto en Tareas en la herramienta electrónica.
• El Guardián del producto informa a los interesados qué se hará en el ciclo en curso e informará de todos los cambios que tengan impacto en el negocio.

Reunión de avance (Daily meeting)

¿Cuáles son sus objetivos?

• Distribuir el trabajo.
• Evitar re-trabajos (prevenir que dos personas estén haciendo la misma tarea, o que uno esté haciendo algo que ya fue resuelto antes).
• Asegurarse que se llegará a tiempo con lo comprometido y darse cuenta lo antes posible si hay un riesgo de incumplimiento, y poder así tomar acciones correctivas.
• Ganar en motivación, por poder autoasignarse las tareas, y decir lo que voy terminando.
• Estimular la colaboración, ya que:
  • Cada uno sabe qué está haciendo el otro y puede ofrecerle información que lo ayude.
  • Cada uno expresa con qué obstáculos se encuentra, puede pedir ayuda, y eso orienta a los demás en qué pueden colaborar.
  • Cuando uno está con pocas tareas, y escucha que los demás están absorbiendo más trabajo, puede darse cuenta qué otra tarea puede asignarse o en qué puede ayudar a otros.

¿Qué hacer durante la reunión?

• Cada persona del equipo responde brevemente a 3 preguntas:
  • ¿Qué hice desde la última reunión de avance?
  • ¿Qué me propongo hacer hasta la próxima reunión de avance?
  • ¿Qué obstáculos encuentro?
• La reunión no dura más de 15 minutos, todos de pie para hacerla ágil, para que nadie se extienda en detalles. Si esto no es posible, puede ser teleconferencia, vía mail o por grupos en Whatsapp, Telegram, Slack. Cuando son grupos se acuerda un tiempo máximo de audio, por ejemplo 2 min.

Después

• Si se identificó una oportunidad de aportar algo a un compañero o quedaron dudas, acercarse a esa persona, resolver dudas y coordinar alguna acción.

Entrega y revisión del producto/prestación (Demo o Review)

¿Cuáles son sus objetivos?

• Tener visibilidad sobre el grado de avance (para todo el equipo y otros interesados en el proyecto).
• Confirmar si fueron bien entendidas las necesidades y, si es un producto, confirmar si funciona correctamente
• Nivelar el conocimiento sobre lo realizado (todos los integrantes del equipo conozcan lo realizado por los demás).
• Brindar información para mejorar en la estimación de las siguientes tareas y que se puedan intercambiar tareas.
• Mejorar el compromiso, ya que se revisa si los compromisos asumidos en la planificación del ciclo en curso fueron cumplidos o no.

 ¿Qué hacer antes de la reunión?

• El Guardián del producto:
  • Revisa que las necesidades hayan sido comprendidas y correctamente resueltas.
  • Envía la invitación, indicando claramente qué se incluirá en la Entrega y durante la reunión se deberá mantener foco en lo especificado.
  • Si es desarrollo de software:
    • Prueba el producto e informa los errores con tiempo suficiente para que sean corregidos antes de la entrega y revisión. Si es necesario, arma pruebas con casos reales, mostrando el curso normal y las excepciones.
    • La prueba debe incluir el proceso completo (por ejemplo, si es una aplicación que será bajada de Internet, mostrar el primer paso).
    • Si corresponde, hacer pruebas de performance (en la historia debe ser detallado el volumen de datos a procesar y también el tiempo máximo de respuesta esperado).
• El equipo:
  • Si corresponde, corrige los errores detectados.
  • Prepara la sala con proyector disponible, dejando abiertos la herramienta electrónica de seguimiento del proyecto, la información vinculada, y las aplicaciones que serán mostradas.

Durante

• Los presentes:
  • Revisan el listado de necesidades (backlog) comparando con lo realizado.
  • Chequean si lo comprometido fue cumplido, tomando en cuenta el criterio de Terminado definido para ese proyecto o tarea (por ejemplo, puede ser listo para implementar apenas termina la reunión).
  • Dan y recibe retroalimentación sobre el producto (sobre cómo se trabajó es tema de la Retrospectiva)
  • Asumen los errores (no valen las excusas ni las justificaciones, analizar las causas de los errores es también tema de la Retrospectiva).
• Si hay otros interesados en el producto, pueden hacer preguntas y comentarios. Si hacen nuevos pedidos, son anotados por el Guardián del producto quien lo incorporará al listado de necesidades y los analizará en detalle luego de la reunión.
• Al finalizar se aclara si se cumplió con lo comprometido o no: si la entrega es parcial, por más que se haya realizado el 99%, no se cumplió con lo comprometido. Y si esto duele en el orgullo del equipo, será un motor en la retrospectiva para revisar cómo fue el proceso y en qué se puede mejorar.
• Se registra lo realizado, dejando visible la diferencia con lo comprometido: esto brinda información para realizar una mejor estimación en los ciclos siguientes.

Luego

• Se continua con la reunión de retrospectiva.

Reunión de retrospectiva

¿Cuáles son sus objetivos?

• Mejorar las formas de trabajar y las dinámicas de grupo.
• Resolver conflictos y cultivar la confianza, la colaboración, la honestidad.
• Analizar problemas hasta encontrar su origen y diseñar soluciones.
• Crear formas más eficientes de lograr los resultados y ponerlas a prueba.
• Motivarse como personas y como equipo para alcanzar el máximo potencial.

¿Qué hacer antes de la reunión?

• Se puede preparar usando diferentes técnicas cada reunión: AQUÍ TIPS PARA RETROSPECTIVAS.

Durante

• Se sugiere realizarla inmediatamente después de la reunión de Revisión para que lo revisado esté fresco. Además, si en la Revisión algún participante quiere hablar temas que corresponden a la Retrospectiva, se le puede decir que espere unos minutos más, hasta que comience la Retrospectiva.
• Como mínimo, realizar las siguientes preguntas: ¿Qué hicimos bien y queremos seguir haciendo? ¿Qué queremos dejar de hacer? ¿Qué nuevos compromisos asumimos? ¿Qué obstáculos identificamos y cómo nos proponemos superarlos?
• Es importante una actitud de apertura: hablar sin rodeos, cuestionarse el propio pensamiento, reconocer errores, escuchar distintos puntos de vista y comentarios. Es un buen momento para conocer más a los demás y dejarse conocer: exponer e indagar.
• Es responsabilidad de todos que la Retrospectiva sea interesante, además que se hable con honestidad de lo que ocurrió: se realicen propuestas para mejorar, se generen pedidos y compromisos.
• Los compromisos mejor si quedan registrados y accesibles para todo el equipo, para que durante el siguiente ciclo sean tomados en cuenta, y en la siguiente Retrospectiva se revise si se mejoraron las prácticas, se cumplieron los compromisos, y si algo no dio el resultado esperado, volver a analizarlo y ajustarlo, asumiendo nuevos compromisos.

Después

• Celebrar lo logrado en ese ciclo de trabajo.
• Descansar y generar energía para el próximo ciclo de trabajo.

Aclaraciones para el desarrollo de software

• La duración de cada ciclo (sprint) sea entre 1 y 4 semanas
  • Motivo: En menos de una semana es difícil entregar una versión lista para implementar y con valor de negocio. En más de 4 semanas es difícil hacer estimaciones acertadas, y el riesgo de entregar funcionalidad que no se ajuste a las necesidades es mayor. Mientras más corto el sprint, más rápido se entrega valor de negocio y más fácil para el equipo asumir el compromiso que todo lo prometido estará listo, ya que el riesgo de desvío es menor. Mientras más largo, más valor de negocio se puede incluir en una misma versión, y menos tiempo en reuniones de planning, Demo y retrospectivas. Algunos equipos encuentran que al contar con un sprint de 2 o 3 semanas, se facilita el cumplimiento de los compromisos porque se compensan los tiempos incurridos en las diferentes tareas.
• La duración sea definida de forma fija durante todo el proyecto
  • Motivo: Para poder tener una base de datos con las estimaciones y lo realizado, lo cual permite ir conociendo la capacidad de respuesta del equipo y realizar estimaciones más realistas.
• La duración del sprint se define en el primer planning, con todo el equipo
  • Motivo: El PO aclara cada cuánto tiempo es necesario entregar valor de negocio (por ejemplo: cambios en regulaciones de entidades de gobierno, cierres contables) y el equipo cada cuánto tiempo es posible entregar una versión lista para implementar.
• Sólo cambiar la duración de un sprint en su planning meeting
  • Motivo: Si se cambia la duración durante el sprint, se pierde el compromiso asumido.
  • Aclaración: Los motivos por los cuales se puede cambiar la duración es por asuntos de fuerza mayor (como cambios en regulaciones de entidades del gobierno) o porque el equipo considera que no está en su máximo rendimiento con la duración previamente definida. No se sugiere cambiar la duración por motivos menores, ya que se pierde el ritmo de trabajo y la información sobre estimaciones.
• Para estimar la duración del proyecto completo, es necesario completar el backlog, con todas las historias de usuario y realizar un planning donde el equipo estime el esfuerzo de cada una.
  • Motivo: Al estar el equipo completo, se nivela el conocimiento y se reduce el riesgo de error. Estimar todo el proyecto implica tiempo y riesgo de desvío, pero hay organizaciones que lo requieren para organizar el flujo de trabajo a lo largo del año y para realizar comunicaciones hacia los clientes.
  • De todas formas, sugerimos que el compromiso sea por sprint. Motivo: Mientras más largo el sprint más riesgo de error en la estimación, mientras más corto el plazo para cumplir una tarea, más fácil asumir y mantener un compromiso. La estimación es algo que puede fallar y se aprende a estimar con el tiempo, en cambio el compromiso es una promesa que su cumplimiento depende de la persona o el equipo que ejecuta las tareas.

IR AL ÍNDICE SCRUM