El Shu-Ha-Ri del Daily Scrum

Quizás hayas oído hablar del shuhari, concepto proveniente de las artes marciales japonesas que describe las etapas del aprendizaje desde la iniciación hasta la maestría.

Dicho concepto afirma que cuando deseamos aprender algo nuevo existen unas normas que primero debemos seguir (Shu). Posteriormente hacemos innovaciones sobre esas normas buscando desprendernos de las mismas sin alterar su fundamento (Ha) y finalmente nos libramos de los límites marcados por las normas y creamos las nuestras propias (Ri).

• 守 Shu (seguir las normas)
• 破 Ha (romper las normas)
• 離 Ri (Ser las normas)

Hoy he querido aplicar este concepto a uno de los eventos fundamentales de Scrum: el Daily Scrum, en el que el equipo de desarrollo (DT) inspecciona y adapta el trabajo hacia la consecución del Sprint Goal, sincroniza las actividades de sus miembros y elaboran el plan de trabajo para las próximas 24h.

Veamos los elementos que caracterizan el Daily Scrum de un equipo que viaja por estas tres etapas:

守 Hacia el “Shu”:

Dar cera, pulir cera.

El DT intenta reunirse en el mismo sitio y a la misma hora todos los días. A veces es necesario aplazarlo porque alguien no ha llegado todavía a la oficina, la sala está ocupada o nadie les avisa de que ya es la hora. Cuando el Scrum Master (SM) no está disponible el equipo de desarrollo lo realiza de forma frugal o bien no lo realiza.

Normalmente el equipo se arremolina alrededor del SM esperando que éste les de el pistoletazo de salida. Por turnos los miembros contestan a las tres preguntas del daily antes de pasar el testigo al miembro contiguo. La mayoría se dirige principalmente al SM reportando y/o justificando el trabajo hecho/no hecho. Algunos miembros declaran que están esperando a que otros terminen sus tareas para poder empezar las suyas. Algunas veces las conversaciones se extienden más de lo esperado entrando en detalles técnicos que debieran discutirse en otro momento. Cada miembro habla de las tareas que tiene asignadas y las que pretende realizar de forma prácticamente individual, con poca interacción hacia el resto de miembros salvo que haya un bloqueo importante. El Sprint Backlog (SB) no suele estar actualizado de antemano y el equipo suele prestar poca atención a las métricas tipo burn-down para comprobar el progreso hacia el Sprint Goal (Es posible que el equipo no tenga siquiera un Sprint Goal). Si el Product Owner (PO) atiende entonces se aprovecha la reunión para aclarar algunos ítems del SB en lugar de crear el plan del día. El SM mismo se ha visto participando más de una vez en la reunión cuando debiera dejar ese espacio de tiempo para el equipo de desarrollo. Pese a sus esfuerzos por controlar el tiempo se suele sobrepasar el timebox de 15 minutos con cierta frecuencia y además uno o más miembros del equipo no tienen tiempo de hablar, razón por la que a veces es necesario alargarlo.

Progreso: El SM tiene bastante trabajo por delante. El equipo se reúne, participa y se reporta mutuamente, pero no trabajan como un equipo. Al final del evento no hay plan de acción diario, ni compromisos para las siguiente 24 horas. Con el tiempo el equipo generalmente obedece las normas del Daily Scrum prescritas en la Guía de Scrum. Existen puntos por pulir y todavía por asimilar, sin embargo con la ayuda del Scrum Master el equipo de desarrollo repite el evento día tras día ateniéndose a las normas.

破 Hacia el “Ha”:

Al diablo con las circunstancias, yo creo oportunidades.

El DT se reúne todos los días en el mismo sitio a la misma hora. Han encontrado el momento y lugar adecuado para que todos puedan asistir, incluso tomado medidas como aplazarlo a última hora de la tarde. No necesitan que el SM les avise de que ya ha llegado la hora, el DT se pone en marcha hacia el punto de reunión.

El equipo se arremolina en torno al tablero de Scrum y uno de ellos arranca el evento. Algunos contestan a las preguntas del daily aunque añaden otras variaciones que se centran en el trabajo actual (como tratar cada ítem en orden antes de pasar al siguiente) y se percibe que algunos miembros lo traen preparado, lo que normalmente implica que el SB está actualizado. En su turno se dirigen al resto de compañeros reportando de forma sencilla, pero también pidiendo ayuda, ofreciéndola y compartiendo la idea que tienen para afrontar el trabajo que esperan realizar hoy, que se ajusta en base a todos los participantes. Cuando se extienden en el tiempo, ‘aparcan’ el tema para más tarde (Incluso usan una pizarra para ello). El Sprint Goal existe, encabeza el tablero y recuerda a todos por qué estamos trabajando en esto. Además, el DT tiene la visión general del progreso mediante alguna métrica en pantalla que evita pasar por alto desviaciones. Las aportaciones del PO son rápidas y bajo demanda, al igual que las del SM que se limita a escuchar/anotar sus observaciones. Los 15 minutos se respetan, el SM no es el único que mira el reloj, pero cuando llega el momento de finalizar la reunión es él quien la acaba y el equipo se reúne después una vez más si es necesario. Por el contrario, si el tiempo sobra, sobra, y no se intenta 'llenar' el timebox hasta los 15 minutos.

