¡Pasamos tanto tiempo en reuniones que no consigo escribir código! ¿Demasiadas reuniones?
¿Cuánto tiempo debería dedicar oficialmente un desarrollador a las reuniones?
La Guía de Scrum es bastante explícita sobre los eventos de Scrum, pero es posible que los totales no sean evidentes de inmediato. Partiremos del supuesto de que trabajamos 8 horas al día, 5 días a la semana:
- Daily: 15 minutos de scrum diario por día.
- Sprint Planning: 8 horas para un Sprint de 1 mes.
- Sprint Review: revisión de Sprint de 4 horas para un Sprint de 1 mes.
- Sprint Retrospective: 3 horas para un Sprint de 1 mes.
- Refinamiento del Backlog: no es un evento en el sentido de una sola reunión, pero «dedica el 10% del tiempo a refinar el backlog».
En definitiva.
Tiempo dedicado a los eventos de Scrum
| Evento | Horas/Sprint de 4 semanas | horas al día | % | Horas Totales por semana |
|---|---|---|---|---|
| Daily Scrum | 0:15 | 2:15 | ||
| Sprint Planning | 8:00 | 2:00 | ||
| Sprint Review | 4:00 | 1:00 | ||
| Sprint Retrospective | 3:00 | 4:00 | ||
| Refinamiento Backlog | 10% | |||
| Total tiempo dedicado | 10:00 |
En total, en una semana la dedicación estimada es de 10 horas a los eventos de Scrum. Esto es el 25% del tiempo disponible.
Suena como mucho, ¿verdad? Quizás hay algunas cosas a tener en cuenta.
El refinamiento de Backlog no es una reunión
El refinamiento del Backlog no es en realidad un evento en el sentido estricto de la palabra. Es una variedad de actividades que realiza a lo largo del Sprint con un propósito: comprender el trabajo que tenemos por delante.
El refinamiento del Backlog no tiene por qué ser una reunión de 4 horas con todo el equipo cada semana.
Una sesión de mapeo de ejemplo puede contar como refinamiento de la Pila tanto como una charla informal con el Product Owner durante el café de la mañana sobre alguna idea que tengan para una nueva función.
Dediquemos el tiempo que se necesite hasta este máximo
Los tiempos mencionados anteriormente son los que la Guía Scrum considera la cantidad máxima de tiempo.
No vayamos más allá de esto. De hecho, puede haber razones para dedicar menos tiempo:
Nuestro equipo es pequeño. La alineación y el acuerdo nos llevan poco tiempo.
Nuestro trabajo es más una cuestión de volumen que de complejidad y requiere poco esfuerzo para comprenderlo completamente.
Nuestro equipo está familiarizado con el tipo de trabajo que realizamos. La experiencia en la materia es un bien común.
Nuestro equipo está familiarizado entre sí y puede discutir problemas rápidamente y alinearse en soluciones.
Nuestro equipo ha demostrado ser capaz de completar los detalles durante la implementación. Tengamos fe en nuestra capacidad para resolver las cosas a medida que avanzamos. También debemos tener en cuenta: el refinamiento del backlog no es el momento para un análisis técnico profundo. Si sabemos lo suficiente sobre el qué y el por qué, continuemos; la Planificación del Sprint y el Sprint en sí serán cuando entremos en el Cómo.
Nuestro equipo se comunica continuamente. No es necesario tener una reunión explícita para comunicarnos.
Nuestro equipo llega a las reuniones bien preparado. No puedo enfatizar esto lo suficiente: nada mata más la motivación que asistir a las reuniones sin estar preparados o sorprenderse mutuamente con elementos que podrían haberse abordado o anunciado antes.
Si nuestra reunión tiene una agenda y la hemos trabajado: no lo tratemos. No es necesario que se traten temas solo porque se le asignó un tiempo en la agenda.
Trabajando a tiempo parcial
Si trabajamos a tiempo parcial, las 10 horas antes mencionadas significarán un porcentaje relativamente mayor de nuestro tiempo.
Daily Scrum, Sprint Planning, Sprint Review y Sprint Retrospective son eventos que llevan la misma cantidad de tiempo ya sea que trabajemos 24, 32, 36 o 40 horas a la semana.
En cuanto al refinamiento del Backlog: generalmente no consume más del 10% de la capacidad del Equipo de Desarrollo. Y como se hemos comentado, no tiene por qué ser una reunión de un gran equipo.
Evitemos las interrupciones
Profundizar en un problema, pensar en cómo resolverlo y luego implementarlo son actividades que generalmente se benefician de una atención ininterrumpida. Esto sugiere que debemos planificar las reuniones de tal manera que esto sea posible.
Otra forma de interrupción es la reunión ad hoc. Tomar un descanso para dejar que nuestra mente funcione es una gran idea. No es lo mismo que tener que dejar el trabajo en cualquier momento.
Si nuestro equipo tiene que lidiar con tales interrupciones, veamos si podemos nombrar a alguien diaria o semanalmente para que sea el primero en ser interrumpido para que otros miembros del equipo puedan concentrarse.
Hora del día
Averigüemos a qué hora del día funcionamos mejor para que todos tengamos una reunión. La hora exacta del día es diferente de una persona a otra. Llevemos un registro de cuándo es más productivo al implementar soluciones y planifiquemos reuniones en torno a eso.
La estructura es importante, pero es posible que deseemos cambiar esta de vez en cuando.
Probablemente no necesitemos esa otra reunión
Antes de aceptar cualquier otro tipo de reunión que no sea un Evento Scrum, especialmente las recurrentes para todo nuestro equipo, preguntémonos si todavía no hay un Evento Scrum para ello.
La Dirección quiere saber lo que está haciendo.
Recordemos la transparencia, apertura e inspección de los Valores Scrum. Deberíamos querer compartir lo que sea que se esté haciendo. Disponer de elementos de comunicación de la información y estar dispuesto a explicarlo a quienes muestren interés. No necesitamos una reunión de equipo específica para esto.
Dicho eso:
- Los managers pueden asistir a la Revisión de Sprint.
- Los managers pueden asistir (pero no interrumpir) el Scrum diario.
- Los managers pueden leer nuestros puntos de acción con respecto al proceso que sigue a sus Retrospectivas de Sprint.
- Los managers pueden leer las métricas de desempeño que nuestro equipo ha puesto a su disposición.
Una necesidad de saber no es lo mismo que un problema de confianza. Los problemas de confianza y miedo entre el equipo y la dirección pueden obstaculizar el progreso y lo harán. Deben ser abordados y resueltos por el Equipo Scrum.
El Scrum Master puede ayudar a identificar estos problemas.
Nuestro equipo no debe temer que la dirección malinterprete o abuse de lo que nosotros hacemos transparente.
Viceversa, no debería ser una tensión para el equipo producir información que satisfaga la curiosidad de la dirección. Debe ser información que se pueda crear fácilmente y que les resulte útil.
¿Los “stakeholders” quieren saber sobre la velocidad, los puntos de historia…?
Como desarrolladores, no debemos sentirnos tentados a dedicar horas, puntos de historia u otras medidas de velocidad o de costes que hayamos estado usando dentro de nuestro Equipo Scrum. No nos dejemos engañar por la hoja de ruta y las reuniones de previsión con los stakeholders.
Estas son preguntas sobre el Product Backlog. Ahí es donde entra en juego el Product Owner. El Product Owner puede pedir consejo a los desarrolladores, por supuesto. Y dado que el Product Owner está involucrado regularmente con el progreso del equipo a través de los Scrum Events, eso no debería implicar mucho tiempo adicional.
¿Cada reunión es una pérdida de tiempo que debería haberse dedicado a la programación?
Una razón por la que muchos desarrolladores de software se quejan del tiempo que pasan en las reuniones es que prefieren dedicar ese tiempo a resolver problemas programando.
Sin embargo, también creo que es un error pensar que la competencia central de un programador es solo escribir código. La competencia central es proporcionar soluciones a través de software. La comprensión de los problemas precede a la provisión de soluciones. Eso requiere tiempo para leer, escuchar y discutir los problemas.
De hecho, la Guía Scrum habla de desarrolladores en el sentido amplio de la palabra. Cualquiera en un equipo Scrum que no sea el Product Owner es por definición un Desarrollador.
- ¿Experto en UX? Desarrollador.
- ¿Analista de negocios? Desarrollador.
- ¿Ingeniero de pruebas? Desarrollador.
- ¿Ingeniero de operaciones? Desarrollador.
- ¿Ingeniero de Seguridad? Desarrollador
- …..
Todas estas personas están involucradas en los eventos de Scrum, para alinear y comprender lo que se requiere para entregar incrementos de valor de trabajo.
Consideremos lo siguiente.
Es mejor escribir una línea de código que ayude a generar valor que tener 1000 líneas de código que no lo hagan.
El otro extremo es quedarse atascado en la parálisis del análisis y Big Design Up Front, dos cosas que hicieron que la gente abandonara Waterfall en favor de Scrum. A veces, no sabremos el valor de una idea hasta que la hayamos implementado y medido en la producción, así que sepamos cuándo dejar de hablar y comenzar a experimentar y aprender.
A fin de cuentas, creo que dedicar un mínimo del 75% de nuestro tiempo a resolver problemas juntos, con el tiempo suficiente para comprender los problemas que deben resolverse, creo que puede ser lo más adecuado