A finales de 2020 estuve acompañando a un equipo con Scrum. En aquellos momentos de la pandemia, las empresas estaban combinando la vuelta a la oficina con teletrabajo. En este equipo se optó por la rotación dentro del equipo. Durante la Daily Scrum acaeció un hecho interesante, los miembros del equipo que habían acudido a la oficina estaban de pie mientras que el resto de componentes del grupo estaban sentados en su casa. ¿Es la manera más efectiva de hacer una Daily Scrum? Os propongo algunos consejos.
El Objetivo de la Daily Scrum
La Daily Scrum es uno de los eventos de Scrum peor entendidos y que mayor relevancia tienen cuando disponemos del foco adecuado. Para empezar, debemos olvidar el nombre de “Daily Stand-up” que podemos encontrar en muchas formaciones o en libros de dudosa procedencia. Los participantes en el evento no están de pie, salvo que queramos que su duración sea menor. Aunque nuestro caso es raro ya que hay personas sentadas.
El evento tiene un objetivo claro: sirve de apoyo a los Developers para que puedan autogestionarse, de cara a alcanzar el Sprint Goal que se han marcado en el Sprint. Recordemos que, durante la Sprint Planning, habían fijado un Sprint Goal al que habían acompañado con un plan de acción que había que acometer. Este plan debe ser inspeccionado y adaptado cada día para analizar cómo vamos y poder tomar medidas que nos permitan asegurar la entrega de valor. De ahí, la importancia de la Daily Scrum dentro del Sprint.
A partir de entender la motivación de este evento, debemos entender el formato del mismo.
Entendiendo la Daily Scrum
La Daily Scrum tiene una duración de 15 minutos máximo, es decir, que puede durar menos pero no debe durar más (lo que desemboca en una reflexión interna). La hora del día debe ser siempre la misma, se suele recomendar a primera hora del día, pero no es obligatorio. El lugar debe ser el mismo también, aunque esto es sencillo en remoto.
El formato del evento es libre, es decir, los desarrolladores deben decidir cómo quieren realizar el mismo. Las “famosas” tres preguntas no son obligatorias, es más, hay muchos equipos que consideran que realizarlas les lleva a un formato de “reporte”, algo poco recomendable.
Los asistentes a la Daily Scrum son los Developers que son los responsables del mismo. El Scrum Master, Product Owner u otros Stakeholders pueden venir pero en calidad de oyentes.
Debemos contar con el Sprint Backlog en la Daily Scrum, ya que es el artefacto sobre el que inspeccionamos y adaptamos. Necesitamos entender el estado del trabajo (actualizaciones, nuevo trabajo, modificaciones…) y poder adaptar el plan para garantizar que acometemos el Sprint Goal.
Developers, ¡es vuestro turno!
La Daily Scrum es un gran momento para que los Developers de un Scrum Team den un paso al frente. No hay jerarquías dentro de un Scrum Team, por tanto, necesitamos momentos de inspección y adaptación en los que poder entender si estamos yendo en la dirección correcta.
Scrum busca la autogestión y la responsabilidad compartida del Scrum Team como un todo. En vez de proponer cómo dividir el trabajo y organizar a las personas, Scrum simplifica todo en asumir la responsabilidad compartida de los miembros y dejando que cada equipo encuentre aquellas prácticas y procesos que les permitan entregar valor.
Por tanto, deben ser los Developers los que usen este evento para ellos, para que sea productivo y para que tenga sentido. Si no funciona, busquemos una manera mejor de hacerlo efectivo, no hay que esperar a que un Scrum Master u otra persona nos diga cómo hacerlo.
Consejos para hacer la Daily Scrum en Remoto
En remoto, debemos evolucionar la Daily Scrum para seguir siendo efectivos. Algunos consejos generales se aplican a todas las reuniones: tener la cámara activa, ser todos puntuales y dejar los micrófonos apagados si nos interrumpimos demasiado. En ese sentido, nada cambia. Alguien del equipo debe mostrar el Sprint Backlog, es decir, el plan de trabajo que usamos para autogestionarnos. Para esta tarea, podemos rotar por día o por Sprint, para no sobrecargar a nadie.
En cuanto a herramientas, soy un apasionado de los tableros posits. Dado que en remoto se dificulta su uso, recomiendo utilizar herramientas tipo Mural o Miró que permiten visualizar toda la información de manera global. Cualquier herramienta tipo Jira o Trello que requieran hacer “scroll” para mí son poco útiles porque nos dificultan tener una foto completa. Mural o Miró permiten que trabajemos de manera colaborativa. A pesar de que solo una persona comparta pantalla, todos los Developers pueden manipular el tablero a la vez, lo que aumenta la sensación de “esto es nuestro”.
Siempre recomiendo evitar las tres “famosas” preguntas y, a cambio, que nos hagamos la verdadera pregunta: ¿llegamos al Sprint Goal? Es clave que, de la Sprint Planning, hayamos obtenido un único Sprint Goal que esté claro. Una vez lo tengamos, en la Daily Scrum deberíamos proyectar si seremos capaces de finalizarlo.
Si el equipo detecta que el Sprint Goal peligra, deben cambiar su plan de acción para tratar de acometerlo. Si aún así, necesitan modificar el alcance (que no el Sprint Goal), deben negociar con el Product Owner. De esta negociación, podemos redefinir el alcance.
Dado que en remoto es más difícil localizar a las personas al no estar en la misma ubicación, podemos utilizar la Daily Scrum para organizar reuniones del día o de la semana. Podemos decidir quiénes estarán y cuántos necesitamos que estén presentes para tomar alguna decisión relevante.
El papel del Scrum Master
Muchos Scrum Master están sintiendo que su trabajo pierde valor en remoto cuando es justo al contrario. Precisamente, en entornos donde tenemos que dar un paso adelante, es cuando un Scrum Master debe estar en primera línea, no como protagonista, sino como acompañante en el proceso de Scrum y de la entrega de valor. Si el equipo necesita entrenamiento en remoto, es porque necesitamos mejorar estas habilidades y aquí es donde un Scrum Master profesional no tiene tiempo de aburrirse.
Durante la Daily Scrum, es normal que un Scrum Master asista. Ahora bien, la responsabilidad recae sobre los Developers y no deben ser el “facilitar para todo”. Si no dejamos que los equipos tengan su espacio para organizarse, creamos un vínculo muy bonito para sentirse útil, pero innecesario si queremos que las personas den un paso al frente.
Y tú, ¿cómo haces la Daily Scrum en remoto?