Progreso: El SM tiene por tarea recopilar impedimentos fuera del dominio del DT y de anotar puntos de mejora. Percibe organización y quizás signos de una colaboración que va por buen camino, las decisiones se toman durante o después del evento por consenso y se materializan en coordinación de tiempos, pair programming y otras técnicas. También se alcanzan compromisos diarios que, aunque no se cumplan siempre, marcan el ritmo del día a día. El equipo añade aquello que cree necesario al daily scrum sin quebrantar las normas básicas, por ejemplo, se desprenden de las 3 preguntas y producen las suyas propias; o alternan los turnos individuales en conversación por pares/tríos. Al final del evento todos tienen medianamente claro cuál es el plan del día y cómo creen que deben proceder para conseguirlo.

離 Hacia el “Ri”:

Be water my friend

El DT celebra todos los días el Daily Scrum en su espacio reservado. La actitud unánime es aprovechar el tiempo y sacar el mayor partido del mismo en un evento sin el cuál sería más difícil organizarse, por lo que se toman unos minutos si es necesario antes de arrancarlo. Cualquiera de sus miembros inicia el meeting y éste se desarrolla sin un orden particular (Primero los impedimentos y/o los bloqueos, después los avances, después las propuestas…). Todos se enfocan en el cómo y en el cuándo, pero incluyen en sus cálculos la entrega de valor de negocio cuanto antes, esto es, se centrarán en aquellos ítems que puedan terminar en el timebox de un día. El equipo suele tener claro algunos elementos clave como la disponibilidad de los miembros (Ejemplo: miembros con otras dedicaciones), la definición de hecho, el calendario del sprint, el Sprint Goal, impedimentos, etc y los mantiene de forma visual en el espacio de trabajo por si deben revisarse sin perder tiempo. Preguntas como “¿Qué es lo mínimo de valor que podemos hacer hoy?” o “¿Cómo nos organizamos para hacer el máximo posible hoy?” sustituyen a las tres preguntas básicas y se crea un “Daily goal” al que todos se comprometen a cumplir antes de finalizar el día. Al concluir el encuentro cualquier miembro del equipo podría resumir el plan acordado y cómo piensan coordinarse para sacar el mayor partido del mismo, al igual que si se tratara de un Sprint Planning con un alcance de 24 horas.

Progreso: El SM juega un papel secundario. El daily Scrum es un evento para el DT y sólo para el DT. El equipo no sólo coopera, sino que colabora, es decir, (metafóricamente) tocan sus instrumentos de forma individual pero al mismo son. Cuando reportan lo hacen para ellos mismos, no para que otro mánager compruebe quién está detrás de retraso de los tiempos. Si el equipo dice que va a hacer algo, lo hace, y si está hecho, está hecho, no casi hecho, sino conforme con la definición de hecho. Si surgen problemas, los resuelven juntos. Si los problemas se salen del dominio del DT entonces se delegan en el SM. El equipo está enfocado y cumple su compromiso. Pese a las buenas perspectivas en esta etapa un buen SM siempre buscará puntos de mejora que lleven al equipo al siguiente nivel, ya que conseguir un equipo perfecto (incluso en esta etapa tan avanzada) está lejos de la realidad.

Conclusiones

Scrum va de aprovechar las oportunidades, y el Daily Scrum es la oportunidad para maximizar el trabajo del día. Aunque el evento se realice a un nivel muy bueno hay que decir que esto no significa que el trabajo se vaya a lograr en un día, sin embargo, bien realizado, el daily scrum aumenta las probabilidades de que esto ocurra. Por ello, y dado que es un evento clave en el framework de scrum, es importante inspeccionar y adaptar nuestro Daily scrum, identificar elementos que ya hacemos y que podremos llegar a hacer en una progresión parecida a la expuesta y, en definitiva, mejorar la entrega de valor cuando nuestros stakeholders lo esperan.

Y para tí ¿Qué elementos detectas que sitúen a tu equipo en una de estas tres etapas? ¿Estáis en el Shu? ¿En el Ha? ¿En el Ri? ¿Qué crees que os hace falta para pasar de una fase a otra?